I'm using Devise for authentication in a Rails 4.2 app. Most of the users are not having any issues logging in and getting their work done, but there is one user in particular that appears to consistently have a bad CSRF token and can't log in.
Of course, the following is what's logged:
W, [2015-02-17T20:58:19.261194 #1936] WARN -- : Can't verify CSRF token authenticity
I, [2015-02-17T20:58:19.263556 #1936] INFO -- : Completed 422 Unprocessable Entity in 5ms
F, [2015-02-17T20:58:19.276795 #1936] FATAL -- :
ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):
<stack trace>
Perusing the logs shows me that the user's CSRF token changes as you'd expect, but it is consistently (100% of the time) rejected by the server.
Originally, I thought this was an issue with that user's browser. I started logging the user agent when logins are attempted and asked that user to try with several browsers; she has, and all are able to reproduce the same issue.
I reset her password and was able to log into the account using new credentials. She still cannot log in.
She has dumped her cache and cleared cookies several times. Likewise, a runthrough with anti-malware software returns no results (this is probably the most suspect).
What am I missing? Is there something I need to do on the server side in order to fix this issue, or is it likely an issue with her computer itself?
The issue has been resolved, at least temporarily. After some searching through issues on the Devise issue tracker, I happened across this snippet (for placement in config/initializers/session_store.rb) that seemed to help:
Rails.application.config.session_store :cookie_store, key: "_rails_session_#{Rails.env}", domain: :all
The user is not having any problems signing in at this point. I suspect it was either that the user was not properly clearing her cookies or that there was a mixup somewhere in the code. At any rate, it seems to be fixed.
Related
I have an app that uses the Twitter API where users can authenticate via twitter and retweet/like/follow through my app. Randomly this week the logs are showing "code: 89 Invalid or expired token".
Naturally, I go login to twitter to see the status of my app, and nothing seems out of the ordinary. I saw others with this issue had success regenerating their keys and replacing them in their application.
This didn't help.
One important thing to note is nothing has changed in the code of my application for the last 3-4 months, so I doubt it's anything in there. It's been working for over two years without any issue.
The thing I suspect the most is perhaps Twitter decided to suspend my app; Although, I don't see anywhere that is the case, and I thought I'd receive an email from them about it if it were.
I'm at a loss and would appreciate some possible solutions or alternative avenues I can pursue to find the culprit.
The keys associated with your app are the API Key (Consumer Token) and API secret key (Consumer Secret). The error you're getting is for the Access token, which belongs to the user. It sounds like the user associated with that request needs to authorize your app again before it can operate again with their access key. This can happen if the user removes authorization for your app by visiting their Settings/Privacy and safety/Apps and sessions.
If you were using your own access token in a scenario like single-user authorization, then regenerating the key might work, but in this case, the only way to get new keys for that user is for them to go through the sign-in process to authorize your app again. e.g. you could log who the user was that the error occurred on and send them a notification to re-authorize.
I have a Rails 5 app and am using a form to submit data. I am using CSRF protection and the form generates a hidden field 'authenticity_token'. Works great!
But sometimes a user gets and error 'Can't verify CSRF token authenticity'. And I am wondering why this happens? I can only imagine that the user has cookies disabled. But which normal internet user does that? Are there any other reasons?
I am not able to reproduce this error on my computer. So the only solution I have is to disable CSRF protection which is not really what I would like to do.
Any ideas?
Can't verify CSRF token authenticity results in 500 Internal Server.
I am wondering why this happens? I can only imagine that the user has cookies disabled. But which normal internet user does that? Are there any other reasons?
Yes, this happens. Or maybe the user(or hacker) tries to make an API request to the endpoint and since, it can't verify the authenticity token it will throw this error. A normal user doesn't do this, but maybe someone who values their privacy and may turn these settings off, or maybe they want to use Tor browser and so on. As developers, all we can do is try to provide best possible experience to the end user.
So, A better practice is to catch 500 Internal Server error with some custom message and then display it to the end user, while also sending the Stack trace to yourself(slack notification etc.) so that you can work on if it's a critical issue.
This way, If everything is good from user's end, this will work normally. But If someone disables cookies(or anything that results in some error), you can display custom message about the issue.
Since 2AM (ish) this morning, the SSO does no longer work with LinkedIn.
We 100% get the error "the authorization server encountered an unexpected condition".
We did not change our code whatsoever. We tried to switch the LinkedIn developer app to test mode and then back to live mode, but still no luck.
There can be no logs on our end (for the issue is on LinkedIn end), and AFAIK there is no developer log on LinkedIn either (although it could be a pretty useful addition).
Anyone experiencing the same issue? Or anyone have any idea why this could happen all of a sudden?
Thanks!
EDIT: after several attempts (by modifying our OAUTH code in some ways), it always failed. And we decided to create another brand new LinkedIn developer app, and it did work! This is really weird...
For some reason an account which I've registered using my app and tested before is now giving me an error when trying to log in using its details: "Logins don't match. Please include at least one valid login for this identity or identity pool."
I know the values I am using for it are definitely correct and other accounts are still able to login. What could be the cause of this error?
Any help would be greatly appreciated.
What the SDK is trying to tell you is that the identityId in your Federated Identity Pool (and which may be stored in a keychain in your device, and which may be re-established on restart from an existing session) does not match the login in your authentication provider which was returned by the "logins" method.
This can happen in a number of different ways, but this usually occurs because you attempt to log in as another user on the same authentication provider without first logging out.
The SDK recovers by retrying.
(This recovery does not really work because I think it takes 2 or 3 attempts to time out, and the recovery then leaves you in a state where subsequent logins fail with the same error. Restarting the app clears this. I have not fully investigated the defect in the retry/recovery process)
The solution is to prevent the app from logging in on a different ID with the same authentication provider (IdP) without first logging out of that authentication provider.
I'm trying to make Facebook login with omniauth-facebook in Rails 3.2.9; I have followed the steps of Ryan Bates in http://railscasts.com/episodes/360-facebook-authentication and in this very moment I have the same code.
If I try to login without the Javascript it works (it takes me to Facebook, I grant the permissions, and gets me back to the app successfully), but if I try with the Javascript (for the Facebook popup) it initially shows the popup to login, but then makes a redirect and throws me this error (without asking for the permissions):
Started GET "/auth/facebook/callback" for 127.0.0.1 at 2012-11-16 15:16:03 -0600
(facebook) Callback phase initiated.
(facebook) Authentication failure! invalid_credentials: OmniAuth::Strategies::OAuth2::CallbackError, OmniAuth::Strategies::OAuth2::CallbackError
OmniAuth::Strategies::OAuth2::CallbackError (OmniAuth::Strategies::OAuth2::CallbackError)
This is a very common error; I made the research and tried all the solutions (mostly are from some months ago) but none of them work. This is what I have tried:
Checking the sandbox in Facebook is disable (and I have waited hours for the propagation)
Checking the Site URL to http://localhost:3000/
Checking the App ID and App Secret
Downgrading the omniauth-facebook gem to 1.4, and throws me this error: omniauth-facebook must pass either acodeparameter or a signed request (viasigned_requestparameter or afbsr_XXXcookie)
Downgrade to Rails 3.2.8
What else should I do? (I think the key is in the Javascript, and right now I have the same code of the video, with CoffeeScript). Thanks in advance!
I followed that Railscast just now and managed to get it working. You'll notice people discussing your problem in the comments. Following the links there, I ended up on this issue on Github and this question on StackOverflow.
I recommend updating to 1.6.0 and to 2.0.0 when it finally comes out. In the meantime, make sure you aren't making any of these mistakes:
Defining your app credentials in two different initializers, usually omniauth.rb and devise.rb. source
Having a domain name mismatch between your live site and the site url configured within your facebook application. source
Leaving the facebook application in sandbox mode, so the domain name doesn't match the production one. source
Adding a before_filter :authenticate to the OmniauthCallbacksController or ApplicationController (since OmniauthCallbacksController inherits from ApplicationController). source
Using omniauth-facebook in conjunction with Facebook's client-side flow. source
Messing with the state param.
Solution without downgrading (using 1.5.1 right now) :
https://github.com/intridea/omniauth-oauth2/issues/32 ->
Add this to your provider declaration :
provider :facebook, xxxxxxxxx, yyyyyyyyy, {:provider_ignores_state => true}