Scenario : I am working on a rails application in which our user is redirected to a third party application during payment request. Once it is done, we get the response back from that application via HTTP POST method. We have a controller action to handle that request but there is a before_action devise gem method 'authenticate_user!' for checking if the user is logged in.
Issue : when the application is accessed over https, the before_action check fails and the user is logged out of the application (Completed 401 Unauthorized). In case of http, it is fine.
Rails version : 4.2.6
Devise version : 3.5.6
I have not worked on devise much. Please let me know if you have any insights on this.
look to the token authentication.
for example you can assign to before_action a method wich check if user it's authenticated by token and this token keep in params when you make first request to payemnt application.
This is one example, you can make other scenario using token.
Related
I have a Rails 6.1 app using devise 4.7.1, doorkeeper 5.5.1, and devise-doorkeeper 1.2.0.
I'm trying to run through a (PKCE) OAuth flow, but the final step -- a POST request to /oauth/token -- returns a 401 Unauthorized error with the JSON content {"error": "You need to sign in or sign up before continuing."}.
I'm confused about this, since the /oauth/token endpoint should be accessible to unauthenticated users as far as I understand. What's also weird (but perhaps a red herring) is that if I attempt to run the same POST request with curl, but remove the User-Agent header, it succeeds.
My current suspect is this block of code in initializers/doorkeeper.rb:
resource_owner_authenticator do
current_user || warden.authenticate!(scope: :user)
end
This comes from the Doorkeeper docs. By stepping through the code, I can see that it's the call to warden.authenticate! that returns a 401 error. Doorkeeper's TokensController#create is never called.
Is there any important step I'm missing that allows unauthenticated access to this TokensController#create endpoint?
This problem was caused by our use of the Ahoy analytics library.
By default, this library tracks all page visits in your Rails app. It tries to get the current user using current_user || current_resource_owner. Because current_user was still nil when POSTing to /oauth/token, getting current_resource_owner ended up calling our Doorkeeper resource_owner_authenticator, which returned the 401 error. The source code for this is here.
This also explains why things worked as expected when unsetting the User-Agent header: with no user agent (or the user agent of e.g. curl), Ahoy treats the request as coming from a bot, and doesn't attempt to track it (source code here).
Our solution to this is to tell Ahoy to stop tracking all page views automatically by setting Ahoy.api_only = true in its configuration.
I'm using Devise 3.5 with Omniauth in a Rails 4 app. I've created an integration with Facebook that allows a user to connect their Facebook account to my app. Currently when the user clicks the connect button, they're sent to /user/auth/facebook and then redirected to the callback url that Omniauth generates: /user/auth/facebook/callback. What I'd like to do is manually override this callback url in some cases - meaning that I don't want to override it in an initializer - with a fully qualified url. For example, if a user starts out on http://www.example.com/ I might want to override the default callback url with http://app.example.com/user/auth/facebook/callback.
My app has dynamic subdomains and a user will (almost) always begin the authentication process on a subdomain. Unfortunately it seems that Facebook doesn't support wildcards in oauth redirect urls, which is why I want the ability to detect if a user is on a subdomain and adjust the callback url to something that I have whitelisted on my Facebook app so that the authorization process succeeds.
From what I've read, the url helper omniauth_authorize_path accepts additional arguments to be passed on as parameters. I've tried passing a custom callback path in like so, but without success:
user_omniauth_authorize_path(:facebook, callback_path: #custom_callback)
I've also tried changing callback_path to redirect_url and redirect_uri, but nothing seems to work. When I look at the link that's generated, it does indeed include the callback as a parameter in the url, but when I click the link, I'm redirected back to the default callback url instead of the custom callback url.
Here's how I solved this problem. I'm sure there are other ways, but this seems like the simplest most elegant solution I could come up with.
In config/routes.rb I set up an auth subdomain. All my Oauth connect requests will start on different subdomains and then Facebook is set up to forward those users back to the auth.example.com subdomain.
constraints AuthRedirect do
devise_scope :contact do
get '/auth/facebook/callback' => 'omniauth_callbacks#facebook'
post '/auth/facebook/callback' => 'omniauth_callbacks#facebook'
end
end
Here is /lib/auth_redirect.rb. This just checks if the subdomain is auth and captures that traffic. This is placed at the top of my routes list so as to take precedence over other subdomains.
class AuthRedirect
def self.matches?(request)
request.subdomain.present? && request.subdomain == 'auth'
end
end
Then in my client, when a user clicks the Connect with Facebook button, I send them to /auth/facebook?contact_id=<id>. From here Devise directs them to Facebook, which then redirects them back to https://auth.example.com/.
Then in OmniauthCallbacksController#facebook I can pull the user's id from the omniauth params like so:
auth = env["omniauth.auth"]
contact = Contact.find(env['omniauth.params']['contact_id'])
From here I can persist the credentials to the database and the redirect the user back to the appropriate subdomain. This solution avoids problems with CSRF tokens and more importantly does not require me to use Ruby/ERB to build the omniauth authorize path that the user is sent to when they click the connect button.
have you tried with redirect_uri ?
user_omniauth_authorize_path(:facebook, redirect_uri: #custom_callback)
EDIT: sorry I missed the second part of your post.
I actually have the same problem in production but it works perfectly on a staging environment. The only difference is about the callback url on staging which has one more subdomain *.staging.domain.com
By the way you can provide a static callback_url in the devise initializer file:
config.oaumniauth :facebook, ..., callback_url: 'url right here'
I'm on this issue this yesterday.
Either I provide a static callback url but facebook raises me an CRSF error:
omniauth: (facebook) Authentication failure! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF detected
Or I let devise set the callback_url dynamically which gonna look like
https://*.domain.com/DEVISE_MODELS/auth/facebook
and in this case I get a straight non matching/whitelisted callback url during FG loggin in process.
EDIT2:
GOOD! I made it. I'm able to get oauth login in with wildcard subdomain.
Provide a static callback_url in your devise initializer
add the domain to your session store as :
domain: ".domain.com"
With that I'm getting neither CRSF error nor nunmatching CB url/whitelisted.
Hope it'll work for you !
I want to simulate several function in my rails application by using curl in terminal. The problem I am facing now is that first I login in my application using user name and password. But then while I am hitting the url corresponding to a function of a controller, it is giving message "You are redirected to sign_in page".
I think I have to use authenticity token somehow. But I don't know how to get it and how to pass it during each call to controller function. So if anyone helps me to figure it out, I will be really grateful.
You can check the format of the request modify the controller code to handle both the html and json request separately.
In the first request get the access token in response from your controller. You can use this authentication token for your further request.
In order you generate the access token
Create a migration in users table for authentication token
When the user logins/sign-up create the authentication token for that user
Once you make these changes you can have the user information passed using the curl request and pass back the authentication token in response for the user.
For further request use this authentication token to verify the user and perform the actions.
I am using Devise to authenticate users for my rails app using database authentication (for username and password) and token authentication for an API that I built with Grape. Devise is generating an authentication token as expected. However, it seems that authentication always fails after the first request and works subsequent times. I am calling authenticate! before my API calls in Grape, which is defined as follows:
def authenticate!
error!({"error" => "Unauth 401"}, 401) unless env['warden'].authenticate
end
This is very odd behaviour. If I try to login with the browser first, then via a curl call to the API, it works. It seems that the first request will just always fail after a server restart.
Is that the expected behaviour? If so, why is that and how do I avoid it? Do authentication key logins always need a regular login via the browser first?
P.S: I did read Devise authentication fails on first attempt, succeeds afterwards, but it does not seem to answer the question.
I am creating an API for my application. On one side, there is the API server (and the main app) and on the other, the client. The sever uses DoorKeeper to secure the API using OAuth 2.0 (basically turning the main app into an OAuth 2.0 provider) and the client is using OmniAuth with a custom strategy for my app.
The main app uses multitenancy using subdomains; so every client has its own subdomain. There is also a oauth subdomain that is routed to the DoorKeeper interface.
When a user clicks on the "Log in with my app" link, he gets redireced to the oauth subdomain. If he is not logged in to the main app, he needs to get redirected to the login page under the correct subdomain. So I need to pass the client's account name to the server so that DoorKeeper knows to which subdomain to redirect to.
How can I achieve that please?
I've researched on the subject and found out how to pass to OmniAuth params that will get passed to the callback action. Will those params be available to the server?
EDIT: I am not using Devise!
EDIT 2: Here is some code.
Client app session controller create action (log in with my app)
def set_client
self.current_client = Client.find(params[:client][:name])
redirect_to "/auth/catapult?client=#{self.current_client.account_name}"
end
As you can see, I append the client param to the OmniAuth route, but this param is not passed to the server app (DoorKeeper), so I have no idea where to redirect to on the server app.
DoorKeeper config
resource_owner_authenticator do
p params
User.find_by_id(session[:user_id]) || redirect_to(log_in_path)
end
In the redirect above, I need to specify the client's account name as subdomain, but I don't have this info (client's account name) since the params hash does't contain the client's account name that I passed (the client param)
I found out how to fix my problem. I had to dig in deeper into the OmniAuth source code. what I had to do is override the request_phase method in my custom strategy as follow:
def request_phase
redirect client.auth_code.authorize_url({:redirect_uri => callback_url, :catapult_client => request.params["client"]}.merge(authorize_params))
end
Where :catapult_client is, add any extra params you want to pass and it just works!
The simplest way is to pass the place-to-redirect-to-after-authenticating-successfully as a query param when they are redirected to the login page, so it's there as part of the GET request's querystring. Store it, and on a successful auth, redirect them there. You don't need to involve this data in the OAuth process at all.
Of course, I'm assuming that they all start at their subdomain too.
Edit:
When a user clicks on the "Log in with my app" link, he gets redireced to the oauth subdomain.
Assuming the user starts at mysubdomain.yourapp.com, they click on the "Log in with my app" link.
The link also contains a query parameter with the subdomain in it, so oauth.yourapp.com?redirect=mysubdomain.yourapp.com (or just oauth.yourapp.com?redirect=mysubdomain)
The user arrives at oauth.yourapp.com. The app stores the query parameter. The user puts in their details or is redirected to a service…
The OAuth process is finished, the user has been authenticated.
Redirect the user back to the redirect parameter stored earlier.
This is how I do it, just not with Rails, but I don't see why you couldn't use this process with any framework. This, as I mentioned, depends on the user starting on the correct subdomain.