TYPO3 Core

What happens if you manually create a new admin user through phpMyAdmin?

Are you sure that this TYPO3 installation does have the permission to write to tables?

Typo3 connected and wrote to MySQL using full admin rights.
Creating an admin user manually through PHPMyAdmin seems to work. The SQL statement was accepted, the whole entry can be found in the be_users table. However, the error message remains the same, even after restarting the MySQL instance. But maybe I don't have the correct values for all columns (because I got nothing to compare). What should a complete entry for an admin user look like?

What is this error message?

A default user is just the unmodified default of a new database record with only "username", "password" (MD5sum!) and "admin" (flag is set) fields changed.

Do you have display_errors enabled? Does PHP write any error messages?

If nothing helps you will have to enable MySQL logging and check what commands have been sent.

In any case, I'm sure that the logfiles (PHP or MySQL) would help, and this is surely not a TYPO3 problem...

The error message of Typo3 is still the same: "Your login attempt did not succeed. Make sure to spell your username and password correctly, including upper/lowercase characters."
I tried it with display_errors set on and off in php.ini; no errors were displayed or logged. I just uploaded the MySQL logging file (mysql_log.txt, see above) for the backend login procedure, maybe someone can read something out of it. At least Typo3 accesses the database. The MD5 sum of the password is the equivalent to joh316, as given by Franz Holzinger on http://bugs.typo3.org/view.php?id=3056 . I'm not sure if this isn't a Typo3 problem, because a similar problem (backend login not possible / no backend users created in fully functional database) was reported several times for older versions of Typo3.

Well, as far as I can see from the log-file, your login succeeds. A session is created and the successful login is also logged in the T3-log.

Perhaps cookies in your browser are disabled? Or there is a problem with PHP, perhaps register_globals=on in the php.ini? This often causes problems.

As I wrote in the description above, cookies are enabled. The problem is reproducable using different browsers (Firefox, IE, Opera). In the php.ini register_globals was always set to OFF.
I even reinstalled Typo3 4.0.1 twice and everything remained the same. No errors, all tables were created and reported to be consistent, but the default backend user (admin / password) wasn't created and creating admin users via the database analyser works (at least Typo3 tells me so), but the be_users table remains empty...
Anybody else who has seen this?

Well, according to your log-file, the login succeeds. The time of the last login is updated in the be-users record, a be-session-record is created, and a log-entry is created. So I don't understand why you are not logged in.

Perhaps there is a problem with challenging/superchallenging the password you entered. I would guess this is a PHP-problem, perhaps even a bug. Could you try upgrading PHP to 5.1.x, newer than 5.1.1?

I also sometimes encounter login-problems, but they usually disappear after the next login-attempt. The problem seems to occur if you cancel the login-process after clicking "login" and the re-login. Somewhere the old credentials seem to have been saved and are not usable - or something like this. The result is, anyway, that you can't login.

I have exactly the same problem. There is no entry made in the db , not in be_users and not in fe_users. I use php 514, so this can not be the problem.
For my belief this is a typo3 problem.

What about mySQL? I use 5.0.18 and InnoDB.

This logfile shows the log of a session login but not when a new user would be created.

Please go back to the Install Tool, create a new admin user, and post the log again.

Now I took an actual xampplite package and everything worked fine. The difference I can see is the usage of myISAM tables.

Is there an issue with T3 concerning InnoDB - tables? I believe, this 'create new admin user' cannot write into InnoDB. No idea why, but with InnoDB no table row is written.

I now upgraded PHP to version 5.1.4. That did not help at all.
I use MySQL 5.0.17 - yesterday with the InnoDB engine. Changed it now to MyISAM.
When starting the Typo3 configuration (new install, no Typo3 database existing) I now receive at first the following PHP warning:
"Warning: mysql_list_tables(): supplied argument is not a valid MySQL-Link resource in C:\Programme\Apache\Apache2\htdocs\typo3\t3lib\class.t3lib_db.php on line 967"
Despite this I can go on with the whole configuration. I could create a database and import all 32 tables. They were reported to be consistent, but the be_users is still empty.
I uploaded you a new MySQL logfile, which was recorded while creating an admin user via the database analyser. Though it seems to be ok and even Typo3 said "User created", the be_users remains empty...
I also installed an actual stable Joomla release (sorry, just for testing) on my machine - the Apache / PHP / MySQL environment worked perfectly at least for that.

Partly solved!
Have a careful look at http://bugs.typo3.org/view.php?id=2634 !
The problem is still unsolved in Typo3 4.0.1! How difficult is it?

Setting the ses_data blob to NULL in be_sessions via PHPMyAdmin made the backend login possible for me. This might only occur using MySQL > 5.0.3; from that version on a default value for blobs isn't allowed anymore. I installed Typo3 on my providers database (which is MySQL 4.1.20) where I could add an admin user via the database analyser and it worked - without "repairing" the ses_data field!
However, even there the basic admin / password user was not created during the installation.

On my machine it remains impossible to create admin users via the database analyser - the be_users remains empty. But a user created manually with PHPMyAdmin can be used for backend login now.

Also I had difficulties with MySQL 5.0.17 and 5.0.22 using the InnoDB engine. It only works with MyISAM.

I've run into the same problem upgrading from TYPO3 3.7.0 to 4.0.1. I'm using PHP 4.2.2.

I'm still having this problem with Typo3 4.0.1 on a WinXP machine... PHP 5.1.4 and MySQL 5.0.18.

I've changed be_sessions with MySQL Query Browser

DROP TABLE IF EXISTS `typo3`.`be_sessions`;
CREATE TABLE `typo3`.`be_sessions` (
`ses_id` varchar(32) NOT NULL default '',
`ses_name` varchar(32) NOT NULL default '',
`ses_iplock` varchar(39) NOT NULL default '',
`ses_hashlock` int(11) NOT NULL default '0',
`ses_userid` int(11) unsigned NOT NULL default '0',
`ses_tstamp` int(11) unsigned NOT NULL default '0',
`ses_data` mediumblob,
`ses_backuserid` int(11) NOT NULL default '0',
PRIMARY KEY (`ses_id`,`ses_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Don't know how to create admin user manualy

Best regards,
Marko

The underlying reason for this bug (and very likely more) is that Typo3 even in version 4.0.1 does not support databases with deterministic behavior in case of invalid input.

MySQL 5 has a so-called 'strict' mode that disallows inserting rows that do not specify a value for fields declared NOT NULL without DEFAULT. Enabling that mode is a very good idea, because otherwise what happens when an INSERT does not have a value for such a field basically depends on the phase of the moon.

However, in at least two places, Typo3 generates just such queries. One is wherever this bug is, the other is in the install tool, where the admin user is created (see bug #15944, comments #15944 and #15944).

The correct way to fix this is to make sure that Typo3 does not depend on bugs in its database to work correctly. In my opinion, the previous behavior of MySQL was a bug, and the 'strict' mode was introduced to fix it. Now that MySQL's bug is fixed, it is time to fix Typo3's.

Can someone please dig into this and provide a solution?

Can confirm that it is a MySQL strict mode problem. The question I ask myself is if it's something that is really important to solve or not.

I think it should be a sign of bad design in the database design.

Setting the fields in the be_users table to allow null
allow the php script to insert the user in the database table via the "create admin user" in the database analyser.
And setting the fields to allow null in the be_sessions table let you login.
These create a partial cure to the problem.

Change the slq_mode:
Go to mysql config file my.ini and change: sql_mode='MYSQL4';"

Add a user (User "admin" and Password "joh316") with phpmyadmin:

INSERT INTO `be_users`
(`uid`, `pid`, `tstamp`, `username`, `password`, `admin`, `usergroup`, `disable`, `starttime`, `endtime`, `userMods`,
`allowed_languages`, `uc`, `tsconfig`, `usergroup_cached_list`)
VALUES (0, 0, 1133351190, 'admin', 'bacb98acf97e0b6112b1d1b650b84971', 1, '', 0, 0, 0, '', 1, '','', 0);

Login attempts via Mozilla FireFox works correctly, but it's not working via IE or Opera.

All other functionality works well via Firefox
Can following solve correct my problem?

sorry 4 poor english.

disabling the strict mode( introduced to solve mysql 5.0 bug)

1. sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

will certainly get every newbee started.

More Complex solution http://bugs.typo3.org/view.php?id=2634

I just downloaded TYPO src-4.1.1 and testsite 3.8.1 yesterday.
The TYPO3 is still not working correctly with the MySQL 5.X version.

This has been a known problem since November 2005!!!???

Please see original report here :
http://typo3.toaster-schwerin.de/typo3_english/2005_11/msg00811.html

That can't be right, that we have to "downgrade" to MySQL 4.1 just to get TYPO3 to work, without changing the way MySQL 5.X server works, and thereby decrease the power and security within MySQL 5.X...

When will a correct TYPO3 installation / testsite be avaible to overcome this "easy" problem with null and not null within the DB's.

Best Regards
Tim Nielsen
Denmark

I had the same problem in the following installation:
Win 2003 Server, IIS 6, PHP 5.2.5, MySQL 5.0.45, Typo3 4.1.5.
I had to change the sql_mode in my.ini to be able to insert rows in the be_users table, but the problem was not solved yet.

The solution came when I changed the security settings of the directory where PHP stores the session files and gave permission to IUSR_[MachineName] to read, execute and write in it.

I had similar symptoms as described earlier with login problems, on the following setup:

Win 2003 Server x64, IIS 6, PHP 5.2.5, MySQL 5.0.45, Typo3 4.1.5

After researching the topic extensively for several days, I see that Typo3 is struggling with MySQL5 strict mode.

I am not sure what the exact fix is, but when I tried to install a separate script 'phpMyAdmin', it reported I had a missing php extension 'mcrypt'. Furthermore, I had installed php, and mysql via their autoinstaller scripts which had the 'mysql strict mode' set to On by default. Therefore, I uninstalled and then reinstalled php and mysql via the zip NoInstaller packages (manually), and since then login issues have been resolved.

To my understanding it is not necessary to set sql-mode=40 or anything like that, basically if you have any mode like the following, just comment it out with # from your MySQL config file (my.ini)

1. sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

I had the same issues ON Win 2003 server IIS6
typo 4.1.4
PHP 5.2.1
mysql 5.1.22

Change in my.ini

1. Set the SQL mode to strict
   sql_mode="MYSQL4"

created the admin user
now its in the be_users table.

and changed security settings of the directory where PHP stores the session files and gave permission to IUSR_[MachineName] to read, execute and write in it.
can be found in php.ini

Here's an alternative possible "solution", for those of us who have other applications that run on MySQL 5 and can't change the sql_mode globally, or don't have access to the my.cnf/my.ini file.

You can change the SQL_MODE for the typo3 session only with:

SET @@session.sql_mode = 'MYSQL40'

I was going to submit a patch to clss.t3lib_db.php that checks if you are using mysql 5 and then executes the above query right after connecting.

Please correct me, but it looks I could edit config_default.php or localconfig.php and add the query like:

$TYP03_CONF_VARS['SYS']['setDBinit'] = "set @@session.sql_mode = 'MYSQL40'";

-- this would depend on the user knowing that this is the problem, but a programmatic check would probably be an ugly hack that would have to be ripped out once MySQL STRICT is supported

see the MySQL manual entry on sql_mode for details:

http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html

SET SESSION sql_mode='MYSQL40'

looks better.

i solved this for me by changing the table:

ALTER TABLE `be_users`
CHANGE `uid` `uid` INT UNSIGNED NOT NULL AUTO_INCREMENT DEFAULT NULL,
CHANGE `pid` `pid` INT UNSIGNED NOT NULL DEFAULT '0',
CHANGE `tstamp` `tstamp` INT UNSIGNED NOT NULL DEFAULT '0',
CHANGE `username` `username` VARCHAR NOT NULL DEFAULT '',
CHANGE `password` `password` VARCHAR NOT NULL DEFAULT '',
CHANGE `admin` `admin` TINYINT UNSIGNED NOT NULL DEFAULT '0',
CHANGE `usergroup` `usergroup` VARCHAR NOT NULL DEFAULT '',
CHANGE `disable` `disable` TINYINT UNSIGNED NOT NULL DEFAULT '0',
CHANGE `starttime` `starttime` INT UNSIGNED NOT NULL DEFAULT '0',
CHANGE `endtime` `endtime` INT UNSIGNED NOT NULL DEFAULT '0',
CHANGE `lang` `lang` CHAR NOT NULL DEFAULT '',
CHANGE `email` `email` VARCHAR NOT NULL DEFAULT '',
CHANGE `db_mountpoints` `db_mountpoints` varchar(255) NOT NULL DEFAULT '',
CHANGE `options` `options` tinyint(4) unsigned NOT NULL DEFAULT '0',
CHANGE `crdate` `crdate` int(11) unsigned NOT NULL DEFAULT '0',
CHANGE `cruser_id` `cruser_id` int(11) unsigned NOT NULL DEFAULT '0',
CHANGE `realName` `realName` varchar(80) NOT NULL DEFAULT '',
CHANGE `userMods` `userMods` varchar(255) NOT NULL DEFAULT '',
CHANGE `allowed_languages` `allowed_languages` varchar(255) NOT NULL DEFAULT '',
CHANGE `uc` `uc` TEXT NULL DEFAULT NULL,
CHANGE `file_mountpoints` `file_mountpoints` varchar(255) NOT NULL DEFAULT '',
CHANGE `fileoper_perms` `fileoper_perms` tinyint(4) NOT NULL DEFAULT '0',
CHANGE `workspace_perms` `workspace_perms` tinyint(3) NOT NULL DEFAULT '1',
CHANGE `lockToDomain` `lockToDomain` varchar(50) NOT NULL DEFAULT '',
CHANGE `disableIPlock` `disableIPlock` tinyint(1) unsigned NOT NULL DEFAULT '0',
CHANGE `deleted` `deleted` tinyint(1) unsigned NOT NULL DEFAULT '0',
CHANGE `TSconfig` `TSconfig` TEXT NULL DEFAULT NULL,
CHANGE `lastlogin` `lastlogin` int(10) unsigned NOT NULL DEFAULT '0',
CHANGE `createdByAction` `createdByAction` int(11) NOT NULL DEFAULT '0',
CHANGE `usergroup_cached_list` `usergroup_cached_list` varchar(255) NOT NULL DEFAULT '',
CHANGE `workspace_id` `workspace_id` int(11) NOT NULL DEFAULT '0',
CHANGE `workspace_preview` `workspace_preview` tinyint(3) NOT NULL DEFAULT '1'

this just adds DEFAULT '' to all (var)char fields and 'NULL DEFAULT NULL' to text fields

the above fixes only creating of user with step 5 of 1-2-3 installer

use the below SQL to fix session table, for login to work:

ALTER TABLE `be_sessions`
CHANGE `ses_id` `ses_id` VARCHAR NOT NULL DEFAULT '',
CHANGE `ses_name` `ses_name` VARCHAR NOT NULL DEFAULT '',
CHANGE `ses_iplock` `ses_iplock` VARCHAR NOT NULL DEFAULT '',
CHANGE `ses_data` `ses_data` LONGTEXT NULL DEFAULT NULL

(the login fails due to the fact Typo3 BE cannot create new session data due to missing default values)

Dear Damianos Dimitriadis,
thanks a lot for the hint with the session save path. I already searched a long time for a solution, which your hint provided for me! Great!

user's configuraion error