Open radek-senfeld opened 5 years ago
Thanks for the contribution. I like the idea but I think I might implement this a little bit differently. This method is limited in that you can only have one path and it doesn't take into account what some people want to do, which is allow access to a whole set of resources under a particular path.
What I'm thinking about doing instead is to introduce some reserved keywords using the existing allow
and deny
directives. If done right, people should be able to mix and match allow and deny to reach any kind of dynamic path protection.
For example, adding two new reserved keywords match:exact
and match:prefix
:
allow path match:prefix
And with a JWT with a path:
{
"path": "/protected/resource"
}
A prefix match would allow someone to access /protected/resource/1
. Setting it to match:exact
would only allow you access to /protected/resource
but not /protected/resource/1
. Likewise, a deny
rule could be used on a path to deny access to particular paths.
What do you think?
I agree fully. That would be elegant indeed.
I was dreaming about something similar for a few moments but then the Real life knocked and I had to whip out something functional to replace Nginx's secure_link feature. My itch is pretty much scratched. 🤣
My proposal is to have such a functionality now and replace it later. It's an minor patch and it won't be a problem to rip it off when the time comes.
I also cannot promise to invest too much time into this. Go is fun but so is my life.. :neutral_face:
Implemented as discussed would make allowroot
obsolete too, am I right?
I needed something like what @BTBurke suggested, so I went ahead and started working on it. I hope I'm not stepping on any toes. I think icb-/caddy-jwt@d0f8d4bd92b84c4e99d7b8582fe49fbf011e7337 is mostly complete, except for rounding out tests. I went with new config directives rather than reserved keywords in the existing allow
and deny
directives, but I'm happy to make whatever changes others think are appropriate.
Hi BTBurke, we found ourselves in a quite similar situation as described in https://github.com/BTBurke/caddy-jwt/issues/41.
I've implemented a simple path checking mechanism. Hope you like it! ;-)