Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sending badRequest when unauthorized should have been sent #9

Open
anasyb opened this issue Mar 3, 2015 · 6 comments
Open

Sending badRequest when unauthorized should have been sent #9

anasyb opened this issue Mar 3, 2015 · 6 comments

Comments

@anasyb
Copy link

anasyb commented Mar 3, 2015

ember-simple-auth expects an unauthorized access (401) to be sent when an issue happens with the auth. At the moment sails is sending a badRequest (400).

Why?

  • In response to receiving 401, simple-auth "invalidates the session and reloads the application" ref.

Fix

  • update AuthController.js to call res.unauthorized instead of res.badRequest
  • include an api/responses/unauthorized.js file
@mgenev
Copy link
Member

mgenev commented Mar 3, 2015

good call, feel free to submit a PR or I'll adjust it when i get back to Seattle

@Globegitter
Copy link
Member

@anasyb @mgenev @kriswill What do you think. Should we include the unauthorized.js already in sane core or better here in the addon?

@kriswill
Copy link
Contributor

kriswill commented Mar 3, 2015

I think it's a good to have it as the base sails project. Someone might have some other rule that they use to determine authorization besides roles, like resources owned by a user, etc.

@anasyb
Copy link
Author

anasyb commented Mar 4, 2015

It might be the case people would find a use for it other than that associated with authentication, but I don't believe that's the intent of it. SO has a summary on that and IEFT states clearly it should be basically only used when credentials are provided but there is a a problem with them... the server asks the user to retry. In response simple-auth would invalidate the session and transfer the user to login. This behaviour shouldn't IMHO happen in other scenarios like the one mentioned above: resources not owned by a user. For those the forbidden 403 exist which says: I know exactly who you are and you're not allowed, don't even try!

That being said I don't know what's the answer to your question @Globegitter... I would personally put it here in sane-auth.

@kriswill
Copy link
Contributor

kriswill commented Mar 4, 2015

@anasyb If the ONLY use of 401 is specifically for authentication, then it does belong to the addon project.

@Globegitter
Copy link
Member

Yep I think I will plan it in for the auth addon for now. Can still change in the future if necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants