cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: DigestAuthTest is failing on 2.3.x
Date Tue, 21 Dec 2010 11:44:08 GMT
Hi Christian

On Tue, Dec 21, 2010 at 11:04 AM, Christian Schneider <
chris@die-schneider.net> wrote:

> Hi Sergey,
>
> thanks for the hints. I have written a systest for the digest auth. When I
> only set username and password my test does not do correct digest auth.
> I also need to set the authSupplier. If I don´t set it then the request is
> not cached and the retransmission is not done.
> Perhaps I broke something during my refactorings but when reading the 2.2.8
> code I think it reacts in the same way.
>
> In any case I get an exception of "Can´t find inputstream" when the
> authentication fails. I guess this is not correct.


 I suspect what is happening in this case is that the HttpConduit is
attempting to read the (normal) input stream despite the fact that error
status is say 401 or 500. I thought I actually fixed it for JAX-RS tests to
work properly, but may be the issue you are describing is caused by the code
at a slightly higher level...


> I would rather expect to find an exception that describes that the
> authentication
> failed. Do you know how the conduit should react in this case?
>
>
I'm just not entirely sure if HttpConduit should throw an exception in this
case. What if the authentication has failed at the CXF server interceptor
level in which case a SOAP service would return 500 (as opposed to 401),
HTTPConduit can not introspect itself the cause of the failure.

Cheers, Sergey



> Best regards
>
> Christian
>
>
>
> Am 16.12.2010 23:32, schrieb Sergey Beryozkin:
>
> Hi Christian
>>
>> On Thu, Dec 16, 2010 at 9:50 PM, Christian Schneider<
>> chris@die-schneider.net>  wrote:
>>
>> Hi Sergey,
>>>
>>> I wrote the test but it was not correct. I write the digest auth token
>>> from
>>> a hashmap. The test compared the result string with an expected string.
>>> Seems for hashmap this is not always working.
>>> So I corrected the test by parsing the token into a map and comparing two
>>> maps. That seems to work reliably.
>>>
>>>
>>> I've had quite a few tests failing in a similar way too :-)
>>
>>
>> Btw. Before there was no real test of DigestAuth at all. I would like to
>>> also create an integration test for digest auth. Does anyone have a good
>>> idea how to do this? Is it possible to start embedded jetty with digest
>>> auth?
>>>
>>>
>>> I've written recently two Jetty-based system tests relying on Jetty
>> security
>> features, one is to do with Jetty providing the container-managed
>> authentication. For example, see
>>
>>
>> http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/security/JAXRSSimpleSecurityTest.java
>>
>> It is a JAX-RS test but you can probably just copy&  paste it
>> into systests/jaxws, as well as test/resources/jaxrs_simple_security
>> folder
>> (into say jaxws_digest) and just updates beans.xml (more on it below).
>>
>> But this code
>>
>>
>> http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/security/BookServerSimpleSecurity.java
>>
>> is probably of main interest, there we tell Jetty where the
>> jetty-realm.properties file
>>
>>
>> http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/security/jetty-realm.properties
>>
>> is located.
>>
>> So the only other thing to do is to have web.xml require the DIGEST auth,
>> I
>> guess you just need to replace BASIC with DIGEST in
>>
>>
>> http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/resources/jaxrs_simple_security/WEB-INF/web.xml
>>
>> Note - the security-constraint section is commented out because I do not
>> want Jetty to enforce the user is in a certain role bur rather want CXF
>> interceptors to enforce it, I only want jetty to populate the current
>> principal (name, roles).
>>
>> Finally, you can have in your beans,xml just a single JAX-WS endpoint,
>> similar to the jaxrs endpoint with the /security1 address, just have the
>> SimpleAuthrorizingInterceptor registered only
>>
>>
>> http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/resources/jaxrs_simple_security/WEB-INF/beans.xml
>>
>> A test like this can verify that the container is capable of processing
>> the
>> digest auth Authorization, and that CXF can enforce the
>> container-populated
>> rules on a per-endpoint basis...You can simplify it a lot, omit the
>> authorization part, etc
>>
>> Hope it helps, Sergey
>>
>>
>> Best regards
>>>
>>> Christian
>>>
>>>
>>> Am 16.12.2010 17:59, schrieb Sergey Beryozkin:
>>>
>>> Hi,
>>>
>>>> Just spotted :
>>>>
>>>>
>>>>
>>>> https://hudson.apache.org/hudson/job/CXF-Trunk-JDK15/org.apache.cxf$cxf-rt-transports-http/1577/testReport/org.apache.cxf.transport.http/DigestAuthSupplierTest/testEncode/
>>>>
>>>> Does someone know what can be causing it ?
>>>>
>>>> cheers, Sergey
>>>>
>>>>
>>>> --
>>> ----
>>> http://www.liquid-reality.de
>>>
>>>
>>>
> --
> ----
> http://www.liquid-reality.de
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message