Hacker News Reader

Comment by tyleraldrich | Hacker News Reader

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.

View on HN

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}`?

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.

I will look into this more and come back with what I figure out later on. Thanks.

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...

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.

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.

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)

Reply on news.ycombinator.com