…nerdy by nature!

Recently, I wanted to add the possibility to log directly into Typo3′s backend from some other PHP application without entering the password again. The reason for this was mainly convenience since typing in two different logins (or worse: the same login twice) seems annoying.

Of course, a lot of other people have already done the same thing, so I read around in some blogs/forums…the usual. Most posts pointed out that you need to write a Typo3 backend extension which would do that task for you.

Since I was too lazy to do so, I looked around a bit in the database and the code and came up with a solution which sometimes works and sometimes not…more on that later.

First of all, there was the issue of obtaining the backend user-ID which is stored in the table be_users. You can query that database with anything you got on a user, I used the e-mail address:

SELECT
  `uid`
FROM
  `be_users`
WHERE
  `email`=:email
LIMIT 1;

This is of course done without checking the password. Now the next thing that should be done is to remove all logins, which the following query does:

DELETE FROM
  `be_sessions`
WHERE
  `ses_userid`=:userId;

Typo secures its sessions in several ways, the most tricky one of them is by calculating a hash out of the browser’s user-agent. I believe this one is likely to change in future versions (the original code looks like there could be some additions), but here’s the code that does the magic for the current 4.4 release:

$hashLock=hexdec(substr(md5(":".$_SERVER['HTTP_USER_AGENT']),0,7));

Ok, now with that information (plus a random $sessionId you need to generate), the new session can be created in the database, here’s the query:

INSERT INTO `be_sessions` (
  `ses_id`,
  `ses_name`,
  `ses_iplock`,
  `ses_hashlock`,
  `ses_userid`,
  `ses_tstamp`,
  `ses_data`,
  `ses_backuserid`
) VALUES (
  :sessionId,
  'be_typo_user',
  :userIp,
  :hashlock,
  :userId,
  UNIX_TIMESTAMP(),
  NULL,
  0
);

The last part is to push the cookies to the client, and here lies the most important challenge. By default, Typo locks all cookies to the URL of the backend. However, if no cookies were present yet, one can create & send cookies which are accepted by Typo. First, here’s the code to create the cookies (assuming the backend is located at /typo3, also the cookies here are locked to a SSL-connection):

setcookie("be_typo_user",$sessionId,0,"/typo3/",$_SERVER['SERVER_NAME'],true);
setcookie("typo3-login-cookiecheck","true",0,"/",$_SERVER['SERVER_NAME'],false);

Conclusion

Now in my short tests, the above system always worked when there were no Typo3-generated cookies present yet. So if you want this method to REALLY work, you need to place the script within the same directory as the Typo3 backend so you can write the correct cookies, and you might want to make sure no cookies remain by deleting them first.

So all in all, this method was just a quick hack and currently fits my needs, the better approach is certainly to create an auth extension.

I just got across a bug in Typo3 (v 4.4.0) which took me a good half hour to analyze, fix – just to find out it has already been reported -DUH!!

The problem is, that Typo uses something like the following code to check for safe_mode:

if(ini_get('safe_mode')){
  //safe mode is enabled
}

This is fine as long as you use 1 or 0 to active or deactivate the safe_mode. But since PHP allows to use the words “on” and “off” as well, setting

safe_mode=off

will result in Typo thinking that safe_mode is enabled – although it is off.

I guess the bug will be fixed pretty soon according to the bug report, in the meantime, just replace off with 0 as a workaround.

There are quite a few configuration options in Typo3 which come into play if you intend to run the system completely with UTF-8. And the mean thing is: If you sod up only one of them, chances are good that some things will work but others won’t.
So here’s a list of options I’m currently setting for UTF-8 support.

Settings in localconf.php

The following values need to be set in localconf.php, so you can just set them using the Typo3 install tool.

forceCharset

The value of this field is used by Typo internally for different configuration. You need to set it to UTF-8.

multiplyDBfieldSize

This value sets the size of characters as used in the database. Since in UTF-8, only one character is used, you need to set this to 1 (this is the default).

setDBinit

All statements placed within this value will be sent to the database server each time a new connection is opened. The following two lines should be sufficient to do the magic, if not, set the character_set_server as well:

SET NAMES utf8;
SET CHARACTER SET utf8;

UTF8filesystem

With this field, you tell Typo that your filesystem supports UTF-8 filenames. This is quite important, otherwise Typo will place uploaded files with non-ASCII-characters under invalid names. Set to 1.

If you don’t like the install tool, here’s the PHP code to put into your localconf.php:

$TYPO3_CONF_VARS['SYS']['UTF8filesystem'] = '1';
$TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;'.chr(10).'SET CHARACTER SET utf8;';

Settings in TypoScript

In order to have Typo deliver the page with a valid encoding head, you should also add the following statement in your template.

config{
  additionalHeaders = Content-Type:text/html; charset=utf-8
  metaCharset = utf-8
}

From now on, Typo will use UTF-8 as the default charset on all levels.