Comments (8)
This is ready to go in v3.0.0. Unfortunately, there's no way to force a specific plugin version in the Caddy build server so this introduces some breaking changes. Hopefully, it won't cause people a lot of problems.
Breaking changes:
Token-Claim
headers are URL encoded- Headers are now title-cased to line up with the docs and standard practice for HTTP headers
So for the above example you'll get
Token-Claim-Https:%2F%2Fauth.mydomain.com/app_metadata.authorization.user: o1ek
With strip_header
you get:
Token-Claim-App_metadata.authorization.user: o1ek
from caddy-jwt.
This is a problem for me as well. Auth0 now forces this namespacing of extra claims.
The offending character seems to be the slash (/). Would it be possible to convert all slashes to another character?
from caddy-jwt.
My bad, I had notifications turned off and didn't see this issue pop up. Should be an easy fix. Are these metadata fields useful? My initial inclination is just to drop any claim information with a / in it and not pass it via header.
from caddy-jwt.
Yes, these headers are extremely necessary for me. Auth0 forces any custom claims to be namespaced with a valid URL. (https://auth0.com/docs/api-auth/tutorials/adoption/scope-custom-claims)
My first thought was to simply replace any / with something like _ so that o1ek's example would change from
"Token-Claim-HTTPS://AUTH.MYDOMAIN.COM/APP_METADATA.AUTHORIZATION.USER"
to
"Token-Claim-HTTPS:__AUTH.MYDOMAIN.COM_APP_METADATA.AUTHORIZATION.USER"
That works as a valid header, but is still pretty ugly.
What would be really excellent would be a configuration option that would allow you to remove this namespace. Something like:
namespace_replace [namespace] [repacevalue]
This would be very flexible and allow for something like this:
from
"Token-Claim-HTTPS://AUTH.MYDOMAIN.COM/APP_METADATA.AUTHORIZATION.USER"
to
"Token-Claim-APP_METADATA.AUTHORIZATION.USER"
from caddy-jwt.
By the way, the app metadata thing seems to be something specific to the OP's app. Auth0 forces this namespace for any custom claims. For example:
{ email: "[email protected]", ... https://www.site.com/name: "Joe", https://www.site.com/state: "Indiana" }
These currently create headers like Token-Claim-HTTPS://WWW.SITE.COM/NAME
These headers work internally inside of Caddy (like in templates) but throw errors for some things like the proxy directive.
from caddy-jwt.
I was wondering about that, because I looked up the RFC for HTTP headers and /
is an allowed character in headers.
from caddy-jwt.
I think the right answer for this is probably to URL encode the claim key, perhaps with an optional directive to strip the URL from the header up to the last /
So with no configuration you would get:
Token-Claim-HTTPS%3A%2F%2FAUTH.MYDOMAIN.COM%2FAPP_METADATA.AUTHORIZATION.USER
With something like this:
mysite.com {
...
strip_header
...
}
You get:
Token-Claim-APP_METADATA.AUTHORIZATION.USER
from caddy-jwt.
That sounds great. The URL encoding would make a sane default, and the strip_header option would be even better.
The only thing that comes to mind with URL encoding is that some existing claims/headers might change on people with a Caddy upgrade. That might be a bit unexpected for people.
from caddy-jwt.
Related Issues (20)
- Multiple auth provider trust. HOT 4
- Refactor
- Possible minor error in a message (keys.go) HOT 1
- Validate multiple claims in an allow rule? HOT 1
- Loading cookie with alternative name HOT 7
- Set referer header on redirect HOT 3
- Protect an exact path HOT 4
- Response after succesful login: www-authenticate header: Bearer realm="",error="invalid_token" HOT 6
- Using placeholders for allow directive HOT 2
- Support for other Authorization header formats HOT 1
- JWT signed with H256 results in a 401 HOT 3
- Build fails with new module-based build server HOT 2
- Caddy's import path has changed
- Question about releases HOT 1
- Take http status code as a configuration value HOT 4
- Caddy 2 port HOT 36
- go mod errors with "version "v3.7.2" invalid" when requiring this package HOT 2
- Advice on secret file format for HMAC HOT 2
- allow access for groups HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from caddy-jwt.