search

fnakstad / angular-client-side-auth

One way to implement authentication/authorization in Angular applications
http://angular-client-side-auth.herokuapp.com/
MIT License
1.63k stars 346 forks source link

After I authorize a page /login can be opened again for sign in #20

Closed temadev closed 11 years ago

temadev commented 11 years ago

Page /login should be restrict for authorized users.

ok, and if i open something like /auth/twitter this will authorize me again.

fnakstad commented 11 years ago

Alright, this is fixed. Thanks for posting! As for the second suggestion, you can change the access level of the auth/twitter route on the server-side to anon if you want to deny logged in users. However, in the example I think I'll just keep it the way it is since it's not really a problem if the user reauthorizes himself.

danielabar commented 11 years ago

Just my two cents worth re: authorized user being able to get back to the Login page. It did used to work this way but then the following would occur:

  1. User logs in successfully
  2. User clicks Browser back button
  3. System detects user is logged in and redirects them to logged in view
  4. Repeated for as many times as user clicks Browser back
  5. Unless user realizes there is logout link, they will be stuck in this redirect loop

The problem with this is users generally expect Browser back to take them back to previous page, and they could get frustrated/confused otherwise. In a desktop, not so bad because they can close the browser tab. But I tried this on mobile and was totally stuck, no way to get out of it except killing the browser app. Even then next time I opened browser was taking me back to logged in view. Had to delete my cache and cookies to get out of it. (compounding this issue, entirely my fault, my responsive nav wasn't behaving correctly so user could not get to logout link).

My preference would be if authorized user is allowed to view login page.

fnakstad commented 11 years ago

That's a really good point, amd I'm a little torn on this. It can be easily rectified by changing the accessLevel of the login page, but I think I'll keep it as it is in the example app. Instead I've been thinking of having more detailed error messages when someone tries to access a route they don't have permission to see. That way we can provide the user with more specific feedback about why he can't see the route he's trying to access.