kraken-example-with-passport icon indicating copy to clipboard operation
kraken-example-with-passport copied to clipboard

Bypass secure routes

Open rodmoreno opened this issue 8 years ago • 9 comments

In this example using the 'auth' library routes that require authentication are specified, in this case they: /admin & /profile, but if I have the role of 'user' and there the route: /admin/whatever I can get on that route.

Sorry for my english

rodmoreno avatar May 17 '16 06:05 rodmoreno

Hi @rodmoreno. Thanks for taking the time to file this issue. I'll get back to you once I'm able to begin looking into it.

grawk avatar May 18 '16 15:05 grawk

Hi, I have been dealing with this bug myself and the only solution that I have found to date is to specify every possible route to be blocked. Personally, I don't think that specifying each route is the best solution, especially when you generating pages based on some id from a database (for example, '/admin/profiles/5bd2c68c9b3062a301790e3'). I have been trying to get something working with regex patterns, with no luck (this regex : /\/admin.*/ matches all /admin routes, but does not work in this context). Perhaps someone could shed a little more light on how the 'auth' object gets used? It does not seem to follow the express routing pattern. Any insights would be appreciated.

quarterpi avatar Jan 13 '17 17:01 quarterpi

Forgive my ignorance, but I can't find a reference that explains this line of code if (!auth[route]). To be more specific, the !auth[route] part has me scratching my head. Can someone please point me to where I can learn the syntax rules for this operation? (I have been able to gather from running this code in the debugger that it is essentially comparing the strings stored in auth against route, and returning either true or false based on the presence or absence of a match (true if no match is found, otherwise false.). I would like to understand this line of code better as I have never encountered it before.) Thanks in advance.

quarterpi avatar Jan 13 '17 18:01 quarterpi

@quarterpi It's a logic switch and you've defined the behavior perfectly. There is nothing extraordinary about this pattern.

grawk avatar Jan 13 '17 18:01 grawk

The existing whitelist/blacklist approach to auth in this app is very rudimentary and doesn't really scale to the examples mentioned by you. You might instead go with a regex pattern in the middleware configuration itself. Please see: https://github.com/krakenjs/kraken-js/wiki/Using-krakenjs-middleware-config-for-whitelisting-and-blacklisting-routes#whitelisting and https://github.com/krakenjs/kraken-js/wiki/Using-krakenjs-middleware-config-for-whitelisting-and-blacklisting-routes#blacklisting

Someone can file a PR to upgrade from the naive approach currently taken. It is not a high priority for the maintaining team.

grawk avatar Jan 13 '17 18:01 grawk

To correct myself and answer my own question, the line of code that reads !auth[route] compares all of the keys in auth with the route requested. That also explains why my regex wasn't working, since this method does not use the usual express regex routing pattern and does a string string comparison. I am currently working on a solution. I will post it if I find one that I feel is suitable.

quarterpi avatar Jan 13 '17 18:01 quarterpi

We'd be grateful if you either post your solution or open a PR to bring it into this example!

grawk avatar Jan 13 '17 18:01 grawk

@grawk thanks for your response. I finally realized the obvious. Thanks for the links you provided.

quarterpi avatar Jan 13 '17 18:01 quarterpi

@grawk I will if I get something satisfactory.

quarterpi avatar Jan 13 '17 19:01 quarterpi