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.
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.
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.
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
···
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.ithttp://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.
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.
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.
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.
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.ithttp://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.
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
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.
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.
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.
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.ithttp://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.
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
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.
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.
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.
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.ithttp://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.
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.
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
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.
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.
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.
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.ithttp://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.
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.
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
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.
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.
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.
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.ithttp://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.
