Hi Paul,
Is it worth revisiting Basic and Digest authentication support for the
client now that 1.0 is released? I'd be more than happy to try and
help out.
Cheers
Mike
2008/9/1 Mike Jones <mike.a.jones_at_gmail.com>:
> Hi Paul
>
> There is no rush for integration from my point of view - I'm using the
> basic authentication within my own test cases and that has scratched
> an itch. :-)
>
> I'll think over your points when I'm more awake. :-D
>
> Mike
>
> 2008/9/1 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>> Hi Mike,
>>
>> This is a good start. The digest use-case is espcially useful to understand
>> that processing the request and response is especially useful from within
>> the same filter class. This is good to know for any refactoring i do to
>> better support modifying the Input/OutputStream.
>>
>> Some points:
>>
>> What if there is no authentication header in the response for certain
>> resources?
>>
>> What if different resources have different digest authentication? (i dunno
>> if this is common or not, to some extend different clients should be used
>> for different auth requests, or the filter is added to certain web
>> resources).
>>
>> It may be possible in certain circumstances when receiving the authenticate
>> response to resend the request. For POST/PUT request this requires that
>> buffering of the request body, or being able to generate the body more than
>> once, is supported for non-authenticated requests. But perhaps it may be
>> appropriate to utilize a HEAD request (assuming GET and POST is supported?)
>> to avoid buffering.
>>
>> Do you mind if we consider this for integration after the 1.0 release?
>>
>> Paul.
>>
>> Mike Jones wrote:
>>>
>>> Hi Paul
>>>
>>> I've updated the file - it includes an initial attempt at filter that
>>> supports basic digest. It works (against Jetty in the test) but I need
>>> to do some more work:-
>>>
>>> - the way it handles the authorization in the filter life cycle could
>>> be more elegant.
>>> - it assumes that it is dealing with qop="auth".
>>> - the nonce count is never incremented.
>>> - For the client nonce I create a string via
>>> RandomStringUtils.randomAlphanumeric(8) (provided by commons-lang) and
>>> then md5 hash it. Overkill?
>>> - I took the hashing method from a work project. This probably needs
>>> changing since it was cobbled together from a number of examples given
>>> on blogs but can't remember which :-).
>>>
>>> However, its a start :-D
>>>
>>> <http://dl.getdropbox.com/u/19381/jersey-auth.tar.gz>
>>>
>>> Mike
>>>
>>> 2008/8/28 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>>>>
>>>> Hi Mike,
>>>>
>>>> Sorry for the late reply. I will take a closer look at this on Friday.
>>>>
>>>> Paul.
>>>>
>>>> On Aug 26, 2008, at 12:10 AM, Mike Jones wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> For the moment I've created a small project for the basic
>>>>> authentication filter. I've also created a single test case that has
>>>>> two tests. One test applies the filter to a Client and the other
>>>>> against a WebResource. In each test a request is made without the
>>>>> filter to check we get a 401 response and then a 200 after the filter
>>>>> has been applied. I'm using embedded jetty and a *very* trivial
>>>>> servlet in the testing.
>>>>>
>>>>> I've placed the code at:
>>>>>
>>>>> http://dl.getdropbox.com/u/19381/jersey-auth.tar.gz
>>>>>
>>>>> What package namespace should I be using? I'm using one based on my
>>>>> employer at the moment: org.ilrt.jersey.filter.
>>>>>
>>>>> I'll look at the digest stuff next.
>>>>>
>>>>> Cheers
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>> 2008/8/25 Mike Jones <mike.a.jones_at_gmail.com>:
>>>>>>
>>>>>> Ok, I'll look at creating some tests and will have a look at the
>>>>>> digest authentication :-D
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>> 2008/8/25 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>>>>>>>
>>>>>>> Hi Mike,
>>>>>>>
>>>>>>> This looks good. We would require tests to an authenticated service. I
>>>>>>> am
>>>>>>> guessing such services could be written using embedded Jetty and we
>>>>>>> can
>>>>>>> make
>>>>>>> them unit tests.
>>>>>>>
>>>>>>> BTW you can do this:
>>>>>>>
>>>>>>> clientRequest.getMetadata().
>>>>>>> putSingle("Authorization", new String(encoded));
>>>>>>>
>>>>>>> I think having this as a separate contribution would be best as it
>>>>>>> depends
>>>>>>> on the Apache commons.
>>>>>>>
>>>>>>> I agree with Imran that one should avoid having such information in
>>>>>>> the
>>>>>>> URI.
>>>>>>> We should stick to utilizing HTTP authorization headers.
>>>>>>>
>>>>>>> Extra bonus points for supporting the digest access authentication
>>>>>>> scheme
>>>>>>> [1] :-)
>>>>>>>
>>>>>>> Paul.
>>>>>>>
>>>>>>> [1] http://www.ietf.org/rfc/rfc2617.txt
>>>>>>>
>>>>>>> Mike Jones wrote:
>>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I've had as quick go at creating a filter for basic authentication.
>>>>>>>> It
>>>>>>>> works well for my tests and uses the Base64 encoder provided with
>>>>>>>> commons-codec:
>>>>>>>>
>>>>>>>> <snip>
>>>>>>>> public class BasicAuthenticationClientFilter extends ClientFilter {
>>>>>>>>
>>>>>>>> public BasicAuthenticationClientFilter(final String username,
>>>>>>>> final String password) {
>>>>>>>> this.username = username;
>>>>>>>> this.password = password;
>>>>>>>> }
>>>>>>>>
>>>>>>>> public ClientResponse handle(ClientRequest clientRequest) throws
>>>>>>>> ClientHandlerException {
>>>>>>>>
>>>>>>>> // encode the password
>>>>>>>> byte[] encoded = Base64.encodeBase64((username + ":" +
>>>>>>>> password).getBytes());
>>>>>>>>
>>>>>>>> // add the header
>>>>>>>> List<Object> headerValue = new ArrayList<Object>();
>>>>>>>> headerValue.add("Basic " + new String(encoded));
>>>>>>>> clientRequest.getMetadata().put("Authorization", headerValue);
>>>>>>>>
>>>>>>>> return getNext().handle(clientRequest);
>>>>>>>> }
>>>>>>>>
>>>>>>>> private String username;
>>>>>>>> private String password;
>>>>>>>> }
>>>>>>>> </snip>
>>>>>>>>
>>>>>>>> I'd like to make it more robust and useful as a contribution to
>>>>>>>> jersey. I need some tests for it and was also wondering if it should
>>>>>>>> check for the username and the password in the URI:
>>>>>>>> http://mike:secret@localhost/ ? Any thoughts?
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> 2008/8/20 Mike Jones <mike.a.jones_at_gmail.com>:
>>>>>>>>>
>>>>>>>>> Hi Marc
>>>>>>>>>
>>>>>>>>> That worked a treat for the one test I wrote - I think I'll need to
>>>>>>>>> call a Authenticator.setDeault(null) on the tearDown to stop
>>>>>>>>> specific
>>>>>>>>> the credentials going across more than one test.
>>>>>>>>>
>>>>>>>>> Paul's idea about the Filter is interesting - I suppose using that
>>>>>>>>> you
>>>>>>>>> can support conventions like http://mike:secret@example.org/
>>>>>>>>>
>>>>>>>>> Thanks for the help
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>> 2008/8/20 Marc Hadley <Marc.Hadley_at_sun.com>:
>>>>>>>>>>
>>>>>>>>>> Try adding the following to your code before you use the client
>>>>>>>>>> API:
>>>>>>>>>>
>>>>>>>>>> final String username ="...";
>>>>>>>>>> final String password ="...";
>>>>>>>>>> Authenticator.setDefault(new Authenticator() {
>>>>>>>>>> protected PasswordAuthentication getPasswordAuthentication() {
>>>>>>>>>> return new PasswordAuthentication (username,
>>>>>>>>>> password.toCharArray());
>>>>>>>>>> }
>>>>>>>>>> });
>>>>>>>>>>
>>>>>>>>>> HTH,
>>>>>>>>>> Marc.
>>>>>>>>>>
>>>>>>>>>> On Aug 20, 2008, at 6:45 AM, Mike Jones wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello
>>>>>>>>>>>
>>>>>>>>>>> I'm using Jersey with Spring security and I'm in the process of
>>>>>>>>>>> creating some tests that use embedded Jetty and the Jersey client.
>>>>>>>>>>> I
>>>>>>>>>>> need to perform some basic authentication with the client - do I
>>>>>>>>>>> need
>>>>>>>>>>> to encode the credentials in Base64 myself and add them to the
>>>>>>>>>>> headers
>>>>>>>>>>> in the jersey client? Am I missing some nice (and probably
>>>>>>>>>>> obvious)
>>>>>>>>>>> helper methods for this?
>>>>>>>>>>>
>>>>>>>>>>> Cheers
>>>>>>>>>>> Mike
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>>>>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> Marc Hadley <marc.hadley at sun.com>
>>>>>>>>>> CTO Office, Sun Microsystems.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>>>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>>>>
>>>>>>> --
>>>>>>> | ? + ? = To question
>>>>>>> ----------------\
>>>>>>> Paul Sandoz
>>>>>>> x38109
>>>>>>> +33-4-76188109
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>> --
>> | ? + ? = To question
>> ----------------\
>> Paul Sandoz
>> x38109
>> +33-4-76188109
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>