I am developing a web application using rails and devise for the authentication. There are two types of users, one who are able to have multiple concurrent sessions (super) and the others who can only have a simultaneous session (normal). In order to implement this behaviour, I have added a new field on the User model to store the authentication_token (generated in the SessionsController#create). Also, I added a new filter to the ApplicationController which check if the stored token in the session is equal to the saved on the User model when it is a normal user. When it is not the same authentication token, we logout the normal user.
Now I am developing a new ionic mobile application which needs to login to the same rails application. However, in this case all user types can have multiple concurrent sessions. In order to do this, we would like to continue using devise (although we have also considered to use doorkeeper with password flow).
I am not sure about the best approach to get this. The main problem is to detect if we are accesing the API with the rails or ionic application. One approach is to add a parameter but I don't like to use a parameter in all requests. Another approach it is to use browser gem, but we can access the web from a browser in the mobile.
When we uses the rails application, we can use the same behaviour described above. Otherwise, I think it is not necessary to do anything because devise permits concurrent sessions by default.
Another posibility it is to use a new model to store the authentication token and its type (rails or ionic). If we are using the rails application, then we query the rails authentication token and override it (or create if it does not exist). On the opposite, we add the new authentication_token as a new instance related with the user model. With this behaviour we can manually control the expiration of the tokens and store more information (IP, browser...).
I am not sure about the best approach to achieve this behaviour. Thanks in advance.
Related
I'm adding oauth support (via omniauth) to a legacy Rails app. One complication to this app is that it uses subdomain-based multitenancy (for example account1.example.com, account2.example.com) and when registering our app with oauth providers, we need to specify full URLs for our callback — no wildcard domains allowed.
No problem, I'll just reserve oauth.example.com and register that.
The problem, though, is that our session ID cookies are set for account1.example.com and such. This makes CSRF protection break and also makes passing along the client's destination a lot tricker.
I can reconfigure our Rails app to set the session ID cookie on .example.com which fixes the CSRF issue. But! If I change that in production, it will invalidate every session for every user of our app. Not a showstopper, I guess, but pretty unfriendly.
So! As the only place I want to share cross-domain sessions is for our oauth actions — is there a way I can override the session handler on a per-controller basis?
Or would I maybe be looking to write a custom Rack middleware to override session handling for some requests…?
I have a Rails web application, and I want to build a JSON API as well so I can have mobile applications bound to it.
I've been reading a lot about it, and I don't get it why so many people prefer to activate authentication_token authentication instead of the normal authentication process that Devise offers us.
So, the question is: why use authentication_token ? Any performance reason ? Any security reason ? What is the best way to authenticate through an API ?
authentication_token is basically used to authenticate user from outside
i.e. say you sent user a email containing the activation link containing the token, so when he clicks the link, he directly gets logged in.
I have developed two rails applications app1 and app2, they have their own user controller and model and own ability.rb file and own devise gem. I want all of them share a common user controller and user model and ability.rb file so that anyone irrespective of the application goes through the same authentication system.
In this context I have read the post Rails: Devise Authentication from an ActiveResource call and How to add authentication before filter to a rails 3 apps with devise for user sign up and sign in?. But I am sorry, I could not figure out how to modify their individual routes.rb file so that all the authentication requests redirected to it and I would like to know if I have to make another application for only management of user for that purpose.
You might use omniauth gem to provide one application to manage its users through the second one (like a Facebook connect, for example). This app's sign in action would just be a redirect to the second one's sign in page.
In this case, however, you would have 2 different user tables, which might need synchronization, but for just a simple authentication that could work.
I have an rails app which relies on authenticating username/password entered to an external webservice. Rails app will not have a user model. When a user enters login/password and it makes a post request to check that login/password. External application will return back a cookie or token which can be used for subsequent requests made from rails app.
There is no User model in the rails app since all the users are stored in an external application.
Is there a gem which let me strictly do session management? I'm planning on storing that token in a session.
why not just create a sessions controller that saves the token into a session? I don't see a need for a gem.
something like
sessions[:token] = token
If you are dealing with a tokens that expire like facebook you can take a look at this
http://developers.facebook.com/blog/post/2011/05/13/how-to--handle-expired-access-tokens/
hope it helps
I might look at the way Michael Hartl does user sessions in his Rails tutorial. What you want is something slightly different, but you might be able to reuse some of what he did there. http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec-current_user
(It's also just a good tutorial to go through, regardless of your level of Rails experience.)
I'm creating a web service with Rails 3.1 that requires authenticated user accounts for creating/managing content. It also requires an authorization scheme for transient 'users' accessing the content - they do not have accounts, but will simply provide a password furnished to them by the user who created the content in their requests.
I'm thinking the best strategy is to keep the two separate, not creating accounts for the transient users, representing them as a separate model associated with the content.
My question is whether this is something I should build from scratch, or whether I can get sufficient leverage from one of the existing authentication gems for it. And if the latter, how I would go about configuring it to manage two different strategies.
If understand right, you will have regular account users and temporary account generated by users to share access to whatever.
I don't think something for this specific purpose exist.
My think using a solid and confortable Auth Manager gem will be require to secure both user and tmp_account access.
The reste, ie managing user-tmp_account relation and managing life time + right of the tmp_account, could be done without pain manually.
I personally build up something similar with the gem Devise.
Turns out I don't really need an authentication gem. While the implementation isn't finished, it appears a combination of Rails 3.1's has_secure_password and CanCan will work well for this.
Here's Ryan Bate's tutorial for using has_secure_password: http://asciicasts.com/episodes/270-authentication-in-rails-3-1
The idea is to use has_secure_password on both the User and Content models, and implement current_user such that it creates a transient User when the password is provided, setting a password property on that transient user.Then the implementation of the init method in CanCan's Ability class will verify the transient user's password against the content in a can block.