Hi, I know this is a bit dated, but I just wanted to mention that I had exactly the same problem with CXF 2.2.5 and that Dan's solution worked perfectly. In the startup of my application, I added at some point WSSConfig.getDefaultWSConfig() .setAllowNamespaceQualifiedPasswordTypes(true). It worked!
Thanks Dan. On Fri, Feb 5, 2010 at 12:48 AM, huidong <[email protected]> wrote: > > i am using the latest 2.2.6. can you elaborate how to pass WSconfig object? > my configuration is something like: > > <jaxws:inInterceptors> > > <bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor"> > <constructor-arg> > <map> > <entry key="action" value="UsernameToken" /> > <entry key="passwordType" value="PasswordText" /> > <entry key="passwordCallbackClass" > value="***.ws.impl.PasswordCallback" /> > <entry key="allowNamespaceQualifiedPasswordTypes" value="true" > /> > </map> > </constructor-arg> > </bean> > </jaxws:inInterceptors> > > this way, after i modified WSS4JInInterceptor, it works fine for both > java/.Net clients. > > > dkulp wrote: > > > > > > > > Well, the code on trunk is a bit different now in that the WSConfig > object > > that is used can be passed in as a property. Thus, with that, it's > much > > easier. > > > > One option for you COULD be to do something like: > > > > > WSSConfig.getDefaultWSConfig().setAllowNamespaceQualifiedPasswordTypes(true); > > > > in some user code or something at startup. That should set the default > > config > > object to allow it which would then be used for processsing. > > > > Dan > > > > -- > View this message in context: > http://old.nabble.com/An-invalid-security-token-was-provided-%28Bad-UsernameToken-Values%29-tp27429163p27461028.html > Sent from the cxf-user mailing list archive at Nabble.com. > >
