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