Securing Your Application
Notifying the security service
The last piece in the puzzle is how to notify the security service, when new
items are added. In our implementation, we simply expose a method on the
securityRetryQueue called onItemAdded(), which is called each time we
push an item into the queue as follows:
push: function(retryItem) {
retryQueue.push(retryItem);
service.onItemAdded();
}The security service overrides this method with its own, so that it can react
whenever there are authorization failures, as given in the following code:
securityRetryQueue.onItemAdded = function() {
if (securityRetryQueue.hasMore() ) {
service.showLogin();
}
};This code is found in the security service, where the variable service is the
security service itself.
Preventing navigation to secure routes
Preventing access to secure routes using client-side code is not secure. The only
secure way to guarantee that users cannot navigate to unauthorized areas of the
application is to require that the page be reloaded; this provides the server the
opportunity to refuse access to the URL. Reloading the page is not ideal, because
it defeats many of the benefits of a rich client application.
While reloading the page to do security is not usually a good
idea in a rich client application. It can be useful, if you have a
clear distinction between areas of your application. For instance,
if your application was really two subapplications, each having
very different authentication requirements, you could host them at
different URLs, and the server could ensure that the user had the
necessary permissions, before allowing each subapplication to load.In practice, since we can secure what data is displayed to the user, it is not so important
to block access to routes using redirects to the server. Instead, we can simply block
navigation to unauthorized routes on the client when the route changes.