When defining the routes of an AngularJS application, a new property called access added to each route to indicate what level of access each route should have. This is based on the client-side authorization method described here here .
The .config block will look like this:
app.config(['$routeProvider', '$locationProvider', '$httpProvider', function ($routeProvider, $locationProvider, $httpProvider) { var access = routingConfig.accessLevels; //Initialize with asynch data instead $routeProvider. when('/home', { templateUrl: '/Templates/home.html', controller: 'homeController', access: access.user }); $routeProvider. when('/private', { templateUrl: '/Templates/private.html', controller: 'adminController', access: access.admin }); //...more route configurations }]);
Leaving the basic logic of the approach aside, I just want to know how we can initialize the access variable with some asynchronous data so that it is available when defining the access property for each route? This is necessary because only the server knows the list of access levels.
Although there are answers to Initialize an AngularJS service with asynchronous data based on making a promise in the service and using resolve in the route configuration, it won’t work in my case, since I need the asynchronous call to be resolved before the route configuration is determined, since the access property depends from asynchronous data.
What options do I have? Is there any way to use the promise / deferred method?
Any suggestion would be greatly appreciated.
EDIT:
To describe that access executes a bit, it is populated with a separate module called routingConfig . In an approach, a user can belong to a specific role, which is defined as a binary number. For example, for example: 001, user: 010, admin: 100 (etc.).
The access level for any route will again be a binary number determined by the OR operation of all user roles that are allowed to access it. So, for example, if access to the user access level can be obtained through the user roles user (010) and admin (100), its bit mask will be 110. Later, to check access to the route, we can perform the operation AND the user role and access level to find out if it is allowed or not. Details can be seen in the link above.
Please note that the data at the end of the server is still protected by more complex algorithms, therefore, even if this logic is controlled on the client side, such a user will be able to see the markup of any unauthorized page.
Again, back to the problem in the hand. Like access , which is used as a property in the config block, it is initialized with asynchronous data coming from the server. This data may look like this:
accessLevels : { 'public' : '111', 'user' : '110', 'admin': '100' }