Redmine

OK so after a bit of investigation it seems a salt was added inbetween these two versions; however I'd have thought this would have been taken care of with the database upgrade process?? If I switch back to using the old files I can login so clearly the passwords haven't been hashed with the salt. Can I convert them manually??

I'm basically in the same situation - attempting to migrate from an old Redmine test server, to a new production server.

On the new server it's no longer possible to login (sure you can manually reset the user password directly in MySQL database).

A solution will be greatly appreciated!

I just realised that it can't rehash the passwords with the salt as they're already encrypted so obviously can't hash it with the salt as it'd need to know the plaintext password. However what I'd expect it to do is, when you login, check if there is a salt set, and if there's not, check the password as it would have checked on 1.0.5 (no salt) and then generate a salt and rehash it once it knows you've entered the right password. Is this not how it works??

A fair workaround could be to password reset each existing user - retrieve forgot password should do the trick!

Right, I decided to use a workaround, so here's what I did:

First of all, you gotta find the file 001_setup.rb:
find / -name '001_setup.rb'

Now open it (this is my path):
nano /var/www/railsapp/db/migrate/001_setup.rb

Find this part of the file: # create default administrator account
user = User.create :login => "admin",
:hashed_password => "fa2d1dc9a9d2982c3ef8cc3b5d985d1c54c9a064",

We'll use the hash in MySQL to reset the admin password:
mysql -u root -p
use redmine;
update users set hashed_password ='fa2d1dc9a9d2982c3ef8cc3b5d985d1c54c9a064' where login='admin';

fa2d1dc9a9d2982c3ef8cc3b5d985d1c54c9a064 in plaintext is "turnkey".

Now you should be able to login with username "admin" and password "turnkey".
From there, either manually reset the users password or, as I'm doing, configure email so they can use "Forgot password" instead.

Matt Rogowski wrote:

(...)however I'd have thought this would have been taken care of with the database upgrade process??

• source:/tags/1.2.2/db/migrate/20110223180944_add_users_salt.rb
• source:/tags/1.2.2/db/migrate/20110223180953_salt_user_passwords.rb

Are they listed in your schema_migrations table?

Yes, well it only has '20110223180944' and '20110223180953' but I assume that's OK as all the others are only numbers too. The salt column exists, it just only generated a salt for a few rows and hasn't actually rehashed any of the passwords.

As long as the rest of the upgrade was performed I can just write a script myself to generate a salt and rehash the password. But just hope there aren't other things that weren't done in the upgrade and will leave me with errors once I fix the hashing and login.

I´m having same problem here, and the hashed_password workaround didn´t work for me. What´s up with the salted passwords?

Another detail: i´m using LDAP authentication. Even for the admin user, I still couldn´t log in.

How is the password handling in case of LDAP authentication? Redmine is supposed to salt and store the LDAP password in its database??

Nope, Redmine doesn't store LDAP password, it is verified by LDAP server at authentication time and there is no salt stored for these users.

Well, the migration generated salt strings for all users, and there are hashed_passwords stored for them as well... What could be the problem?

This may happen if your users already had a password, i.e. if they used to authenticate themselves with internal authentication and then were switched to LDAP auth.

That happened indeed... Any ideas why wouldn´t work after the upgrade?

No. Is the LDAP authentication mechanism the only failing one or can't you log in as well with internal auth if you create a new user?

I can´t even log in with the default admin user.

Are you sure that the mongrel patch you found is fine?

You should find your mongrel.log file and have a look into it.

Here's the only patch I use to run Redmine with mongrel on Windows (to be placed into config/initializers folder).

Thanks, I will try that and check the logs.

Have same problem while tried upgrading from 1.0.3 to 1.3 release.
Did upgrade exactly by RedmineUpgrade wiki page.
I have 1.0.3 running well (in different directory, but using same database), changing password on 1.0.3 does not help.

Environment I run:

FreeBSD 7.2-STABLE, nginx with passenger 3.0.9.
Database engine: PostgreSQL 9.0
ruby-1.8.7.352_2,1 An object-oriented interpreted scripting language
ruby18-gems-1.8.7 Package management framework for the Ruby language
ruby18-iconv-1.8.7.352,1 An iconv wrapper class for Ruby

serv# gem list

• LOCAL GEMS ***

actionmailer (3.1.3, 3.1.1, 2.3.12, 2.3.11)
actionpack (3.1.3, 3.1.1, 2.3.12, 2.3.11)
activemodel (3.1.3)
activerecord (3.1.3, 3.1.1, 2.3.12, 2.3.11)
activeresource (3.1.3, 2.3.12, 2.3.11)
activesupport (3.1.3, 2.3.12, 2.3.11)
acts-as-taggable-on (2.0.6)
arel (2.2.1)
builder (3.0.0)
bundler (1.0.21)
daemon_controller (0.2.6, 0.2.5)
daemons (1.1.4)
erubis (2.7.0)
eventmachine (0.12.10)
fastthread (1.0.7)
file-tail (1.0.7, 1.0.5)
hike (1.2.1)
i18n (0.6.0, 0.4.2)
json (1.6.1)
mail (2.3.0)
mime-types (1.17.2)
multi_json (1.0.3)
passenger (3.0.9)
pg (0.11.0)
polyglot (0.3.2)
rack (1.3.5, 1.2.1, 1.1.2)
rack-cache (1.1)
rack-mount (0.8.3)
rack-ssl (1.3.2)
rack-test (0.6.1)
rails (2.3.12, 2.3.11)
railties (3.1.3, 3.1.1)
rake (0.9.2)
rdoc (3.11)
ruby-graphviz (1.0.3)
rubygems-update (1.6.2)
rubytree (0.8.1)
sprockets (2.0.3)
spruz (0.2.13, 0.2.2)
thin (1.2.11)
thor (0.14.6)
tilt (1.3.3)
tins (0.3.1)
treetop (1.4.10)
tzinfo (0.3.30)

On another server running same 1.3 version and very similar environment - no problems (was fresh install there), so I think here is same problem as described by previous members.

Let me know any hints to fix.

P.S. And my db/schema.rb does not have 20110223180944 or 20110223180953.

In order for my upgrade to work, I had to copy the previous version of this file before migrating the database:

config/initializers/session_store.rb

After that, migrated the database and it worked fine.