Hi all,
just wanted to share a little information (and vent my frustration)
after almost 2h trying to figure out what was wrong with my
application.
It’s a simple application which I’m using to train TDD.
Basically my authentication tests were not working. Manual tests on
development environment all worked. I’m using hashing and salting, so
that one item on my users.yml (fixtures for users model) is:
one:
id: 1
email: [email protected]
hashed_password: d8bb56db4f9783c2e8932aa4153bdf7ae5188ec2
salt: 263168800.183078117780979
The hashed password + salt combination is obviously one that works,
taken from development environment.
My tests would fail on authentication: would always say user found but
authentication failed. Trough some debugging and logging I noticed
that the expected_password was different than the stored_password.
OK, this kinda isolated the problem: what could possibly be causing
the passwords to be wrong? I checked them billions of times, the entry
on the development environment users table was exactly the same as the
one on the users fixtures…
So I decided to use MySQL Query Browser to check the test database.
Upon listing the rows on the users table I found the problem: the salt
was WRONG! It was NOT the same as the one on my users fixture! How the
hell could it be different? After all, the database is rolled back
after each test, so even the change_password tests I had would not
have changed the salt…
Upon comparing both salts, I noticed that the difference was that one
of them was trimmed. While the original (from fixture) was
263168800.183078117780979 the one on the table was
263168800.1830781177 (I didn’t count the number of trimmed characters
so this might be wrong).
So, the only thing that makes sense would be that, when inserting
stuff into the database from fixtures, Ruby/Rails thinks that the salt
field is a float and stores it accordingly, although it is supposed to
be a string.
I’ve checked http://ar.rubyonrails.org/classes/Fixtures.html but they
don’t mention anything about column types, and I guess they don’t
need: It would make total sense IMO if the type wasn’t detected from
fixtures but read from the table structure!
The way I made it work, then, was by using this fixture (note the
quotation marks):
one:
id: 1
email: [email protected]
hashed_password: d8bb56db4f9783c2e8932aa4153bdf7ae5188ec2
salt: “263168800.183078117780979”
So, a long post for just a simple hint: double check those fixtures!