Even Unauthenticated user can see static contents of the page

[CatchSandeepVaid]

Consider this usecase: Page "A" should be accessed by an authenticated user. Page "A" has some static contents and some dynamic contents (which will come from backend-server). When a user navigates to page "A", the static contents appear immediately and when request is sent to load dynamic contents, the server may reply with 401 and hence login screen will be shown.

So the side effect is even an unauthenticated user sees the static content of the page which is not desired.

I think both authentication and authorization problems can be solved by listening to stateChange events and there checking for authorization and authentication.

[ScallyGames]

If I got you right this isn't a client but a server issue. Content security should never be handled on the client, because an attacker could easily bypass that.

=> you should change your server to reply with a 401 error instead of serving the static content, hence causing angular to react to the 401 immediately

[CatchSandeepVaid]

By static contents, i mean the ones present at client side. Example: Labels etc. So this isnt a server side issue..

[simison]

@CatchSandeepVaid resolve your data needs already at routes to prevent Controller loading before you've got the data: https://github.com/johnpapa/angular-styleguide#route-resolve-promises

And possibly implement user rights separately from backend for the client, but don't rely on it for security, as @Aides359 already said.

[witoldsz]

My solution to this issue was to create a custom directive which hides everything behind some "please wait" spinner. This directive was also listening for events with some name, like:

<div hide-until-ready="customer-data">
 .... the entire form
</div>

Now, inside the CustomerDataCtrl, when everything is fetched from server and all possible other promises are finally resolved, I publish the "customer-data" event and the spinner disappears showing everything including data loaded from server.

Simple and worked very well. Also there was no need to tinker with routes. It worked everywhere on the page, not only at route changes.

[Iraecio]

.config(['$httpProvider', function ($httpProvider) { $httpProvider.interceptors.push(['$rootScope', '$q', 'httpBuffer', function ($rootScope, $q, httpBuffer) { return { responseError: function (rejection) { var config = rejection.config || {}; if (!config.ignoreAuthModule) { switch (rejection.status) { case 401: var deferred = $q.defer(); var bufferLength = httpBuffer.append(config, deferred); if (bufferLength) $rootScope.$broadcast('event:auth-loginRequired', rejection); return deferred.promise; case 403: $rootScope.$broadcast('event:auth-forbidden', rejection); break; } } // otherwise, default behaviour return $q.reject(rejection); } }; }]); }]); change in line #62 http-auth-interceptor.js from if (bufferLength === 1) to if (bufferLength)

so ever response with 401, modal login can opem

@CatchSandeepVaid