3 ms·

But... that's not really something you _have_ to avoid. Check permissions, if they fail the test -> http401 (for an API) or some user-friendly redirect. Somethi

But... that's not really something you _have_ to avoid. Check permissions, if they fail the test -> http401 (for an API) or some user-friendly redirect. Something similar to this is how things work without JWT currently, so it's only a problem if you make it one.

madeuptempacct 8y ago
You seriously think making a redundant call or wrapping every. single. controller into a try-catch is better than having claims pulled out in a request pipeline (before even touching the controller) and doing `if(hasAccess){do thing} else {unauthorized}`?
- CiPHPerCoder 8y ago
  It sounds like you're arguing from a very specific mental model of an ACL workflow. In my CMS, I had support for granular permissions. So you could do this: if ($user->can('update')) { if ($postData) { $this->processUpdate($postData); } // display edit form } elseif ($user->can('read')) { // read-only } else { return error_403_condition(); } JWT wouldn't have helped much.
  - madeuptempacct 8y ago
    I will look into this more and come back with what I figure out later on. Thanks.
- X-Istence 8y ago
  That looks similar to a try/catch... You just called it if/else. Also, why can't you make the database request in the request pipeline, right before that "if(hasAccess)" statement. You don't need JWT for this... You are already wrapping all of your controllers...
- patates 8y ago
  If your controllers are asp.net mvc controllers you can decorate them with permission attributes (see the relevant docs for your version). Pretty sure most frameworks have a way to structure your code for permission checking.
- andrewingram 8y ago
  If you're not willing to risk users making requests with stale permissions (which is a risk you shouldn't accept lightly), then JWT requires that you hit something at the start of processing every request anyway. It can either be a token blacklist service (really just a key-value lookup), or it can be an auth/permission service. The auth service/query is higher per-request overhead, but it also keeps things simple. And simple is what you want unless you're dealing with ridiculous scale.
- tyleraldrich 8y ago
  I don't know what you're working with, but you don't need a JWT to figure out access in the request pipeline. A session ID does the same thing and allows you to associate a session to a user, and most frameworks are capable of doing this already (e.g. django has middleware that can do this)

madeuptempacct 8y ago

You seriously think making a redundant call or wrapping every. single. controller into a try-catch is better than having claims pulled out in a request pipeline (before even touching the controller) and doing `if(hasAccess){do thing} else {unauthorized}`?

CiPHPerCoder 8y ago
It sounds like you're arguing from a very specific mental model of an ACL workflow. In my CMS, I had support for granular permissions. So you could do this: if ($user->can('update')) { if ($postData) { $this->processUpdate($postData); } // display edit form } elseif ($user->can('read')) { // read-only } else { return error_403_condition(); } JWT wouldn't have helped much.
- madeuptempacct 8y ago
  I will look into this more and come back with what I figure out later on. Thanks.
X-Istence 8y ago
That looks similar to a try/catch... You just called it if/else. Also, why can't you make the database request in the request pipeline, right before that "if(hasAccess)" statement. You don't need JWT for this... You are already wrapping all of your controllers...
patates 8y ago
If your controllers are asp.net mvc controllers you can decorate them with permission attributes (see the relevant docs for your version). Pretty sure most frameworks have a way to structure your code for permission checking.
andrewingram 8y ago
If you're not willing to risk users making requests with stale permissions (which is a risk you shouldn't accept lightly), then JWT requires that you hit something at the start of processing every request anyway. It can either be a token blacklist service (really just a key-value lookup), or it can be an auth/permission service. The auth service/query is higher per-request overhead, but it also keeps things simple. And simple is what you want unless you're dealing with ridiculous scale.
tyleraldrich 8y ago
I don't know what you're working with, but you don't need a JWT to figure out access in the request pipeline. A session ID does the same thing and allows you to associate a session to a user, and most frameworks are capable of doing this already (e.g. django has middleware that can do this)