Typo3: show login page for protected pages when user not is logged in

The problem: If you have pages which are only accessible for certain FE user groups, some of your users may bookmark these protected pages and return when they are not logged in (or you may send the URLs in a newsletter, etc.). Typo3 handles this case as a “404 Page not found” situation (I don’t know why they think 401/403 and 404 are the same, but I can’t change it).

So if you want to show a login form in this case, but a 404 error page if the page is “really” not there, you have to write a user-defined page-not-found-handling function. I have put it into fileadmin/404.php:

Then set this in your typo3conf/localconf.php:

$TYPO3_CONF_VARS['FE']['pageNotFound_handling'] =
'USER_FUNCTION:fileadmin/404.php:user_pageNotFound->pageNotFound';

Put a felogin content element onto the login page (here: login.0.html) and set the redirect options like to: login,loginGroup,getpost

So, what happens if the user goes to a protected page when (s)he is not logged in?

1. Typo3 detects that the page is not accessible and calls our page not found handler.
2. The handler detects that it is not a real 404 error but the page is proected and redirects to login.0.html?redirect_url=<original url>
3. The user logs on.
4. Because getpost is set as a redirect option, the user comes back to <original url>.

Important hint: It took me hours to find out that the redirect options don’t work if the login page has front end user group privileges set. It seems to work only if it’s on a public page.

Also make sure that the LOGIN_URL is found on the system, or you will have a recursive loop calling the 404 page.

Typo3: htmlRTE “Zebra” tables (classes for odd/even rows) using TSConfig

It took me some hours and the documentation is not very good, but finally I have found out how to mark up table rows from RTE tables (not elements with content type “table”) with alternating CSS classes. Put this into your page TSConfig:

RTE.classes.zebra-rows {
  name = Zebra table
  alternating.rows {
    startAt = 1
    oddClass = odd
    evenClass = even
  }
}

RTE.default {
  ignoreMainStyleOverride = 0
  inlineStyle.zebra-tables (
    table.zebra-rows { }
    table.zebra-rows tr { background: lime; } /* or whatever color */
    table.zebra-rows tr.odd { background: red; } /* or whatever color */
  )
  classesTable = zebra-rows
  classesTR = odd, even
  proc.allowedClasses := addToList(zebra-rows, odd, even)
)

Then you only have to assign the block style “Zebra table” in the RTE.

It is also be possible to put the styling into a content CSS file. In that case, you have to set ignoreMainStyleOverride=1, contentCSS=path/to/content.css and then omit the inlineStyle lines.

For ideal table processing, put this into your TypoScript setup (not TSConfig):

lib.parseFunc_RTE.externalBlocks = ul,ol,table
lib.parseFunc_RTE.externalBlocks.table.stdWrap.HTMLparser.tags.table.fixAttrib.class.list >
lib.parseFunc_RTE.externalBlocks.table.HTMLtableCells.default.callRecursive = 0
lib.parseFunc_RTE.externalBlocks.table.HTMLtableCells.default.stdWrap.parseFunc {
  makelinks = 1
  makelinks.http.keep = scheme,path,query
  makelinks.mailto.keep = path
  tags {
    link = TEXT
    link {
      current = 1
      typolink.parameter.data = parameters : allParams
    }
  }
}

It makes the table class zebra-rows working and prevents wrapping table cells with <p> etc. while keeping links intact.

Have fun!

Typo3 acceleration experience

How to accelerate Typo3 for a page with relative high load?

No statistically significant data but just a few benchmarks (made with ab) for the feeling:

Typo3 (no_cache = 1): ~ 1 rq/s
Typo3 (with cache): ~ 3 rq/s
Typo3 (with cache and eAccelerator): ~ 50 rq/s
Typo3 (with cache, eAccelerator and Squid reverse proxy): ~ 2000 rq/s

Creating an empty Typo3/4.2 installation that supports UTF-8

I always use UTF-8 with my Typo3 installations even if it’s not needed in the first version of the Web site because translation is a requirement often arises at a later time.

The way I create my new, empty Typo3 4.2 installation that fully supports UTF-8:

• Create the database with

  CREATE DATABASE tt_new_site DEFAULT CHARSET 'UTF-8';

  GRANT ALL ON tt_new_site.* TO 'new_site'@'localhost' IDENTIFIED BY 'password';

• Unzip the dummy.zip from typo3.org into the new installation’s directory
• Create correct typo3_src symlink
• Set permissions correctly (I made a script for this)
• Create typo3conf/ENABLE_INSTALL_TOOL
• Do necessary Web server setup
• Go to http://new_site/
• Do not use the 1-2-3 setup, but go to the Install Tool directly
• In “Basic Configuration”, set database name + username, password, host, site name, encryption key, [GFX][gdlib_png], [GFX][TTFdpi]=96
• In “Update Wizard”, “upgrade” to the newest Typo3 version. This will do nothing other than setting compatibility mode to Typo3 4.2 in localconf.php.
• In “All Configuration”, set [BE][forceCharset]=utf8, [SYS][no_pconnect]=1.
• In “Database Analyser”, choose “COMPARE” and let Typo3 create the tables. Because we have specified UTF-8 as the database’s default character set and also set forceCharset correctly, the tables will be created with the UTF-8 character set. Then “Create admin user” (don’t use admin as the user name for security reasons).
• Log in to the back end, do the things to remove the 3 warnings (comment the $TYPO3_CONF_VARS[‘BE’][‘installToolPassword’] line in typo3conf/localconf.php, remove typo3conf/ENABLE_INSTALL_TOOL and run the reference check).
• Now you’ve got a fresh Typo3 installation with all basic settings done, including UTF-8 support.

Some extensions have problems with UTF-8. For instance, I run into problems with qcom_html_cleaner, don’t use it until the UTF-8 problems are fixed.

Typo3: still 30 % vulnerable to latest critical security hole

A quick scan of sites made with Typo3 told me that 99 of 330 pages are still vulnerable to the last Typo3 security bug that allows to read all .php files, including localconf.php (where the database password and other things ard stored) at the moment.

That means that about 30 % of all Typo3 pages show their database passwords (and other things) in clear text 5 days after the security bulletin has been sent out.