Looking for a JSON SessionsController? (R: Here's some code!) about simple_token_authentication HOT 8 CLOSED

Hi @dnlserrano!

You're right about expecting a 401 Unauthorized response when trying to sign out with incorrect credentials (email/authentication token). It's also what I would expect (or a 404 Not found if you consider that the session to be destroyed wasn't found and that unauthenticated users should not be given any extra information about current sessions, but that's not the point).

When the error occurs, current_user is not set, because both token authentication and Devise authentication failed. That's correct since the credentials were intentionally wrong. Now, the question is: why doesn't that lead to a 401 Unauthorized response? Usually, the request gets unauthorized after the Devise authentication failure.

I'm sorry for being short of time to investigate this properly, but I have an idea: Is authentication required by Devise to acceed the Devise::SessionsController#destroy action?

If it wasn't, that could explain why the request doesn't get unauthorized after the authenticate_entity! call: if on the first hand the request doesn't get unauthorized, and on the other hand the current_user is not set (because there is no reson for it to be set), then the @user variable being nil is a case that must be handled to avoid the server errror.

Does that make sense to you? Could you give it a try?

Regards!

from simple_token_authentication.

Hi again, @gonzalo-bulnes, sorry for the late reply.

What you suggested did in fact work, i.e., I am now checking if the user is signed in when performing the destroy action in my SessionsController. However, this does not seem to be the best option, since from what I could grasp from the Devise source code, authentication is skipped only on the new and create actions (which makes sense). It would not make sense if they allowed anyone (not signed in) to logout a user. I will have to look deeper into this, but for now it will just have to work with that.

Also, I have posted my custom RegistrationsController and SessionsController here, if anyone is interested. Props to @gigacardoso who helped me dig into the Devise source code, which led me to solve some problems, particular this append_before_filter. I'm still missing unit testing to the SessionsController, but from what I could check from curls, everything is working as it is supposed to. Suggestions/comments/questions are more than welcome.

Note: My models are separated in User (profile information, like age, username, etc.) and Login (authentication stuff, like email, passwords, authentication token, etc.).

Best regards!

from simple_token_authentication.

@dnlserrano Thanks for sharing! I've updated my original gist discussion for others to benefit from yours. : )

from simple_token_authentication.

@gonzalo-bulnes Thanks so much for posting this gist. I'm a complete rookie and this is most helpful. I've searched through SO many devise based API implementations...

A couple of questions:

1. Can you post the route.rb file? I assume you've reconfigured the controllers? e.g.
   devise_for :users, :controllers => { :registrations => "registrations", :sessions => "sessions" }
2. Can you also post the model file for completeness? I think login.rb.
3. Where do the .json.jbuilder files belong? In /app/views/registrations/ and /app/views/sessions -or- in app/views/devise/registrations/ and app/views/devise/sessions. I've actually tried putting them in both locations but am thrown a missing template error.
4. When I try to sign in a user I receive an error "undefined local variable or method `current_login' for #SessionsController:0x3517c80". Where is current_login defined? Do I need to define it somewhere?

many thanks!

from simple_token_authentication.

Hi @djedynak! Let's here redirect great part of the thanks to @dnlserrano who enhanced significantly the original controller example. Most of what you got is part of his work. You're welcome anyway.

I'd have to take a look at the gist again to be sure not to misslead you; but as a quick begin of response to your question 3: do notice that using .jbuilder templates certainly requires a dedicated gem. Before looking at their paths, check if the error message includes :jbuilder in the list of acceptable formats.

More of that as soon as I can refresh what I remember of the gists. Regards!

from simple_token_authentication.

Thanks for the kudos @gonzalo-bulnes.

@djedynak as to your questions I will try to answer them as good as I can:

1. I've updated my original gist. Here you go.
2. As in 1., the gist is now updated with the User and Login models. Here you go.
3. As @gonzalo-bulnes said the .jbuilder files are dependent on the jbuilder gem. Once you have it setup in our Gemfile, all should be good. Also, the files are supposed to be placed at app/views/registrations, like you suggested.
4. Notice that in my Login model, I have the devise directive, which tells Rails that my authentication model is Login. What happens is Devise will create a current_{resource_name} method, which returns the current logged in authenticatable entity. In my case, the {resource_name} is login because I defined my Login model as the Devise authenticable entity. In case you do this in your User model, then (because you instructed authentication in your User model), you will only be able to call current_user.

Regards,
Daniel

from simple_token_authentication.

Many thanks to you both! Again, super helpful.

Just one more quick question. Why the separation of the user and login models given they are mapped one to one?

Thanks!
Dave

from simple_token_authentication.

@djedynak The separation of the models User and Login is totally optional; it aims at increasing maintainability through separation of concerns (see this note).

from simple_token_authentication.