Possible bug in AuthorizationBaseServerResource

I have noticed that in some usecases that the function getAuthSession() in
AuthorizationBaseServerResource returns null because the cookie has not been set yet. Althought it is
set before a redirect in the Attributes of the request. Wouldn't it be more logical to change the
getAuthSession() method to:

    protected AuthSession getAuthSession() {
        // Get some basic information
    	String sessionId = (String) getRequest().getAttributes().get(
                ClientCookieID);
    	
    	if (sessionId == null)
            sessionId = getCookies().getFirstValue(ClientCookieID);
    	
        getLogger().fine("sessionId = " + sessionId);

        getRequest().getAttributes();

        AuthSession session = (sessionId == null) ? null
                : (AuthSession) getContext().getAttributes().get(sessionId);
        return session;
    }

So first verifying the the sessionId is in the request and only then checking if it is in the cookie?

I see that they did this in 2.1 version of restlet, but now they only get it from the cookie?

The bug I'm experiencing does not pop up anymore after I change the restlet oauth extension

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3056197

HTTP_DIGEST authorization in android client

Hey All,

Got following problem with HTTP_DIGEST authorization via Restlet framework on Android.

05-20 18:39:14.623: W/System.err(4584): Challenge scheme HTTP_DIGEST not supported by the Restlet
engine. 

05-20 18:39:17.498: W/System.err(4584): Couldn't find any helper support the HTTP_Digest challenge scheme.

Part code that is executed on client and gives above error

clientResource =new ClientResource("http://example.com/position");
try{
clientResource.wrap(MailResource.class);
ChallengeResponse challengeResponse = new ChallengeResponse(ChallengeScheme.HTTP_DIGEST,
"1671046999",
"tiger");      
clientResource.setChallengeResponse(challengeResponse);
clientResource.get();
}
catch (Exception e)
{
e.printStackTrace();
}

Checked that resource via browser and authorization seems to be fine.

Any advices?:)

Google doesn't brought up anything except solution

Cannot find a copy of sample MyNtlmHttpClientHelper.java

Document:
http://restlet.org/learn/guide/2.0/core/security/authentication/ntml

References a sample NTLM Client Helper for usage with the Apache HTTPClient.  

Does anyone have a copy of the MyNtlmHttpClientHelper.java file that this article references?   Every link
I can find appears to point directly back to the main wiki/tutorial pages.

from: http://restlet.org/learn/guide/2.0#/363-restlet/version/default/part/AttachmentData/data/MyNtlmHttpClientHelper.java

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3055657

endless "Too many open files" exceptions

Hi,

I am working with Restlet 2.1.2, using both client and server
code as parts of a larger applications.

After working correctly for some time (maybe days),
a GET request causes an endless succession of
"Too many open files" exceptions. As it happens,
those are being written into a log file (by nohup) and
eventually exhaust all available disk space -- it appears
the exceptions just keep pouring out, one after another.
Maybe the failed connection is retried immediately, so that
fails again with the same error? Just guessing. I looked at
the source code but I can't tell what's going on.

Here is one such exception. The message is printed by
ServerConnectionController.onSelected.

  Unexpected error while accepting new connection

  java.io.IOException: Too many open files
	at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
	at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:163)
	at org.restlet.engine.connector.ServerConnectionController.onSelected(ServerConnectionController.java:103)
	at org.restlet.engine.connector.ConnectionController.selectKeys(ConnectionController.java:308)
	at org.restlet.engine.connector.ConnectionController.doRun(ConnectionController.java:171)
	at org.restlet.engine.connector.Controller.run(Controller.java:159)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)

latest on push technology

Hi,

What is the current recommended strategy with restlet to implement some 
form of a server side push in a browser environment.

In our case we have 2 use cases for this.

1) A standard publish/subscribe requirement for sending messages to the 
client.
2) We need to simulate a server side ssh or telnet terminal session via 
the browser.

For 2 I think it might be better and simpler to use restlet's current 
streaming representation support.

BTW, really enjoying working with the restlet api.

Thanks
Pieter

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3055303

Assistance with persisting objects

I have asked two questions on StackOverflow and was just awarded the "Tumbleweeds" badge because of the low
view count and no answers.  I have also searched the web multiple times and don't see anything that answers
these questions.

Could someone on this list please take a look at these and let me know how application and request
persistence works in Restlet?

http://tinyurl.com/bmhoxvm

http://tinyurl.com/d2xkw8k

Thanks!

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3055155

How much REST should your web API get?

Android client - Restlet 2.0.15 - cannot connect with HTTPS/SSL - recoverable error 1001

Hi all,

I have written an Android web service client using the Restlet framework for
Android (2.0.15), and I've also written the web service backend as well
(again with Restlet 2.0.15 JEE) which has been uploaded on AWS Elastic
Beanstalk (so the client calls would be in the form of
"http://my_web_service.elasticbeanstalk.com/this/is/my/request"). Everything
works fine on HTTP, so now I'd like to replace it with HTTPS, but this has
proven more difficult that I initially thought.

I have created a trial SSL certificate from Comodo, where I have declared,
as a CNAME, a domain that I own (unfortunately, I cannot declare the
elasticbeanstalk.com subdomain, where the AWS load balancer is running, as a
certificate hostname). This certificate has been uploaded to my AWS
instance, and it seems to be running succsefully (tested via web browser, a
couple of https calls get through succesfully after I accept the certificate
on the browser). The only thing that I don't like about this certificate is
the fact that I get a warning that this may be an invalid certificate, since
the declared hostname (my domain) and the actual hostname that the
certificate is running (elasticbeanstalk.com) do not match.

In my client I'm using the apache http client (have loaded the
org.apache.httpclient.jar on claspath), and this is how I create the client
resource I use on every call, which is plain and simple:

/ClientResource resource = new ClientResource(resourceUri);
Engine.getInstance().getRegisteredClients().clear();
Engine.getInstance().getRegisteredClients().add(new
HttpClientHelper(null));/

Of course, /resourceUri/ is in the form of
"https://my_web_service.elasticbeanstalk.com/this/is/my/request", and this
is the only difference between the working HTTP case and the non-working
HTTPS case. With HTTPS, I get the error below:

A recoverable error was detected (1001), attempting again in 2000 ms.

I've tried several suggestions that I found on google (using
org.restlet.ext.net httpclient instead of apache or even loading the
org.restlet.ext.ssl jar from Restlet Android 2.1), but nothing has worked so
far. I've even captured a network trace with Wireshark, and here's the
callflow:

ssl_call_flow.txt
<http://restlet-discuss.1400322.n2.nabble.com/file/n7578771/ssl_call_flow.txt>  

From the callflow above, it seems that client and server fail to complete a
succesful negotiation, but I have no idea why.

Any suggestions on how to resolve this problem are welcome. I believe that
the issue exists on the client side (Android app using Restlet 2.0.15
framework), but not on the app code itself (since everything works fine when
using HTTP) but rather on the SSL negotiation/handshake before actually
making any calls. I also believe that the Certificate Authority (Comodo) is
successfully accepted/trusted by Android (I've done https calls through the
android device browser), but it still gives you a certificate warning that
you need to accept before continuing. Could it be that Restlet 2.0.15 is not
handling smoothly SSL communication, and I would need to upgrade to 2.1 or
later?

Looking forward to hearing your suggestions. In case you'd like to get some
more info that could help, just ask me. :)

Thanks in advance, 
Alex

--
View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Android-client-Restlet-2-0-15-cannot-connect-with-HTTPS-SSL-recoverable-error-1001-tp7578771.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3054809

Restlet streaming API for json/xml

It is very useful that Restlet automatically does content negotiation and 
returns json or xml result by combining annotated interfaces and the 
converter service. Optionally it uses Jackson and xstream for these two 
formats.

The default works fine if the size of the returned results is not very big. 
However, if we returns a huge array of millions of integers in json 
format, it seems a streaming API is more appropriate.

Is it possible to configure Restlet (or Jackson/xstream) at server side so 
it can return json/xml results using a streaming API?

The real application is actually trying to pull out a huge list of integers 
and save them in a file. The list of integers is computed dynamically at 
server side.

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3054716

catching JSON parse errors

Using Asynch setOnResponse

Hi,I am trying to use and understand the asynchronous client callback.  Here is code sections:

-------------
//In the main:
  ClientResource cr = new ClientResource(myurl);
  cr.setOnResponse(new MyUniform());
  //cr.get();
  cr.getOnResponse();
  System.out.println("done with main");

//In the MyUniform class
public void handle(Request request, Response response) {
  try {
     String text = response.getEntity().getText();
     System.out.println(text);
   } catch (Exception e) {
      e.printStackTrace();
   }
}
----------------

I am not quite sure if I should use ClientResource.get or getOnResponse.  It seems like I should use
getOnResponse, but that is having no effect.  If I use get(), it works, but not asynchronously, as it prints
"done with main" after the response is obtained.  

Any thoughts on how I can set this up?

Thanks,
-Adam

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3054435