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