I use Devise to do the oauth with Github for my users. On login we ask for two basic scopes (for regular users) but if a user wants to perform some action (like setting up a new github organization in our product) we need to require some other scopes in addition to the ones we asked already.
I got it working for the most part the question is about how to better put everything together. This is the timeline of events:
User login (scope email)
User wants to perform setup action (POST /organizations)
in POST /organizations we check for the scopes of the current user and redirect to github to ask for the extra permissions if needed
User accepts the permissions and we get the oauth callback in the callbacks controller.
What I want is to continue with the process have at POST /organizations but the callback is in a different controller (obviously).
I've looked into omniauth.origin but that will only work for a GET redirect and this is a POST.
Any ideas how to better structure a solution for this?
Thank you!
Related
Let's imagine I have following scenario
User receives an email that there is a new item waiting for her
Clicks on a link and is able to either confirm or reject item (details skipped)
Can then access a list of all her items
The trick is that I would like to allow all this happen without user signing in but then limit access to other parts of the website (like sending an item to another user)
How I see it is that:
when user clicks a link she is signed in but only on tier 1 - with access only to confirm/reject action and read only to index of items (that's when Devise session is created)
when user wants to access other part of the website the sign in page is presented
when user comes to the website just by typing in the url http://example.com and wants to access own account she is asked to sign in.
after sign in session is "promoted" to tier which allows full access
after some time of inactivity session is downgraded to tier 1 for security reasons
My inspiration comes from how Amazon works - you can access in read-only most parts of the account but before performing any destructible actions you need to sign in.
Does anyone have any experience with such approach or can share some blog posts, etc?
I didn's find anything on SO and Google mostly returned things about two-factor auth which is not the case here.
I also understand that there are security concerns with links in email.
I have implemented a very similar behavior few months ago. I don't have very interesting resources to show you but I can explain a bit how you could organize or think about the problem to solve.
Description
For the problem you state, it looks like once you have identified a user, you have two different states you can give him:
limited access (perform certain actions, read most of the resources, etc)
full access (allows them to do anything they would normally do).
Having stated that, what you need to do is figure out in which cases you will give a user each access state (for example):
signing in with email token -> limited access
password -> full access
authentication_token -> full access
omniauth -> full access
After that, you will need to save this information in the user session. This should be done anytime the user is authenticated, as you will know what strategy was used to authenticate the user.
To know if a user can or cannot perform an action you will need two things, know what the user can do, and the current "access state". Depending on those you will decide wether the user is allowed or not to perform a certain action.
Whenever a user can't perform an action and is logged in with limited access you should bring him to the flow for verifying his crendetials. This flow is pretty simple, almost like a sign in but just with the password. Once you verify his crendetials you can upgrade his authorization to a full access one.
Implementation details
I recommend you to create a Authorization model which will represent the "access states" that I mentioned. This model will have to be serialized in the session so you should be able to build it from a simple structure and serialize it again into that structure. The simplest the better (a boolean flag, an array or maybe a hash). For the case mentioned, it looks like a boolean would do the job.
Regarding implementation details, I recommend you implementing this with a Warden after_atuhentication callback.
You could implement this with CanCan by creating you own Ability that would be built with an Authorization instance and a User instance.
I think you're confusing authorization and authentication. Devise is an authentication solution, meaning it handles the "proof me you are who you say you are" part. Authorization is the "Ok, I know who you are, now let's see what can you do". Devise doesn't provide an authorization system beyond the simple "logged/not logged". If you need a more complex authorization system, use an authorization gem. CanCan is very popular.
I'm using Devise with multiple scopes (in this case, a user scope and an admin scope) and admins are able to 'become' a user using the approach on the Devise wiki. This works well, except that I have one particular page that requires the use of an auth token that causes a problem with a session logged in under both a user and admin scope. The page generates a POST to a controller that requires a user to be logged in using the user auth token. The POST succeeds, but afterwards, the admin scope has been signed out. (Meaning that admin_signed_in? returns false.) Other pages that execute POSTs to the same controller without requiring the auth token work as expected without logging out the admin scope.
I suspect that something is going on with token_authenticatable where the authentication of any scopes other than the one associated with that specific token are logged out. I've searched for references in the devise gem source to both the devise sign_out and warden logout methods that could be invoked as part of the token_authenticatable functionality and wasn't able to find anything.
This is happening with Devise 1.3.4. Any help is appreciated.
In case anyone else is looking for a solution to this, I found that the before_filter/after_filter approach I described in the comment to my question seems to work fine. I think that a better, more general solution to this would be to make a change to the devise gem and underlying calls to warden, but didn't have time to make those changes for this particular problem yet.
I'm currently working on an application that in addition to the usual visual web application goop also will expose a few RESTful API services for use by outside applications. I am using Devise to manage user authentication but I'm struggling with how to "manually" authenticate a user given certain input.
The case I have is that I want a user of the API to log in w/o actually going to the visual log in screen etc. I want them to submit a username and password and then authenticate and sign them in in my API services.
I know that you can sign a user in using the sign_in method that Devise provides, but that seems to ignore authentication entirely. here's what I wanted to do explained in a bit more detail:
Assume a GET route called connect in the user controller. the controller is replacing entirely the Devise registrations controller, but not the session one. The URL to my service would be:
<server>/users/connect
and it would expect 'email', 'password' parameters in addition to some service specific and unimportant to my question goop.
What I want to know is how to implement something that is equivalent to the following pseudocode:
def connect
user = User.find_by_email(params[:email])
password = params[:password]
# here is the part I'm pseudo coding out
if user.is_valid_password(password)
...do my stuff...
end
render :json ...etc...
end
I have been unable to find a method in the Devise source to do this--it's so generalized in so many ways that I'm likely just missing it.
Anyone have any ideas? I'm hoping not to a) have to implement my own thing and b) not have to move away from Devise. It provides me with so much for the non-API services...
thanks!
I've left out th
Devise's token_authenticatable is the way to go for this. We've successfully used it many times to do api-based logins.
In config/initializers/devise.rb
config.token_authentication_key = :nameofyourapikeyhere
In user.rb:
devise … token_authenticatable, ...
In the above, you can name the api key anything and then have your route as /users/connect?apikey=whatever (using apikey as an example). In the database, it'll be authentication_token, but it'll work fine.
To clarify, if the user has an authentication_token and it's sent in the params (or it's alias- in the above example: apikey), they'll login.
I'm using rails 3 and devise. I would like to do build in the following work flow.
Article is submitted on site that requires admin approval.
Site sends the admin of the site an email with a link to the page where the admin can review edit and approve the article
I've got this implemented, however, if the admin is not currently logged into the site the admin is bounced back to the root path for not being authenticated.
Is there away that the link that that is sent in the email can act as an authentication for the specific admin?
You want to look into token authentication for devise. This allows you to use a one time key to authorize user access through a URL parameter.
See more information here. http://zyphmartin.com/blog/simple-auth-token-example-with-devise
Also you could simply create a authentication token per resource and store the authentication value in the database. When you go to the approve URL for the resource pass in the resource id and the authentication token. This would be more secure than logging the user in as administrator.
If you need more help let me know.
You could implement this as a custom controller action.
You can turn off devise authentication for a given action in a controller by adding an :except => :custom_action key to your :before_filter call.
You could include a query string in the link with the article_id and the admin_id. Then in the custom controller action, you would check that this article has not already been moderated, via an extra field in the articles table. If it had, you could bail. If it hadn't then you could allow the moderator to approve or disapprove of it, set the moderated flag to true and thank the moderator for her work.
If you wanted to get really tricky, you could make the URL include an MD5-hashed id which you could use as the key rather than an article id. You could store this in an extra field in the article model. That would make it much less likely to get spoofed during the brief window when it is moderate-able.
ian.
You could add an action to the controller (which is where your URL would point to), and then exclude it from authentication by adding this to your controller:
before_filter :authenticate_user!, :except => [:review_article]
You could include some sort of a key in the URL (e.g. MD5 of the article as Ian suggested), and check that in review_article.
I know that I can use annotation or Request mapping to restrict access to an ACTION by some specific ROLES. But now I have a different circumstance.
My scenario is: every user of my site can create posts, and they can make their own post public, private, or only share to some other users. I implement sharing post by a database table PERMISSION, which specify if a user have the right to view a post or not.
The problem arises here is that when a customer access a post through a direct link, how can I determine he/she have the privilege to view it? There's 3 circumstances:
The post is public, so it can be viewed by anyone (include not-login
user)
The post is private, so only the login-owner can view it
The post is sharing, it means only the login-user that is shared and the
owner can view it.
I want to process like this:
If the requested post is public: ok.
If the requested post is private/sharing: I want to redirect
the customer to the login page; after
logging in, the user will be re-direct
to the page he wants to see.
The problem here is that I can redirect the user to login controller/ auth action, but after that I don't know how to redirect it back. The link to every post is different by post_id, so I can't use SpringSecurityUtils.securityConfig.successHandler.defaultTargetUrl
Could anyone know a way to do this?
Dunno about grails, but spring security has a spring-security-redirect parameter which can be used to redirect the user to the specified url on successful authentication.
I think you could add your own filter that will be executed before the action is called and do the verification of the post permissions there. You can find more information about Grails Filters here.
Have you looked at the Grails Spring Security ACL plugin? I don't know it very well, but it's designed to restrict access to particular instances:
http://grails.org/plugin/spring-security-acl
I have found a quick workaround for this problem:
If the user is logged in: check the user's privilege, and return the appropriate result.
If the user is not logged in: At view action, set the post_id by:
session.post_id = 8
Redirect the user to the Login Controller/ Auth action.
At checkrole action(which is my grails.plugins.springsecurity.successHandler.defaultTargetUrl in Config.groovy), if session.post_id exists, use it to build the link for re-directing to the view action. Before redirecting, clear the session.post_id.