Initialization data before $state starts working

[colthreepv]

I'm having a quite-common issue, judging by the issue tracker of this project.

A company website needs to validate an user before displaying a page/resource, this is selectively done with $state.resolve, but i need a global version of this.

Global --> because it's the login information.

Quick sumup of the app:

• User has a token written into localStorage
• a loginService based off fnakstad's brilliant work, all routes have an accessMask, but this accessMask to be valid needs to wait for...
• ...an $http POST featuring the previously read token

  Requirement

That solution to be robust needs to work on all routes, because i don't know where the user tries to access on his first request. At the state of developing we have already ~40 states, it's not really a clever idea put 40 resolve(s).

Possible Ideas

I was looking carefully to the $stateChangeStart event, it can be prevented, generating a rejected promise. What i would really want is to delay the resolving of this promise (using .then!), not reject it completely.

This resolve would be run only on the first $stateChange request of the AngularJS Application, since after this we'll have the informations we need.

I'll update this post if i get any more valid ideas :smile:

[colthreepv]

another possible idea

Create a father, abstract, state with a resolve with the required info. All the other states have to be child of this State, it should imply no problems whatsoever, just a some find/replace in the existing code!

Will try that soon© :soon:

UPDATE: i've elaborated this idea as a project, mrgamer/angular-login-example, works :smile: It will require quite a few documentation because it's more a logic project than code one.

[laurelnaiad]

I'd recommmend https://github.com/witoldsz/angular-http-auth and/or https://github.com/fnakstad/angular-client-side-auth

[colthreepv]

Those projects are really cool, but they are not what i'm looking for: they are for resource-based authentication.

I need something that is state-based, i'll explain a little better, hoping to be concise:

My states that requires server-data already haves resolve(s) and they have a redirect system similar to angular-client-side-auth, using $stateChangeError. But some states doesn't require "resources", for example a website that i would define robust wouldn't let an already logged-in user to access the registration page. That can happen with an AngularJS application, the flow goes this way:

• User closes browser or directly types mydomain.com/register
• AngularJS gets downloaded and bootstraps, it reads an userToken from the localStorage, but it doesn't know yet if the token has been revoked, or which permissions this user has (note: different permissions!).
• /register $state gets triggered, it doesn't require any remote resource.
• loginPromise gets resolved, now i know that the user is already registered, but AWW.. SNAP! the user is already landed on the page..?!!!

The quick'n dirty solution would be change the location when the promise gets completed, but.. i'm looking for a more robust solution.

[laurelnaiad]

If your resources are protected by serving 401/403 errors when not authenticated/authorized then what's left is tailoring your UI (including the selection of appropriate states and login screen triggers, which is what those projects do). You could of course do it entirely differently using state resolve features, but ultimately security comes from the server.

[timkindberg]

Your idea of one grandfather state is what I would do. It's perfectly suited for your scenario.

[colthreepv]

The grandfather idea actually works, example here: mrgamer/angular-login-example. Closing this :+1: hope to be useful to someone having my same headache.