Should it be "Authorization"? z, not s. If s is right for some specific 
environments, we can add an additional step to check "Authorisation" if getting 
"Authorization" header failed.

-----邮件原件-----
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] 
发送时间: 2018年1月16日 18:52
收件人: dev@ofbiz.apache.org
主题: Re: svn commit: r1813679 - in /ofbiz/ofbiz-framework/trunk: ./ 
framework/common/groovyScripts/ 
framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/

Thanks Deepak,

Ha indeed, I see your point now.

Sorry for the confusion!

Jacques


Le 16/01/2018 à 11:30, Deepak Dixit a écrit :
> Thanks Jacques for detail,
> but I think name is not always Authorisation in code we are having 
> lots of request.getHeader usage and its breaks their usage.
> I'll confirm and reply here (just for reference.)
>
> Need to backport this to 17.12 as well.
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
> www.hotwax.co
>
> On Tue, Jan 16, 2018 at 3:26 PM, Jacques Le Roux < 
> jacques.le.r...@les7arts.com> wrote:
>
>> Le 16/01/2018 à 09:53, Deepak Dixit a écrit :
>>
>>> +                return super.getHeader("Authorisation");
>>>> I think this should be
>>> return super.getHeader(name);
>>>
>> Thanks Deepak,
>>
>> Actually let me explain the context here (maybe not for you but at 
>> large) In the case of ExternalLoginKeysManager, it's always 
>> "Authorisation". It's explained there 
>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorizati
>> on https://en.wikipedia.org/wiki/Basic_access_authentication
>> And it's the only usage of the wrapper so far.
>>
>> Note that in the case of JWT token used in OAuth 2 you normally need 
>> to use a bearer token
>> https://www.google.fr/search?q=http+authorization+header+bearer&ie=UT
>> F-8 But in the case I committed it was not necessary (it's not OAuth 
>> 2, just a JWT token) and I must say I got issue trying to encode 
>> things with it
>>
>> Anyway you are right, why not using name there, it will not change 
>> things, and the wrapper idea could be then reused/refactored when 
>> adding other related features, will do :)
>>
>> Jacques
>>
>>

Reply via email to