I spoke to a couple people who are running into this problem and they
are using the form on the website to login just like everyone else.
It is a post request: <form action="/session"method=“post”>
How do I check that the form_authenticity_token matches the given _token
value?
What makes this weird is 95% of people can get in no problem what so
ever.
It is some of the people some of the time. That is what is confusing?
Is
is where I set my session values?
Here is session#create:
def create @user = User.authenticate(params[:nickname], params[:password])
if @user
set_user_session(@user) @user.set_last_logged_in_to_now
redirect_to session[:return_to].nil? ? home_path :
session[:return_to]
else
flash[:error] = “Hmmm, we were not able to find you. You sure you
entered your nickame and password correctly?”
redirect_to root_path
end
end
Every stupid time this happened to me it was because I cached the login
form
using page_caching or some other caching mechanism. You can tell
protect_from_forgery to ignore certain actions if that’s what’s
happening to
you.
I am not caching either what so ever. So it is not caching… unless Rails
does caching for me by default I should know about!
Can it be the redirect after the setting of session variables? What can it
be? It is driving me and my members crazy.
It is defenitely not the redirect since the explosion occurs on the
validation of the token against the session token, you should see that
from your stack trace… . At this point I am more inclined to go with
the caching…
It is defenitely not the redirect since the explosion occurs on the
validation of the token against the session token, you should see that
from your stack trace… . At this point I am more inclined to go with
the caching…
I am not doing any caching what so ever unless Rails 2 and 2.1 did
caching out of the box.
The stack trace only gives me the only value… not the other.
Any other suggestions? Any fixes?
Do you reset the session on login? If you do reset the session and if
the user later hits the back button and logs in again then they will
be logging in from the browser’s cached copy of the login page (ie
with the old authenticity token)
If you reuse the session_key or secret from another project
by copy/pasting this part in environment.rb
Rails::Initializer.run do |config|
config.action_controller.session = {
:session_key => ‘_something_session’,
:secret => ‘somethinggoeshere’
}
end
Even if later you change it, some of the stuff seems to stick
and you get messed up sessions for every user who may have
used the other project too or your new project during the time
it was using the old combination of secret/key.
Make sure, session_key and secret are unique, then clear the
private data (cookies, stored passwords, authenticated session,
everything)
This is only a very rough guess, but it may fit with the fact, that
only some
of your customers have this trouble.
No I do not. The person comes straight to the page. Trys to login and
boom… gets an InvalidAuthenticityToken… are any parts of the token
stored in the cookie store? This does not happen to everyone just some
people.
On Wed, Jul 2, 2008 at 11:37 AM, Frederick C. < [email protected]> wrote:
No I do not. The person comes straight to the page. Trys to login
and boom… gets an InvalidAuthenticityToken… are any parts of the
token stored in the cookie store? This does not happen to everyone
just some people.
The value which gets hashed to produce the token is stored in the
session (ie in the cookie).
Not from what I can tell. Can you give me any examples that would
cause race conditions? Double clicking login?
For example if you load the page with the login box simultaneously
(and you don’t yet have a session cookie) then you’ll get two entirely
separate session cookies or if a page fired two ajax requests that
happened to overlap. I know there are some tools (virus scanners, ‘web
accelerators’) that preemptively load pages before you click on the
link, could be a factor
Other than that I can’t think of anything better than finding an
example where it did happen, pull all the requests from that ip
address from your log file and go over it with a fine comb.
If you are using the cookie store, session ids look like
So I had an empty session with just the flash.
I’d probably write a script that would munch through the log files
and print each request from the person in question along with what was
in the session and try and workout what happened.
I have no clue why but maybe it is truncated in the cookie and ends
up not matching.
An exception should be raised if that happens.
Maybe I need to change session storage?
You could give it a go, but I doubt it will change much.
Have you glanced through your log files to see if there;s anything
abnormal or unusual about the people who are affected? There are race
conditions with sessions if users have more than one request, is that
a possibility?
Does that make sense? Does that mean the authenticity_token is not being
saved to the session to be compared?
The authenticity token is never put in the session. The
authenticity_token is generated based on session[:crsf_id]. If you can
see that value changing unexpectedly then you’ll have found the source
of the problem
On Wed, Jul 2, 2008 at 12:30 PM, Frederick C. < [email protected]> wrote:
happened to overlap. I know there are some tools (virus scanners, 'web
%0ASGFzaHsABjoKQHVzZWR7AA%3D%3D–
%0ASGFzaHsABjoKQHVzZWR7AA%3D%3D").unpack(‘m*’).first)
On 2 Jul 2008, at 15:55, John K. wrote:
session[:sex] = user.sex
a possibility?
No I do not. The person comes straight to the page. Trys to
Fred
I am not doing any caching what so ever unless Rails 2 and 2.1
will
I am not caching either what so ever. So it is not caching…
see
John K.
Any fixes? 
Any fixes?