Yes, that does it. Will look forward to the patch, but I can use
this temporarily, thank you very much.
chris
Daniel Kulp wrote:
> Well, you could query the header yourself (lowercase version) and do all
> the decoding yourself in your interceptor:
>
> Map<String, List<String>> requestHeaders;
> requestHeaders = message.get(Message.PROTOCOL_HEADERS)
> if (requestHeaders.containsKey("authorization")) {
> List<String> authorizationLines =
> requestHeaders.get("authorization");
> String credentials = authorizationLines.get(0);
> String authType = credentials.split(" ")[0];
> if ("Basic".equals(authType)) {
> String authEncoded = credentials.split(" ")[1];
> try {
> String authDecoded = new
> String(Base64Utility.decode(authEncoded));
> String authInfo[] = authDecoded.split(":");
> String username = authInfo[0];
> String password = authInfo[1];
>
> AuthorizationPolicy policy = new
> AuthorizationPolicy();
> policy.setUserName(username);
> policy.setPassword(password);
>
> message.put(AuthorizationPolicy.class, policy);
> } catch (Base64Exception ex) {
> //ignore, we'll leave things alone. They can try
> decoding it themselves
> }
> }
> }
>
> Kind of blows. I'll get a fix committed to trunk today. Will be fixed
> for 2.0.2.
>
> Dan
>
>
> On Friday 31 August 2007, Chris Campbell wrote:
>> Wow, nice one. Is there anyway I can get around this without
>> dropping Tomcat? Thanks again.
>>
>> chris
>>
>> Daniel Kulp wrote:
>>> OK. Figured this out. Tomcat is lowercasing everything when we
>>> query them from the HttpServletRequest. However, we're
>>> specifically looking for the "Authorization" header, not
>>> "authorization". Jetty seems to leave the case alone.
>>>
>>> Dan
>>>
>>> On Friday 31 August 2007, Chris Campbell wrote:
>>>> I do see an Authorization header
>>>>
>>>> Authorization: Basic Y2hyaXM6Zm9vYmFy\r\n
>>>>
>>>> Daniel Kulp wrote:
>>>>> There's been a couple people having issues with basic auth lately.
>>>>> Unfortunately, I haven't been able to reproduce any of it. :-(
>>>>>
>>>>> I THINK it's a client side thing. To check, wireshark the tcp
>>>>> socket and see if there is an Authorization HTTP header. If not,
>>>>> it's a client side issue. That said, the simple cases I've done
>>>>> all have worked fine. The header is there. My gut feeling
>>>>> says there is some spring config thing or policy thing or similar
>>>>> that is causing a conflict and is causing the header to no be
>>>>> written. I'll probably need a fairly detailed test case (client
>>>>> side + wsdl would be fine for now, shouldn't need server side
>>>>> stuff) that has all the configs, code, etc... I've tried
>>>>> several things and I'm always seeing the header, but I'm
>>>>> definitely not familiar enough with the policy stuff to get that
>>>>> completely configured to see if that's the issue.
>>>>>
>>>>> Dan
>>>>>
>>>>> On Friday 31 August 2007, Chris Campbell wrote:
>>>>>> Yes, http, and CXFServlet is running in Tomcat 5.5
>>>>>>
>>>>>> Fred Dushin wrote:
>>>>>>> Just to be sure, are you using HTTP?
>>>>>>>
>>>>>>> Also, are you using the Jetty HTTP destination on the server
>>>>>>> side, or Tomcat?
>>>>>>>
>>>>>>> On Aug 31, 2007, at 1:13 PM, Chris Campbell wrote:
>>>>>>>> The AuthorizationPolicy is null in the server interceptor.
>>>>>>>>
>>>>>>>> Now my client does this
>>>>>>>>
>>>>>>>> BindingProvider bp = (BindingProvider)client;
>>>>>>>> java.util.Map<String, Object> context = bp.getRequestContext();
>>>>>>>> context.put(javax.xml.ws.BindingProvider.USERNAME_PROPERTY,
>>>>>>>> "foouser");
>>>>>>>> context.put(javax.xml.ws.BindingProvider.PASSWORD_PROPERTY,
>>>>>>>> "foopass");
>>>>>>>>
>>>>>>>> My server interceptor does this (it is a Phase.USER_LOGICAL in
>>>>>>>> interceptor)
>>>>>>>>
>>>>>>>> // policy is always null here...
>>>>>>>> AuthorizationPolicy policy =
>>>>>>>> message.get(AuthorizationPolicy.class); String username =
>>>>>>>> policy.getUserName();
>>>>>>>> String password = policy.getPassword();
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Daniel Kulp wrote:
>>>>>>>>> On Thursday 30 August 2007, Chris Campbell wrote:
>>>>>>>>>> On client I have:
>>>>>>>>>>
>>>>>>>>>> java.util.Map<String, Object> context =
>>>>>>>>>>
>>>>>>>>>> ((javax.xml.ws.BindingProvider)client).getRequestContext();
>>>>>>>>>> context.put("username", "chris");
>>>>>>>>>> context.put("password", "foobar");
>>>>>>>>>>
>>>>>>>>>> How do I access that context on the server side in my
>>>>>>>>>> interceptor? I cannot seem to find where it is in the Message
>>>>>>>>>> object, or am I horribly misunderstanding something?
>>>>>>>>> With those keys, they wouldn't get to the server. You would
>>>>>>>>> need to use the BindingProvider.* keys.
>>>>>>>>>
>>>>>>>>> On the server side in an interceptor, you should be able to
>>>>>>>>> do: AuthorizationPolicy policy =
>>>>>>>>> message.get(AuthorizationPolicy.class);
>
>
>
