Restlet Request object doesn't contain authentication information

[Kevin Grimes]

The codebase I'm working with has two versions: the first (older) version uses v1.0.0 of the Restlet framework, and the latter (newer) version uses v2.2.2.

When a user queries both versions of my service with cURL and provides their username and password as a base64 encoded String, it works. Similarly, both versions accept the encoded String in the Authorization: Basic ... header.

Where they differ is when I attempt to call the service using HttpURLConnection. The former works, the latter doesn't.

This is the general idea of how the tool that calls my service works:

final String xx_userid = userid; // userid set above
final String xx_pwd = pwd;       // pwd set above
Authenticator.setDefault(new Authenticator() {
    protected PasswordAuthentication getPasswordAuthentication() {
        return new PasswordAuthentication(
                xx_userid, xx_pwd.toCharArray());
    }
});

// ... some more code ...

URL url = new URL(url_string); // url_string is the endpoint of my service
HttpURLConnection conn = (HttpURLConnection)url.openConnection();
conn.setRequestMethod("GET");
conn.setRequestProperty("Accept-Charset", "UTF-8");
conn.setRequestProperty("Accept", "text/xml");

The above code works for the older codebase (that is, I get a 200 OK back as well as the expected XML response). However, for the new codebase, I get a 403 Unauthorized back.

Here's the snippet in my new codebase that's supposed to get the username and password from the request:

@Override
protected boolean authenticate (Request request, Response response) {

    String user = null;
    String pass = null;

    user = request.getChallengeResponse().getIdentifier();
    pass = new String(request.getChallengeResponse().getSecret());

    // ... some more code ...

}

Both user and pass end up staying null, because the getChallengeResponse() method returns null.

Does anyone know why this code works for v1.0.0 of the Restlet framework, but not for v2.2.2? Or is there something else I'm missing?

Some other (probably irrelevant) information:

• The old codebase:
  • Is running in Tomcat v7.0.55
  • Is hosted on a RHEL7 machine
  • Doesn't have a load balancer
• The new codebase:
  • Is running in Tomcat v7.0.55
  • Is hosted on an EC2 instance (Amazon Linux AMI)
  • Uses Amazon's application load balancer (ALB) to point to the different EC2 instances
  • The load balancer has a different domain name than the service instances

Thanks in advance. Please let me know if there's any more information that I could provide to make this easier to debug.

[Thierry Boileau]

Hello Kevin,

Thanks for the detailled mail.

I've tried your sample client code and requested a simple netcat-based server (just run nc -l <port number>).

And I get these headers:

GET / HTTP/1.1
Accept-Charset: UTF-8
Accept: text/xml
User-Agent: Java/1.8.0_172
Host: localhost:8182
Connection: keep-alive

That is to say, the HttpUrlConnection does not seem to send the Authorization header (which explains why the ChallengeResponse is null).

Having said that I don't understand why the 1.1 version seems to retrieve such header...

Can you check that it works for you as soon as you manually set the Authorization header?

conn.setRequestProperty("Accept", "text/xml");

// Add manually the Authorization header
String userpass = xx_userid + ":" + xx_pwd;
String basicAuth = "Basic " + new String(java.util.Base64.getEncoder().encode(userpass.getBytes()));
conn.setRequestProperty ("Authorization", basicAuth);

Best regards,

Thierry Boileau 

[Kevin Grimes]

Hi Thierry,

I appreciate your response. Glad to hear that I’m not the only one experiencing this behavior.

Yes, manually setting the authorization header as you’ve mentioned works fine. This is the approach I’m currently taking to work around the issue.

Thanks,

Kevin Grimes

[Kevin Grimes]

Hi Thierry,

I appreciate your response. Glad to hear that I’m not the only one experiencing this behavior.

Yes, manually setting the authorization header as you’ve mentioned works fine. This is the approach I’m currently taking to work around the issue.

Thanks,

Kevin Grimes

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to framework-disc...@restlet.org.