Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
With BoilerplateJS setup, what is the recommended way to handle authorization and authentication?
Obviously on the server-side you’d check cookies etc to know who’s logged in. But, on the client, how would you know if a user is logged in and what their username etc are?
I will share how this was done in one of the projects that used BoilerplateJS. On this project we used OAuth 2.0 for authentication.
We had a separate login page which was NOT using BoilerplateJS OR complex JS. The reason to keep it separate is that authentication may depend on URL redirection, which is not handled best with JS.
Once user is correctly authenticated, we receive the auth_token of the server session and store it as a JS variable. We used ‘settings’ of global Boiler.Context to store this token. Since settings are inherited to child contexts, we were able to access it from any where.
For authorization purposes, then we then downloaded a simple ACL for the logged user that contains the authorized access keys. These keys were just for client validations to show/hide controls. Real authorization was performed on backend services.
We wanted the BoilerplateJS components to be fully self contained including authentication of it. Therefore if a particular component’s viewmodel receive an unauthorized 401 HTTP response from server (either not logged-in OR or session expiry) we rendered component differently there, without redirecting user to the login page.
Since we did not redirect, user was able to make use of other information on the page even the BoilerplateJS component was not actively displaying it’s content. We had a rendered some error information on the component with a link to re-login.
Handling of this was done via a generic error handler we created. From component.js, we pass a error callback function to our viewmodel (you may have this on context itself too). This callback function is used by the viewmodel to notify any error occurred within it. In the case of 401 HTTP code, this handler is invoked asking component.js to render UI with error information and a link to re-login.
User clicks on the re-login URL to get back to the login page. This URL contains a back reference to the originated URL, such that user is able to get to the page where he was after authentication.