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
>
>