3

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?

Hasith
  • 1,749
  • 20
  • 26
georgiosd
  • 3,038
  • 3
  • 39
  • 51
  • If you are using cookies on the server side, why don't you use them on the client side? – Manuel Leuenberger Sep 22 '12 at 19:33
  • If I understand ASP .NET Forms Authentication correctly, the cookie is encrypted - having code on the client that decrypts the cookie would make the application vulnerable. – georgiosd Sep 23 '12 at 09:43

1 Answers1

6

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.

Hasith
  • 1,749
  • 20
  • 26
  • That's great thanks. It's too bad there's no "real-world" application sample with BoilerplateJS - the plumbing is somewhat difficult. For example, I have no idea how you would centrally manage the rendered version of the control when a 401 happened so that you didn't have to re-write the error control every time. – georgiosd Sep 24 '12 at 16:47
  • After looking at this a little bit, I think it would make sense to create this using OAuth, with Sammy.JS' OAuth support. What do you think? – georgiosd Oct 03 '12 at 10:53
  • I havent used SammyJS before.. May be you should ask a separate question for a good OAuth library on Stackoverflow? Keep us updated too.. I'm not happy with what I have used on OAuth up until now... – Hasith Oct 04 '12 at 19:29