# Creating a frontend login module using Contenido

Author | Timo A. Hummel
Modified | 13th June 2006
Audience | Module Developers
Applies to | Contenido 4.6 or later

## Introduction

The Contenido login mechanism has been made alot easier from Version 4.4 and upwards. Logins are now directly handled by Contenido's frontend, and you only need to pass the parameters "username" and "password" to Contenido. Logins are now handled as "pro-active" logins, which means that the methods explained here need to issued before a protected category is accessed.

## Logging in - manually

Each frontend login can be triggered manually. In order to test your logins, you should insert the following statement into either a layout or module:

    echo $auth->auth["uid"];

This statement shows the current logged in user. For anonymous sessions (i.e. nobody is logged in), the "uid" is always "nobody". To test the login, create a new user in Contenido's Backend, then call the frontend like this:

    front_content.php?username=<youruser>&password=<yourpassword>

If previously the test statement returned "nobody", it should now display your user id.

## Logging in - automatically

Of course, the method above is pretty uncomfortable for end users. You could simply write a module which outputs a login form - it's up to you. All you need to do is to pass "username" and "password" - exactly as shown above.

## Logging out

Of course, your users want to log out if necessary - just pass the parameter "logout" with any value to the system. Example:

    front_content.php?logout=true

## How all this interacts with protected folders

In the past, a login form was only displayed if a protected category. If you are already logged in with the above method, and if you have access rights to that category, everything is alright. But if you are not logged in or if you don't have access rights, the (pretty old) file "front_crcloginform.inc.php" will be called.
If you want to show a custom login form, you can do the following:
Specify a client setting with the following values:

    Type: login_error_page
    Name: idcatart
    Value: <Specify the idcatart of the article containing the login form>

You can also use:

    Type: login_error_page
    Name: idcat
    Value: <Specify the idcat of the category containing the article with the login form>

and/or

    Type: login_error_page
    Name: idart
    Value: <Specify the idart of the article containing the login form>

Please note, that if the idcatart has been specified, idcat and idart are ignored. idcat and idart may be specified both (and then the idart should be an article in the category specified by idcat) or one of them, only.
The article/category specified has to be public/online.

## Creating users

Of course, you don't want to create a user in the backend every time. You can automate the user creation process using the class "User":

    $myUsers = new Users;	// User Collection
    $myUser = new User;	// Single user

    $ret = $myUsers->create("nameofuser");

    /* Note the three equal signs: This checks for the boolean type */
    if ($ret === false)
    {
      /* User already exists */
      die("User already exists");
    } else {
      /* User was successfully created, now we can set the password */
      $user->loadUserByUserID($ret);
      $user->setField("password", md5("theuserspassword"));
    }

You can also assign custom properties to your users (to attach almost every kind of data to a user) by using the methods "setUserProperty" and "getUserProperty". See the API documentation for more information.