Each user of the backend must be represented with a single record in the table "be_users". This record contains the username and password, other meta data and some permissions settings.

The above screenshot shows a part of the editing form for the backend user with uid=2 and username='guest'. The user is a member of the group 'guest_group' and has English as the default language.

Each user can also be a member of one or more groups (from the be_groups table) and each group can include sub-groups. Groups contain the main permission settings you can set for a user. Many users can be a member of the same group and thus share permissions.

When a user is a member of many groups (including sub-groups) then the permission settings are added together so that the more groups a user is a member of, then more access is granted to him.

This screenshot shows the field for the group title - there are many more fields for access settings! See the following pages.

A user can have a single flag set called "Admin". If this is set the user doesn't need any further access settings since this will grant TOTAL access to the system in the backend! There can be no real limitations to what an "admin" user can do! Like the "root"-user on a UNIX system.

All systems must have at least one "admin" user and most systems should have only one "admin" user. It should probably be the developer with the total understanding of the system. Not even "super users" should be allowed "admin" access since that will most likely grant them access to more than they need.

Admin-users are easily recognized since they have a red icon.

It has often been requested to have more access levels between "admin" users and normal users in a system. This is particularly true when TYPO3 works as a CMS and some users should have access to TypoScript templates in the Web > Template module.

The reason why this is not possible to allow for normal users is that it fails the "PHP-execution criteria". By allowing users to alter TypoScript values in frontend templates you also offer them a way to execute custom PHP code on the server - which in turn means they can create a full "admin" account for themselves easily.

The "PHP-execution criteria" is typically the reason why a certain level of access is not possible to grant non-admin users - simply because they may be able to escalate their rights if they could.

Since both backend users and backend groups are represented by records in the database they are edited just as any other record in the system. However backend users and groups are configured to exist only  in the root of the page tree where only "admin" users have access:

This screenshot shows two backend users, "guest" (regular user - blue) and "admin" (admin user - red), located in the root of the page tree together with the group "guest_group". To edit the users and groups just click the icon and select "Edit" as you would edit any other record. Even creation of new users and groups is done with similar basic tools of the TYPO3 core.

Records located in the page tree root are identified by having their "pid" fields set to zero. The "pid" field normally contains the relation to the page where a record belongs. Since no pages can have the id of zero, this is the id of the root. Notice that only "admin" users can edit records in the page root! If you want non-admin users (eg. a super user) to create new users, please install the "sys_action" extension which supplies an "action" for doing just that.

Before discussing each category, please notice that the online help is quite extensive and useful as well. Click one of the Help Icons in relation to either users or groups and you can get a full description of the table:

Access lists are defined in the user groups and includes

This screendump shows how the addition of elements to the access lists can be done for a user group. Notice that the "Include Access Lists" flag is set - if this is not set, the access lists of a user group is ignored!

The lists of possible values for access lists are automatically updated when new tables, fields, modules and doktypes are added by extensions!

When a user is a member of more than one group, the access lists for the groups are "added" together.

TYPO3 natively supports two kinds of hierarchical tree structures: The page tree (Web module) and the folder tree (File module). Each tree is generated based on the mount points configured for the user. So a page tree is drawn from the "DB Mount" which is one or more page ids telling the core from which "root-page" to draw the tree(s). Likewise is the folder tree drawn based on filemounts configured for the user.

DB mounts (page mounts) are easily set by simply pointing out the page that should be mounted for the user:

If this page, 'Root page A' is mounted for a user, he will see this page tree:

Notice: A DB mount will appear only if  the page permissions allows the user read access to the mounted page (and subpages) - otherwise no tree will appear!

File mounts are a little more difficult to set up. First you have to create a "Filemount" record in the root:

Then you have to assign that mount to the user or group:

If the filemount was successfully mounted, it will appear like this:

Notice: A filemount will work only if the mounted path is accessible for PHP on the system. Further the path being mounted must be found within TYPO3_CONF_VARS[BE][lockRootPath] (for absolute paths) or within PATH_site+TYPO3_CONF_VARS[BE][fileadminDir] (for relative paths) - otherwise the path will not be mounted.

General notes on mountpoints

DB and File mounts can be set for both the user and group records. Having more than one DB or File mount will just result in more than one mountpoint appearing in the trees. However the backend users records have two flags which determines whether the DB/File mounts of the usergroups of the user will be mounted as well! Make sure to set these flags if mountpoints from the member groups should be mounted in addition to the "private" mountpoints set for the user:

"Admin" users will not need a mountpoint being set - they have by default the page tree root mounted which grants access to all branches of the tree. Further the "fileadmin/" dir will be mounted by default for admin users (provided that TYPO3_CONF_VARS[BE][fileadminDir] is set to "fileadmin/" which it is by default).

Page permissions is designed to work like file permissions on UNIX systems: Each page record has an owner user and group and then permission settings for the owner, the group and "everybody". This is summarized here:

1Show: See/Copy page and the pagecontent.

16Edit pagecontent: Change/Add/Delete/Move pagecontent.

2Edit page: Change/Move the page, eg. change title, startdate, hidden.

4Delete page: Delete the page and pagecontent.

8New pages: Create new pages under the page.

(Definition: "Pagecontent" means all records (except from the "pages"-table) related to that page.)

Page permissions are set and viewed by the module "Access":

Editing permissions for a page is done by clicking the edit icon:

Here you can set owner user/group and the permission matrix for the five categories / owner, group, everybody. Notice that permissions can be set recursively if you select that option in the selector box just above the "Save"/"Abort" buttons.

A user must be "admin" or the owner of a page in order to edit its permissions.

New pages and records.

When a user creates new pages in TYPO3 they will by default get the creating user as owner. The owner group will be set to the first listed user group configured for the users record (if any) (available in $BE_USER->firstMainGroup). These defaults can be changed through Page TSconfig.

If you wish to change the default values user/group/everybody it can be done by TYPO3_CONF_VARS[BE][defaultPermissions] (please read comments in the source code of config_defaults.php).

User TSconfig is a hierarchical configuration structure entered in plain text TypoScript. It can be used by all kinds of applications inside of TYPO3 to retrieve customized settings for users which relates to a certain module or part. The options available is described in the document TSconfig.

A good example is to look at the script 'alt_main.php' in which the shortcut frame is displayed in the frameset only if the User TSconfig option "options.shortcutFrame" is true:

if ($BE_USER->getTSConfigVal('options.shortcutFrame'))    {....

Likewise other scripts and modules in TYPO3 is able to acquire a value from the User TSconfig field.

So if we wanted to enable the shortcut frame for a user we would set the TSconfig field of the user record (or any member group!) like this:

... or alternatively this (which is totally the same, just another way of entering values in TypoScript syntax):

Precedence order of TSconfig:

The TSconfig of the users own record (be_users) will be included last so any option in the "be_users" TSconfig field can override options from the groups or the default TSconfig which was previously set.

Further notice that the TYPO3_CONF_VARS[BE][defaultUserTSconfig] value can be configured with default TSconfig for all be_users.

"Admin" users further has a minor set of default TSconfig as well:

admPanel.enable.all = 1

setup.default.deleteCmdInClipboard = 1

options.shortcutFrame=1

Relative filemounts are paths which are mounted relative to the directory given by $TYPO3_CONF_VARS['BE']['fileadminDir']. This value is by default set to "fileadmin/" which is also a directory found on most TYPO3 installations.

In this example the folder "fileadmin/webfolder/" is mounted for a user. "fileadmin/webfolder/" is always relative to the constant PATH_site.

If you want to make this filemount work it requires - of course - that the path "fileadmin/webfolder/" is in fact present below the PATH_site. That is not yet the case if you did the core installation from the introduction chapter of this document. So the following steps will prepare the directory for use from scratch (on a UNIX box):

[root@T3dev coreinstall]# mkdir fileadmin/

[root@T3dev coreinstall]# mkdir fileadmin/webfolder/

[root@T3dev coreinstall]# chown httpd.httpd fileadmin/ -R

("mkdir" means "Make Directory", "chown" means "Change Owner". They are UNIX commands)

Notice how ownership of the created folders is changed to "httpd" which is the UNIX-user that Apache on this particular server executes PHP-scripts as.

If $TYPO3_CONF_VARS['BE']['fileadminDir'] is false, no relative filemounts are allowed.

Remember that "admin" users will have the $TYPO3_CONF_VARS['BE']['fileadminDir'] path mounted by default - all other users requires a "Filemount" record to be created and added to their user record/member groups.

Since relative filemounts are located within the document root of the website, the URL of the mounted "fileadmin/webfolder/" would be for example "http://www.my-typo3-site.org/fileadmin/webfolder/" provided that "http://www.my-typo3-site.org/" is the domain of the frontend.

The alternative to relative filemounts - which enables people to upload files into the webspace of the site! - is absolute filemounts. These can be mounted "internally" on the server and thus manage files which are not available from a URL. The requirement for this is that $TYPO3_CONF_VARS['BE']['lockRootPath'] is set to match the first part of any absolute path being mounted.

In this case "/my_absolute_path/another_dir/" is mounted.

Before this will work we will have to configure 'lockRootPath'. In typo3conf/localconf.php, enter:

$TYPO3_CONF_VARS['BE']['lockRootPath']='/my_absolute_path/';

Also create the directories:

mkdir /my_absolute_path

mkdir /my_absolute_path/another_dir/

chown httpd.httpd /my_absolute_path/ -R

Safe mode restrictions

Notice that safe_mode and other security restrictions might prevent PHP from working on files outside the document root and thus prevent absolute filemounts from working! See the "Installing and Upgrading TYPO3" document for more details on how to run TYPO3 on safe_mode / open_basedir environments.

TYPO3 also features the concept of "home directories". These are paths that are automatically mounted if they are present at a path configured in TYPO3_CONF_VARS. Thus they don't need to have a file mount record representing them - they just need a properly named directory to be present. Home directories are nice if you have many users which need individual storage space for their uploaded files or if you want to supply FTP-access to TYPO3 - then the safer option is to allow users FTP-access to a non-web area on the server. Then users can access those files from TYPO3.

The parent directory of user/group home directories is defined by $TYPO3_CONF_VARS['BE']['userHomePath'] and $TYPO3_CONF_VARS['BE']['groupHomePath'] respectively. In both cases the paths must be within the path prefix defined by $TYPO3_CONF_VARS['BE']['lockRootPath']! Otherwise they will not be mounted (as with any other absolute path).

Lets configure:

$TYPO3_CONF_VARS['BE']['lockRootPath'] ='/my_absolute_path/';

$TYPO3_CONF_VARS['BE']['userHomePath'] ='/my_absolute_path/users/';

$TYPO3_CONF_VARS['BE']['groupHomePath']='/my_absolute_path/groups/';

Lets create:

mkdir /my_absolute_path/users/      

mkdir /my_absolute_path/users/2/

mkdir /my_absolute_path/users/1_admin/

mkdir /my_absolute_path/groups        

mkdir /my_absolute_path/groups/1

chown httpd.httpd /my_absolute_path/ -R

These lines create

Notice how one user home dir is named "1_admin" where "1" is the user uid and "admin" is the username. When user dirs are mounted TYPO3 first looks for a directory named "[uid]_[username]", then - if not found - for a directory named "[uid]". So the username is optional and can be a help if you want to identify a users directory without having to look up his uid. However changing the username will break the link to the directory of course.

After having created these directories and configured TYPO3_CONF_VARS to set them up, the folder tree looks like this for the admin-user of the core_install:

Here are some comment to the screenshot:

(The two yellow folders named "test" are some that have been created as a test from the backend.)

If we log in as the user "guest" (uid=2) we should also see some mounted directories:

TYPO3 detects if mounted paths are reaching into the domain of the PATH_site constant. If that is the case the folder is recognized as being in the "Web-space" (yellow folder icon). If a folder is not within PATH_site it is assumed to be a folder internally on the server and thus in "FTP-space" (blue folder icon).

The significance of this is what kinds of files are allowed the in the one and in the other "space". This is determined by the variable $TYPO3_CONF_VARS['BE']['fileExtensions']:

            'webspace' => array('allow'=>'', 'deny'=>'php3,php'),

            'ftpspace' => array('allow'=>'*', 'deny'=>'')

This configuration is the default rule on file extensions allowed within each space. Basically it says that in FTP-space all files are allowed, but in Web-space "php3" and "php" is disallowed!

Having restrictions like this also means that unzipping of files and moving whole directories from FTP- to Web-space is not possible within the backend of TYPO3. This can be expressed as these rules:

(see the classes basicfilefunctions, extfilefunctions and tce_file.php plus the document "TYPO3 Core API")

Notice: In addition to the rules set up in $TYPO3_CONF_VARS['BE']['fileExtensions'] there is a global regex pattern which will also disqualify ANY file matching from being operated upon. That is set in $TYPO3_CONF_VARS['BE']['fileDenyPattern'].

For details about the configuration of these options please read the source comments in "t3lib/config_default.php".

Currently not know if it works and what limitations it might have. Probably they have to be on the same harddisk as the main site.

Logging in now, this is what the user will see:

Click the "Create new" icon:

... enable the access lists, and add the relevant entries:

Edit the user record again and set the membership of the group:

Logging in now, this is what the user will see:

Either do this for the group you created or for the user record itself. If you chose to set up the DB mount for the group you will be able to share the DB mount for all members of that group that has the "Mount from groups:" / "DB Mounts" flag set.

Then make sure to set the permissions recursively for that page so either the user owns the page and subsequent pages or that the user is member of the group owning the pages (or of course allowing "everybody" access).

Then select the permissions you want to assign. In this example the user will be the new owner and his member group will be the group of the pages three levels down. Other configurations can work as well of course. Most importantly for the DB mount is that the "Show page" permission is set for the DB mount page. Otherwise the mount will not even be shown!

Result:

Logging in now, this is what the user will see in the Web > List module:

Optionally you can create a file mount for the user. It's not a requirement since users can upload files directly in editing forms, but it might be more flexible for your users if they can create a online archive of files for reuse.

Most typically a user has access to a subfolder in "fileadmin/". This can be achieved like this:

Create the Filemount record:

Create the folder "fileadmin/user_uploads/":

Since you as an "admin" user has access to "fileadmin/" by default, you can do this easily through the backend:

Add the file mount record to the File mounts of the group "New group":

Make sure the flag "Mount from groups:" / "File Mounts" is set:

Logging in now, this is what the user will see in the File > List module:

Apart from edit, disabled and delete buttons located in the "User Admin" module you can also switch user easily by a single click if the [SU] button:

You cannot switch back for security reasons, so you will have to logout and login as "admin" again. However this feature is extremely practical if you need to login as another user since you don't have to expose/change their passwords!

Tip: Running MSIE (at least) you can start MSIE twice from the Program Menu and each instance will have a different process and "cookie-scope"; The point is that you can login as "admin" in the one MSIE browser window and as another user in the other window - in the same database! This is possible because the two MSIE instances "don't know" about each other.

However you don't have to switch user to just check how that user would see the backend. You can simply click the username and you will have a nice view like this:

This basically lists all information you could dream of for that user. In particular the calculated permissions for "This user" (1) is nice since that is the sum of the user/group/everybody permissions as they will apply to this user for each page in his DB mounts.

"Non-mounted readable pages" (2) could potentially be a security problem. Those pages are not mounted as DB mounts and thus not visible/clickable in the page tree. But guessing an id of one of those pages and sending that id to the Web>List module would list records on these pages. Most likely you don't want that. Further the danger is even more serious if you have Frontend Edit enabled in the CMS frontend. However there is no problem unless you change a default setting; As long as TYPO3_CONF_VARS['BE']['lockBeUserToDBmounts'] is true (which it is by default) pages will be accessible only if the they appear within the DB mounts - that makes security management a whole lot easier since you don't have to worry about "Non-mounted readable pages" at all.