--- On Thu, 4/29/10, Andy Spitzer (JIRA) <[email protected]> wrote: > Will that work with standard SOAP clients? They all > accept a cleartext username/password, and provide it when > challenged, either with BASIC or Digest depending on what > the server asks for. If it asks for Digest, yet > expects something different in the response, it doesn't seem > like that'll work. > > --Woof!
This is wrt XX-8253: as Woof! figured out, there are some issues with digest auth in sipx. Checking Acegi ref ( http://www.acegisecurity.org/guide/springsecurity.html#digest ) looks like digest auth process needs clear text passwords in authentication providers, and is not our case. So what is happening here: we have defined an user authentication provider which receives the presented clear text password, encodes it and checks it against the one stored in db. This works fine in form & basic auth, but fails on digest one since the received password is already encoded. What I've done for solving this (didn't post a patch yet, still investigating other ways) was to extend the acegi digest filter and to place a custom digest token in security context. User auth provider then checks the instance of received token and if it's a digest one it will skip the encoding part (will just compare with the one within db). Tested OK from soapUI (version 3.5, both REST and SOAP) and from Mozilla & Opera browsers. Since basic & digest auth are handled by separate Acegi filters basic auth functionality won't be affected. Any thoughts on this one? Thanks, George P.S. I am thinking to raise a JIRA task to update wiki - how to test sipX WS + sample of sipx WS clients (I can provide a Java + python sample but would need help for other technologies) _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
