Yes, that's correct, within the limits of what "being in a release" means
for a community module, since they are only built along nightly builds, but
are not packaged along with official releases.

Cheers
Andrea

Il giorno mer 5 dic 2018, 23:51 Thomas <tl...@technoeclectic.com> ha
scritto:

> Does this mean it won't it into 2.14.3 but will be in the 2.15.0 release
> in February?
>
> On Wed, Dec 5, 2018 at 1:25 PM Andrea Aime <andrea.a...@geo-solutions.it>
> wrote:
>
>> I have no reason to backport them, they were done for a pilot project
>> that will never use the stable series. But you can backport, if you want of
>> course :-)
>>
>> Cheers
>> Andrea
>>
>> Il giorno mer 5 dic 2018, 18:49 Thomas <tl...@technoeclectic.com> ha
>> scritto:
>>
>>> I'm working on 2.14.x.  The changes haven't made it into there yet.  But
>>> I can see they are in master.
>>>
>>> When might the changes make it into 2.14.x?
>>>
>>> ~Thomas
>>>
>>> On Wed, Dec 5, 2018 at 12:24 AM Andrea Aime <
>>> andrea.a...@geo-solutions.it> wrote:
>>>
>>>> Hi Thomas,
>>>> some time ago I added some places extracting the bearer token from the
>>>> headers,
>>>> but believe that just landed on the developer branch (aka master).
>>>> There might be more places
>>>> that need that, but wondering if you might be looking at a different
>>>> branch.
>>>>
>>>> Mind, pull requests are accepted first on the master (developer)
>>>> branch, once that gets merged,
>>>> subsequent backports PR are welcomed too.
>>>>
>>>> Cheers
>>>> Andrea
>>>>
>>>> On Tue, Dec 4, 2018 at 10:48 PM Thomas <tl...@technoeclectic.com>
>>>> wrote:
>>>>
>>>>> I'm working with integrating my work's oauth service with geoserver.
>>>>> Upon testing the github extension as well as the oauth2 core, I think I 
>>>>> may
>>>>> of found a bug.
>>>>>
>>>>> When a request is made,  GeoServerOAuthAuthenticationFilter:doFilter
>>>>> is eventually called.  The filter checks the request parameter for an
>>>>> access token and if it doesn't exist it checks the request for a bearer
>>>>> token in the Authorization header.  If the token exists in one of those 
>>>>> two
>>>>> places, doAuthenticate is called and it in turn
>>>>> calls getPreAuthenticatedPrincipal.
>>>>>
>>>>> The function getPreAuthenticatedPrincipal  attempts to get the token
>>>>> from the query parameter but doesn't try to get it from the Authorization
>>>>> Header.  According to the RFC for OAuth 2 Bearer Token usage, the resource
>>>>> server (Geoserver), should support this.  A link and a snippet from this
>>>>> page is below.  This causes an issue for our web client which sends the
>>>>> token in the Authorization Header.
>>>>>
>>>>> It looks like I could just extend the class
>>>>> GeoServerOAuthAuthenticationFilter and put my fixes in there.  But it 
>>>>> seems
>>>>> it would be more beneficial to submit a pull request.  The changes would 
>>>>> be
>>>>> about 3 lines.
>>>>>
>>>>> Is there any issue with me doing this?  I realize the oauth2 and other
>>>>> community extensions aren't really maintained unless a volunteer does it.
>>>>>
>>>>> https://tools.ietf.org/html/rfc6750
>>>>> section 2.1 Authorization Request Header Field says
>>>>>
>>>>>
>>>>> Clients SHOULD make authenticated requests with a bearer token using
>>>>>    the "Authorization" request header field with the "Bearer" HTTP
>>>>>    authorization scheme.  Resource servers MUST support this method.
>>>>>
>>>>> _______________________________________________
>>>>> Geoserver-devel mailing list
>>>>> Geoserver-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Regards, Andrea Aime == GeoServer Professional Services from the
>>>> experts! Visit http://goo.gl/it488V for more information. == Ing.
>>>> Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito
>>>> 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob:
>>>> +39 339 8844549 http://www.geo-solutions.it
>>>> http://twitter.com/geosolutions_it
>>>> ------------------------------------------------------- *Con
>>>> riferimento alla normativa sul trattamento dei dati personali (Reg. UE
>>>> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>>>> precisa che ogni circostanza inerente alla presente email (il suo
>>>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>>>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>>>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>>> This email is intended only for the person or entity to which it is
>>>> addressed and may contain information that is privileged, confidential or
>>>> otherwise protected from disclosure. We remind that - as provided by
>>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>>>> e-mail or the information herein by anyone other than the intended
>>>> recipient is prohibited. If you have received this email by mistake, please
>>>> notify us immediately by telephone or e-mail.*
>>>>
>>>
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to