timruffles/auth.md

## auth.md

      
    Raw
  

              auth.md
            
          
    Proper client-side auth

At the mo we have the boilerplate project's getCurrentUser() method, that synchronously returns the user. If it's not fetched yet, bad luck!
This isn't good. We should handle:

waiting to confirm if we're logged in or not. (unless we block the rest of app startup till we know, not too much of a UX cost)
currently this happens at startup
we could embed this on app startup, as we generate the index.html client-side now, e.g window.USER = { id: 15, name: "bob... }
expiration (i.e starting to get 401 Unauthorized responses)
this doesn't happen very often, and we shouldn't over-engineer a solution

I see a few options:
Ignoring the problem

Especially if we embed the JSON into the page, we could just assume the user will be logged in when we're on a viz view.
401s/403s can be handled by standard error UI.
## Fixing it
If we fix it, it'd be nice to handle a app-wide handler that picks up 401s. Then it can pop-up login in a modal, allow user to login again, and keep going.
Then we'd be wise to model that the user is a evolving quantity, that may move from logged in to out and back again.
Observable

Auth.user() returns an Observable<guest | authorizedUser>.
If we do end up handling everywhere, this at least gives us a nice way to compose these state changes.
This is easy to compose with a capacity query. So we can say this.granted = Auth.user().map(u => Access.can(u.capacities, "read", "report")), and perhaps write a async filter (much like angular 2's) to use this status in the view (`ng-if="$ctrl.granted | async")
Mutable

We have a mutable user object, whose .guest properties (& others) will toggle on and off as things change. Easy Angular integration (<a href="/login" ng-if=user.guest)`)
It's not too elegant, but since most of the use-cases for user status are toggling on/off UI components this might be a simple option.