Chapter 7
</li><li ng-hide="isAuthenticated()">
<form class="navbar-form">
<button class="btn" ng-click="login()">Log in</button>
</form>
</li></ul>Supporting authentication and authorization on the client
Securing a rich client application, such as we are building here with AngularJS, is
significantly different to securing a traditional, server-based web application. This
has an impact on how and when we authenticate and authorize users.
Server-based web applications are generally stateless on the browser. We trigger a
round-trip request for a complete new page from the server on every action. So, the
server can compute the user's authorization levels on each request, and then redirect
to some login page, if necessary.
In a traditional, server-based web app, we would simply send the browser
to some login page, and then once login is successful, we redirect back to
the original page that was requesting the secure resource.Rich clients do not send full-page requests on each action. They tend to maintain
their own state and only pass data to and from the server. The server doesn't know
the current state of the application, which makes it difficult to implement the
traditional redirect back, after being sent to a login page. The client would have to
serialize all its current state, and then send it to the server. Then, after a successful
login, the server would have to pass this state back to the client, so that it could
continue where it left off.
Handling authorization failures
When the server refuses to process an unauthorized request, returning an HTTP 401
unauthorized error, we need to give the user an opportunity to authenticate, and
then retry the request. The request could have been part of some complex process on
the client, which has no URL to identify it. If we redirected to a login page, then we
would have to stop the current action, and the user would probably have to restart
what they were doing again after authentication.