Bug #15944
closedBackend Login not possible
Added by old_monty over 18 years ago. Updated over 16 years ago.
0%
Description
admin or fresh installed admin user can't login: "Your login attempt did not succeed. Make sure to spell your username and password correctly, including upper/lowercase characters."
1. got rc2 source and dummy
2. created database user dummy & dummy database
3. tar xvfz dummy & source, chmod -R www-data:www-data fileadmin typo3conf typo3temp uploads
4. configured dns to point typo3 to my server
5. configured apache to point virtual to the dummy site
6. did 1-2-3
7. created admin user
8. tried to log in. No Go.
Same Problem with RC1. I suspect some problem with php config. php.ini attached.
(issue imported from #M3056)
Files
Updated by Franz Holzinger over 18 years ago
Do you have a database tool like Webmin or phpMyAdmin?
Check the entries in the be_users table.
Change the password to
bacb98acf97e0b6112b1d1b650b84971
which is joh316
Updated by Susanne Moog over 18 years ago
I have the same problem... but phpMyAdmin does show, that no backend User is created, even if Typo tells you so.
Updated by old_monty over 18 years ago
Is there any need for a tool?
mysql> use dummy
Database changed
mysql> select uid, pid, username, password,admin from be_users;--------+----------+----------------------------------+-------+
| uid | pid | username | password | admin |--------+----------+----------------------------------+-------+
| 1 | 0 | admin | 5f4dcc3XXXXXXXXXXXXXXXdeb882cf99 | 1 |
| 2 | 0 | muth | 45606e8XXXXXXXXXXXXXXX5db682cdf8 | 1 |--------+----------+----------------------------------+-------+
2 rows in set (0.00 sec)
Double checked the passwords:
mysql> select md5('mypasswords');
matched the passwords in be_users
Updated by Susanne Moog over 18 years ago
I used the debug option now, here's what I'm told:
caller t3lib_DB::exec_INSERTquery
ERROR Field 'usergroup' doesn't have a default value
lastBuiltQuery INSERT INTO be_users
(
username,
password,
admin,
uc,
fileoper_perms,
tstamp,
crdate
) VALUES (
'super',
'1b3231655cebb7a1f783eddf27d254ca',
'1',
'',
'7',
'1143703260',
'1143703260'
)
debug_backtrace require // tx_install->init // tx_install->checkTheDatabase // t3lib_DB->exec_INSERTquery // t3lib_DB->debug
But the real spooky thing is, when I did the following:
Opened PHPMyAdmin, used the SQL Command window to type in the Insert order. I got the message: Field 'usergroup' doesn't have a default value
After that I went to the default field of usergroup and inserted a 1 just for testing. Now the message was:
#14752 - BLOB/TEXT column 'usergroup' can't have a default value
EDIT: Seems to be a MySQL 5.0 -Problem. I just had to turn off the strict option.
Updated by old_monty over 18 years ago
Okay, I tried to hunt the problem down by inserting some debugging code:
In t3lib/class.t3lib_userauth.php::compareUident(), I inserted:
error_log("compareUident($user, $loginData, $security_level)"); // monty
foreach (split("\n", var_export($loginData, true)) as $HLine) error_log($HLine); // monty
foreach (split("\n", var_export($user, true)) as $HLine) error_log($HLine); // monty
foreach (split("\n", var_export(debug_backtrace(), true)) as $HLine) error_log($HLine); // monty
after $security_level = ...
and, since some of the first traces showed, that I have "superchallenged" and I enter the if branch after if ($this->challengeStoredInCookie), I hooked in after this if:
error_log("compareUident: challengeStoredInCookie"); // monty
error_log("\$_SESSION['login_challenge']: {$_SESSION['login_challenge']}"); // monty
This is my Trace:
-------------------------------------------------
compareUident(Array, Array, superchallenged)
array (
'status' => 'login',
'uname' => 'admin',
'uident' => 'eb63eef91c11bee7e5cd2039d1618065',
'chalvalue' => 'd12b563a21baf363cda01c7d7a6b8dae',
'uident_text' => '',
'uident_challenged' => '',
'uident_superchallenged' => 'eb63eef91c11bee7e5cd2039d1618065',
)
array (
'uid' => '1',
'pid' => '0',
'tstamp' => '1143634292',
'username' => 'admin',
'password' => '5f4dcc3b5aa765d61d8327deb882cf99',
'admin' => '1',
'usergroup' => '',
'disable' => '0',
'starttime' => '0',
'endtime' => '0',
'lang' => '',
'email' => '',
'db_mountpoints' => '',
'options' => '0',
'crdate' => '1143634292',
'cruser_id' => '0',
'realName' => '',
'userMods' => '',
'allowed_languages' => '',
'uc' => '',
'file_mountpoints' => '',
'fileoper_perms' => '7',
'workspace_perms' => '1',
'lockToDomain' => '',
'disableIPlock' => '0',
'deleted' => '0',
'TSconfig' => '',
'lastlogin' => '0',
'createdByAction' => '0',
'usergroup_cached_list' => '',
'workspace_id' => '0',
'workspace_preview' => '1',
)
array (
0 =>
array (
'file' => '/var/www/cms/typo3_src-4.0rc2/typo3/sysext/sv/class.tx_sv_authbase.php',
'line' => 111,
'function' => 'compareuident',
'class' => 't3lib_beuserauth',
'type' => '->',
),
1 =>
array (
'file' => '/var/www/cms/typo3_src-4.0rc2/typo3/sysext/sv/class.tx_sv_auth.php',
'line' => 95,
'function' => 'compareuident',
'class' => 'tx_sv_auth',
'type' => '->',
),
2 =>
array (
'file' => '/var/www/cms/typo3_src-4.0rc2/t3lib/class.t3lib_userauth.php',
'line' => 461,
'function' => 'authuser',
'class' => 'tx_sv_auth',
'type' => '->',
),
3 =>
array (
'file' => '/var/www/cms/typo3_src-4.0rc2/t3lib/class.t3lib_userauth.php',
'line' => 285,
'function' => 'checkauthentication',
'class' => 't3lib_beuserauth',
'type' => '->',
),
4 =>
array (
'file' => '/var/www/cms/typo3_src-4.0rc2/typo3/init.php',
'line' => 284,
'function' => 'start',
'class' => 't3lib_beuserauth',
'type' => '->',
),
5 =>
array (
'file' => '/var/www/cms/typo3_src-4.0rc2/typo3/index.php',
'line' => 63,
'args' =>
array (
0 => '/var/www/cms/typo3_src-4.0rc2/typo3/init.php',
),
'function' => 'require',
),
)
compareUident: challengeStoredInCookie
$_SESSION['login_challenge']:
-------------------------------------------------
There is clearly some problem with session management, since $_SESSION['login_challenge'] is empty.
Updated by old_monty over 18 years ago
Workaround found: Setting [BE][loginSecurityLevel] to normal works for me.
Updated by Kasper Skårhøj over 18 years ago
Due to workaround, this is closed now.
Updated by old_monty over 18 years ago
I found the reason for this problem: it was (as I suspected in the problem report) a setting in php.ini:
If session.cookie_domain is set to the wrong domain, challenged and superchallenged login fails. Best practice would be not to set session.cookie_domain at all.
So please either check this setting in the install tool or mention it in the installation documentation.
Updated by Dmitry Dulepov over 18 years ago
I afraid we cannot verify PHP settings in install. It is an overkill.
Updated by old_monty over 18 years ago
Okay, if checking php.ini settings in install tool is overkill (really?), then a note in the install documentation about required and recommended settings - especially session.* and various memory settings - would be appreciated.