This is intended as a reference for LynnwoodBrown to help him document the DEVELOP auth process.

It's a brain dump, so there's no real structure to it, sorry.

TWiki always uses "on demand" authentication i.e. it requires log-in when an operation is attempted that you have requested is controlled. This can happen in any of three ways:

1. You have told the webserver that a resource (script or file in pub) is protected by require valid-user, and the user has attempted to access it,
2. You have told TWiki that a script is protected by listing it in {AuthScripts}, the user has attempted to use it,
3. An access control exception has been raised by the TWiki internal topic protections scheme.

Here's a full breakdown of how TWiki auth works. Blue is for ApacheLogin, Orange is for TemplateLogin.

1. Webserver checks if access to the "view" script is controlled.
   • If it is, then webserver will prompt the user to login, and will define REMOTE_USER if the login passes.
2. If ApacheLogin and and sessions are activated and no session exists, it checks to see if REMOTE_USER is defined. If it is, it creates a new session.
3. If sessions are not activated, it sess if REMOTE_USER can be used to identify the user.
4. If neither sessions nor REMOTE_USER yield a user identity, then the user is TWikiGuest,
5. If no session exists, but sessions are activated, TWiki checks to see if the script is listed in {AuthScripts}
   1. If it is, then an access control exception is raised.
6. TWiki checks if any of the resources (topics) used in the view are off limits
   1. If so, an access control exception is raised.
7. If we get this far, the user is authorised and access is permitted.

Now, we have to consider what happens when an access control exception is raised.

1. If a session exists, then a redirect to "oops" is done.
2. If ApacheLogin, a check is made to see if a script exists with the same name as the current script, but with "auth" at the end. For example, if the access control violation occurred when trying to "view" a topic, TWiki will look for "viewauth" and redirect to it. If no "auth" version exists, it will redirect to "oops".
3. If Templatelogin, then a redirect to the 'login' script is generated.
4. Otherwise a redirect to "oops" is generated.

We also have to consider what "login" and "logout" mean.

1. To ApacheLogin, "login" means a link to a script called logon that is expected to always be protected by the webserver.
2. To TemplateLogin, "login" means a link to a script called login that prompts for login information.
   • The difference in names is quite deliberate. logon is a pass-through script that is simply there as something to hang the webserver require valid-user directive on. login is a full-featured login page generator. Both scripts are intended to redirect back to the page that generated the login request, though they do this with mixed success.

Here are the "useful" modes of operation:

1. No logins
2. ApacheLogin, sessions disabled, require valid-user on all protected scripts
   • User will not be remembered, login will be required each time a protected script is accessed, though browser will cache login details (IP addresses are no longer recorded). Logout is not supported.
3. ApacheLogin, sessions enabled, require valid-user only on logon script, {AuthScripts} lists protected scripts
   • User will be remembered, logout is not supported.
4. TemplateLogin, sessions enabled, {AuthScripts} lists protected scripts.
   • User will be remembered, logout is supported, {AuthScripts} lists protected scripts.

If cookies not are enabled on the browser, URLs are automatically rewritten to include CGISESSID (the session ID).

it is possible to combine auth systems. For example consider the scenario where basic auth is required to set up a session with the TWiki, for viewing content, but then a proper login is required to change content. in this case you could:

1. Set require valid-user on all scripts and files in pub, so webserver login is required to access the twiki
2. Use TemplateLogin to control edit
   • Obviously not using the same passwd file as the webserver!

Access control to files in pub is hard. pub has to be published in order for things like logos to work. On the other hand, secret data may be stored there. The only solution I have found is to completely disable access to user webs through the browser and to require viewfile requests to get at files in pub. viewfile checks access control permissions (topic granularity). However this means that users can't upload images for inclusion in topics, as the includes are generated as pub URLs (though they can manually rewrite the URLs as viewfile requests). Someone needs to fix this.

-- CrawfordCurrie - 31 Jul 2005

See also : TWikiUserAuthentication and TWikiUserAuthentication