I have noticed that the user preferences are applied only after authentication. If the edit command is open to all then all pages are shown with the guest preferences.

Add authentication also to the view command if you want to be recognized always.

If you see here (in view) Main.TWikiGuest = Main.TWikiGuest then I'm right.
Notice that in Preview you will see above your TWikiName.

-- AndreaSterbini - 01 Sep 2000

This is not a bug, that is spec for basic authentication. Basic authentication supplies the REMOTE_USER name only for autheticated pages. FYI.

-- PeterThoeny - 03 Sep 2000

Thanks, do you know if there is some way to retain the remote user information also for non authenticated pages?

-- AndreaSterbini - 04 Sep 2000

This could be done in several ways:

1. Use cookies instead of basic authentication ( REMOTE_USER ). Cookies are controversial, I'd rather not rely on them.
2. Remember the IP address of the REMOTE_USER when present (e.g. edit) then associate IP address with user when user views pages. This fails in case the user IP address changes (i.e. when DHCP lease expired)
3. Use basic authentication for all actions, including view . This could be controversial, e.g. "why do they need to know my name to view content?"

-- PeterThoeny - 06 Sep 2000

The other option to cookies is embed session ids in the URI. Either/or should be something that can be abstracted away from the adminstrative side with modulisation.

-- NicholasLee - 07 Sep 2000

If you really want all users authenticated, you can put require valid-user at the top level of your .htaccess. I have an account like TWikiGuest/guest and in the realm, I say: Use TWikiGuest (password=guest) for guest access.

-- AlWilliams - 12 Sep 2000

I dont' want users to be authenticated for view only. What I want is that, once the user has been autenticated , the following view calls remember who is the user.

A possible solution is to use SessionVariables.

-- AndreaSterbini - 14 Sep 2000

I would rather prefer not to use SessionVariables for figuring out who the remote user is in view. This is mainly because a page would have many URIs, i.e. copy&paste of a URL is not feasible anymore.

I like however the idea of keeping track of the user once he/she is authenticated.

• Cookies could be used silently if enabled on the client side.
• TWiki could keep a table of REMOTE_USER and IP address. The table gets updated each time the REMOTE_USER is not empty. In case it is empty as in view , the user can be mapped by IP address. Note that works reliably only with static IP addresses on a LAN. It will fail:
  • When the lease of an IP address expires (for dynamically assigned IP addresses with a DHCP server).
  • When more then one user sits behind a proxy server that has only one IP address to the outside (and TWiki sits on the outside).

-- PeterThoeny - 14 Sep 2000

I implemented an optional lookup of the username by IP address. TWiki remembers the IP address / username pair whenever an authentication happens (edit topic, attach file). Once remembered, the non authenticated scripts like view will show the correct username instead of guest. Please note that this can fail in case the IP address changes due to dynamically assigned IP addresses.

Variable $doRememberRemoteUser in wikicfg.pm is a flag to enable or disable this behaviour. If set, a hash table of IP address and remote username is updated when users are authenticated. The hash table is persistently stored in file $remoteUserFilename ( "$dataDir/remoteusers.txt" by default)

• Test: Current %WIKIUSERNAME% is TWikiGuest.
  (This shows TWikiGuest in case you have never been authenticated, or your WikiName after you have been authenticated once)

Commited to TWikiAlphaRelease.

-- PeterThoeny - 05 Oct 2000

Is there a timeout, or logout command, to remove the IP-to-user link? For example, I may be using a lab PC and want to edit a page with authentication so that it's logged properly, but someone else may come along and use it later. Ideally, a 'signout' feature should be provided along with this authentication (as is common with cookie-based authentication such as Yahoo Mail's).

Cookies are not a bad option as long as the option is part of the login page, defaulting to off but configurable per installation.

RichardDonkin - 03 Dec 2000

A logout that removes the IP-to-user entry could be done, but that would not be enough, since basic authentication under HTTP doesn't have the concept of logging in - it has the concept of requiring a username and password before a single file is sent from the server to the browser. After that file is sent, nothing has changed on the server, so there is no session to 'terminate'. If someone is able to access multiple files without reentering the password it is because the browser remembers the password, and since the server has no control over this action of the browser, you can't make it "forget" the password, either. The only way to "log out" is by restarting the browser.

I have been searching around the web. One intersting note I found is that the browser will "forget" the password when it receives a "401 unautorized" HTTP-Code. This possibly could be used, dunno.

The other possibility is to use cookies where possible and revert to basic authentication otherwise.

-- PeterThoeny - 03 Dec 2000

Peter says: 'The only way to "log out" is by restarting the browser.' - does anyone know whether this is true, and if not how we might implement a log-out and log-in button? After all, plenty of places provide log-in/log-out. (Oh, or do all those other places use Cookies? And in a corporate environment who cares if TWiki uses Cookies?)

-- MartinCleaver - 11 Jul 2001

I believe Peter is correct. I think cookies are almost always used for this - not that they are not persistent cookies. URL re-write can also be used, but there are issues.

-- JohnTalintyre - 11 Jul 2001

We have written code to integrate TWiki with SiteMinder and are in the process of making this a Plugin.

We found that we needed to alter the core code because

1 Plugins are not initialised before $remoteUser is set. 2 Introduce a call to our code to set the $remoteUser variable based on what SiteMinder says the user is.

Can I suggest that Plugins are initialised before remoteUser is set and that a hook in the Plugins architecture is introduced to query the plugins if they have an idea of who the user really is? Ta.

-- MartinCleaver - 30 Oct 2001