Issue #40: Migrating from RC prevents login

Reported by:	Philip Pemberton
State:	duplicate
Created on:	2014-09-17 13:49
Updated on:	2014-09-19 07:26

Description

After migrating from Rhodecode 2.2.4, I found that I couldn't log into Kallithea.

This turned out to be a database update error, the details of which I pasted into the IRC channel. Essentially the migration changed the "local" authentication reference to "kallithea", but the auth plugin was still called "local".

This is on Kallithea 0.1.

Attachments

Comments

Comment by Mads Kiilerich, on 2014-09-17 13:52

Please explain the issue in more details. Especially how you did the upgrade.

Comment by Philip Pemberton, on 2014-09-17 17:24

From my chat log:

<philpem> Hi all. I've just upgraded from Rhodecode to Kallithea, and I've lost the ability to log in. I can do a "forgot password" and the PW hash changes in the database, but I can't log in.
<philpem> I get this in my Apache log: "2014-09-10 23:31:28.866 WARNI [kallithea.model.validators] user philpem failed to authenticate"
<philpem> OK, it seems somehow all my users have had their extern_type and extern_name set to "kallithea" instead of "internal", so the auth check fails...
<philpem> Quick fix: [in SQL,] UPDATE `users` SET`extern_type`='internal',`extern_name`='internal' WHERE extern_type='kallithea';
<philpem> So as near as I can tell, the stuff in rebranddb.py which changes the auth module name is bogus.
<kiilerix> philpem: why?
<philpem> If you change the auth module from "internal" to "kallithea", users can't authenticate any more.
<philpem> (which is exactly what the script does)
<kiilerix> it is possible that you can invoke it in a way where that is what it does
<kiilerix> what do you want to do?
<kiilerix> where do your database come from?
<philpem> I was upgrading a MySQL database which had been used with Rhodecode to run under Kallithea
<philpem> Followed the instructions in the Setup section of the docs and found I couldn't log in any more!

Essentially, the migration script is changing the name of the authentication module in the database. The "use the database" auth module is called "local", but the migration script changes every "local"-ly authenticated user to use the auth module "kallithea", which doesn't actually exist.

No auth module = fail safe = can't log in.

If you're logging in through LDAP, I suspect you'd be fine.

Comment by Mads Kiilerich, on 2014-09-18 08:17

You say "local" but mean "internal"?

Is this the same as 38.html ? Do the fix there work for you?

Comment by Philip Pemberton, on 2014-09-18 23:58

Yes, I made the mistake of not reading my scrollback (ahem)... So replace "local" with "internal" in what I posted in the second comment.

And yes, issue 38 is identical. Not sure why I didn't notice that when I posted this? Close as duplicate I guess.

I haven't tried the fixed rebranddb.py on my database as I've already migrated it across. Running rebranddb.py again seems silly.

Comment by Mads Kiilerich, on 2014-09-19 07:26

Duplicate of ~~#38~~.

Kallithea issues archive