Hi Christian On Tue, Dec 21, 2010 at 11:04 AM, Christian Schneider < [email protected]> 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< >> [email protected]> 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 > >
