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.
Related
In my Rails app, we use Devise gem for authentication and authorization. But for viewing some of the pages clients want a second password to be entered who will act like super users. This is not an Multi-Factor authentication request, but a kind of One Time Password (OTP) for a given set of pages/resources, just that the OTP will be static.
Devise does not provide this feature. Googling hasn't helped. Any idea how could this be achieved?
This sounds like a bit of an anti-pattern. Why not have an additional field on User that denotes if the user is a super user or not?
This has the benefits that:
there is no password to remember and distribute
super users have one less step to perform
you can easily remove users from this group, if needed
you don't need to build a secondary login form/page
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.
I have a site build on rails that provides XML version of all relevant pages. Additionally, it has HTTP authentication.
My plan to handle login for the mobile app is to post the username/password to the login page and, assuming I get a good response, I'll set global variables variables for user and password and make all requests to protected data with the validated user/pass in the header. Logout will just wipe wipe the user/password global variables.
Is the best way to handle this or am I making things more difficult than they need to be?
yes, although my advice is to use a gem like Devise or authLogic as rolling your own authentication is fraught with potential problems.
There are different ways you can include external libraries for Rhodes, including RubyGems and custom extensions. Please refer to the link below for information.
http://docs.rhomobile.com/rhodes/extensions
I am building an api for others to use. This is a simple enough Json request the user passes as some data and we pass some back.
What I would love is to secure our api and have some sort of user system where we can turn users on and off and we can log how many requests each user makes.
What would be the best way to do this in Rails? I don't want it to slow down the request. I can see ways of doing it using devise maybe but would be great to hear other people's opinions.
Thanks
Another way is to use 3scale (http://www.3scale.net) - it's free up to a traffic cap but handles all the key management, users, documentation etc. and there's a ruby library which you can drop into your code if you're using rails. (other libs are here: https://support.3scale.net/libraries).
I've done this before using the Token Authentication capabilities of devise (see https://github.com/plataformatec/devise ).
I found the following setup works:
Create a user account for each api user.
Configure devise for token authentication
Set the Token Authentication configuration to require the token to be submitted with each request.
This will allow you to enable and disable individual users as well as to track every request back to the api user that made the call.
If you're really interested in tracking usage you may want to consider also creating a database table where you track all api requests. This can be setup to belong_to the users table so that you easily find all requests from different users (e.g., #user.api_requests).
The count of all requests made by a user would be:
#user.api_requests.count
# or use a where clause to find how many of each type
#user.api_requests.where("api_request_type = ?", 'SomeAPICallType').count
One final note -- I recently used the Grape library for building out an API. I thought it was pretty well done and it worked great for our needs. I especially like the ability it provided to version APIs. Details are here: https://github.com/intridea/grape/wiki
I am using a single sign on authentication method which sits in front of my rails application. Access is denied entirely until signed in to the businesses single sign in service.
I am now wanting to lock some controllers down to a select group of administrators and am wondering what the best way to do this will be.
Should I be creating an administrator controller for managing who has access and then checking the signed in users credentials against this tabl
Take a look at CanCan
You could use Declarative Authorization described here:
Declarative Authorization
But Cancan is made to be really easier.
Ben
Authority
Take a look at my new gem, Authority. Its access control is done with plain Ruby methods, so you can use absolutely any logic that you know how to do in Ruby.
Works fine with Single Sign-On
The situation you describe was the original one we made it for: we already had a SSO app that takes care of the CRUD for creating users and assigning roles, like "Carla is an Administrator in App X; in App Y she is both a Worker and a Salesperson."
When Carla tries to access App Y, if she is signed in, it tells App Y "here is Carla: she's signed in, and she has the following roles." It's then up to App Y to decide what those roles actually let her do. That logic doesn't hit the database at all; we actually compare the role list provided with permissions in a YAML file.
That's just one example of the logic you could implement using Authority, but really it's wide-open.
Grouping models
In your case, if you used Authority, I'd suggest you group some models under a StandardAuthorizer and others under an AdminAuthorizer. Check out the README for more explanation.