From Dokeos

Introduction

This article is about the problem of the anonymous user in Dokeos 1.8 and the solution implemented as a patch to this problem

In Dokeos 1.8.0 (and lower), the anonymous user has no existence. It is not a user database-wise or PHP-wise. It is just nobody. No login information is stored and he can only use some courses if the courses are available to the world, that is, if they let someone without identification enter.

This has two consequences:

• The user has no clear set of permissions (so it is a very abstract notion that isn't easily handled)
• The user cannot be assigned database rows dependend on the user ID, which prevents any tracking of that user's progress, which in turns prevents the user from testing the platform in full.

This second consequence is the reason why the way it worked had to be changed.

Solution to the progress reporting

The solution proposed here consists in assigning an ID to the anonymous user. However, as a patch solution, it will only be assigned (for now) inside tools that require such an ID to work properly. Namely: the learning paths and the exercises.

This means that, inside these tools, the anonymous user must be assigned an ID, and once the user gets outside the course, the ID must be removed so that the behaviour remains just as before for all other tools.

In the following diagram, the red arrows are the type of transition from one page to another that really need to be watched as the fact of having an ID or not having an ID could change the pages behaviour dramatically. The orange arrow are transitions to be watched if they are followed by a transition in red. All green arrows are safe transitions.

To help us in our quest for a nice solution, we now have four functions available from main_api.lib.php (they have been added in Dokeos 1.8.1):

• api_get_anonymous_id() will get the ID of the anonymous user in the database for us. This is the user with status=6
• api_set_anonymous() will check if the user is identified. If not, it will set the variables needed for this user to become the anonymous user
• api_is_anonymous() tells us whether the current user is the anonymous user or not
• api_clear_anonymous() returns the current user (if he is anonymous from a state of anonymous user to a state of nobody/undefined

So we have pretty much everything we need. The next step is to find where to use these functions so as to have the most precise impact on the tools.

We want the anonymous user to work in the exercise and the learning path tool. We do not want it anywhere else. Basically, the last assertion means that we could put a call to api_clear_anonymous() in main/inc/local.inc.php, where the login code already resides. However, this could be impractical. For example, if we have a table of 20000 users and we are currently in the learning path tool as anonymous, this would mean that every request we make triggers a clearing of our user_id and then searches in the users table for the only row (on 20000) that has a status of 6, in order to assign this ID to us.

So to make sure that we don't over-work the server, we are going to do something a bit patchy to always clear the user ID except when we are in specific tools. To do this, in the specific tools, before we load global.inc.php, we are going to set a variable $use_anonymous to true. If local.inc.php (included in global.inc.php) sees that value is set and is true, it will not try to clean the user ID information. If the variable is not set or is false, it will try to clean the user ID information.

There is still a problem though: api_clear_anonymous() first checks if the user is the anonymous user. This check is done by querying the user database again, and this, again, might be a slow operation. So for the sake of saving a hundred of unnecessary requests, we are going to save an additional user information in the session $_user variable: $_user['is_anonymous'] = true; when we assign the anonymous ID. This way, we can rely on the session to tell us if the current user is anonymous or not. An option given to the api_clear_anonymous() and api_is_anonymous() will allow us to force the database check in certain cases.

So, to make it short:

• all scripts in exercises and learning path should set $use_anonymous = true; before calling global.inc.php (a search for global.inc.php in those directories give us the places to look at)
• api_set_anonymous() will set an extra variable in the user information to tell this user is the anonymous user
• api_clear_anonymous() and api_is_anonymous() will get a parameter to force the database check
• local.inc.php will call api_set_anonymous() when $use_anonymous is set and is true, and the user has not logged in another way
• local.inc.php will call api_clear_anonymous() when $use_anonymous is not set or is false, and the user has not logged in another way (which overrides the user data anyway)

Recommendations

Because this system has been implemented late in the Dokeos life, the anonymous user could not reliably get assigned a specific user ID (all IDs might already have been taken and "0" was dangerous in terms of interpretations). As such, the anonymous-user feature relies on a query on the database to get the user with status=6. Because this might be a resource bottleneck on large systems, it is not recommended to use the *anonymous user* feature too extensively. This feature should only be used to demo an exercise or a learning path to a limited subset of users (the ones that don't have normally access to the platform). Also, the tracking is made using one - and only one - user ID, which means that if two anonymous users are using the same learning path or the same exercise at the same time, it might well give some surprising results. This is why this feature is limited to only two tools.

We recommend, if you plan on using this feature extensively:

• to make sure the status column is indexed in your main dokeos database, in the user table
• ask us for more development for a anonymous users pool so that more users can connect and get reliable feedback
• make sure you keep an eye on it to avoid overloading the database