Hi,

My TWiki constantly says "Login or Register" in the WebLeftBar despite my use of Apache TWiki:TWiki/TWikiUserAuthentication#Enabling_Apache_Login_using_mod and Require valid-user setup via .htaccess.
I believe it should only say so when I come in as TWikiGuest, or never.

TWiki.Org works fine: when I follow the login link there, I'm greeted with my name afterwards. In my TWiki installation, clicking the login link makes nothing happen (the page is rebuilt identically).

I've tried the following, which I've extracted from the WebLeftBar and WebLeftBarLogin templates, where TWiki:TWiki/IfStatements using IF context can_login and context authenticated drive the display:

Registered as %WIKIUSERNAME%.
%IF{"context authenticated" then="Auth context %WIKIUSERNAME%" else="context *not* authenticated"}%
%IF{"context can_login" then="can_login" else="cannot login context"}%

Result is "Registered as JoergHoehle. context not authenticated can_login", which explains the "Login or Register" in the WebLeftBar display.

I came across TWiki:Codev/RegistrationOnDemandHack. It says "It calls the session 'authenticated' just because it finds $ENV{REMOTE_USER}, regardless of whether the user ever registered." My understanding is, REMOVE_USER must be set in my Apache Login .htaccess setup, therefore IF context authenticated should be true. After all, that's how TWiki came to report WIKIUSERNAME to JoergHoehle.

I'm going to attach my LocalSite.cfg in case that's where the error comes from. It's been generated by configure.

My installation is as follows: The TWiki is conceptually in a closed-group setup. Candidate users are told the password of the TWikiGuest user and the URL of the server. Apache requires a valid-user from the data/.htpasswd file via basic authentication (via SSL, so password remains hidden), i.e. a Wikiname login. TWikiGuest access is limited. Users can then use TWikiRegistration with a new WikiName and receive an e-mail with their new password. An admin must set group permissions. Then users need to restart their browser to be able to login using the new identity instead of TWikiGuest. Then they can view more webs than TWikiGuest. Does that make sense? (suggestions are welcome).

In that situation, displaying "Login or Register" for anyone but TWikiGuest is misleading. I believe it's a bug.
I'd expect this message to be displayed only for TWikiGuest. Put differently, if TWiki has WIKINAME other than TWikiGuest, at least in an Apache Login setup, then further login is not needed (and not even possible within the same browser, says the TWiki documentation).

Regards, Jörg Höhle

BTW, please update the Codebase checkbox set to mention 4.0.4

---

You do not need to set REMOTE_USER. It is set in the environment by the CGI module, using authentication information from the browser.

I would strongly recommend you to switch to Template login with sessions. Apache login is inherently limited by the inability to log out, and there is no solution in sight for that (as far as I know). The only reason for using it is on http: sites where password communication is insecure. On your site, SSL will hide all passwords sent to TWiki so Template login is quite safe.

The behaviour you describe - clicking the login link doesn't take you to the login screen - is suggestive of a configuration problem. I have seen this effect when permissions were wrong, for example. I would suggest that you check your webserver error logs for errors and your TWiki warning log. I would also suggest you disable all plugins and see if the behaviour changes.

Later: oh, I just realised you have ClientSessions turned off. Why?

CC

---

I didn't plan to set REMOTE_USER myself. It is already set by CGI/TWiki to JoergHoehle, as well as USERNAME and WIKINAME. I was wondering about the text I quoted which I understood to mean: REMOTE_USER set implies context authenticated. But my IF context test shows this is not the case here. So either:

• I misunderstood the quoted text,
• my test is bogus,
• our installation is faulty,
• the text is right but the TWiki 4.04 code does not implement that specification (anymore?).

Apache login is being used for several reasons:

1. TWikiUserAuthentication says "Firstly, the most secure method is without doubt to use the webserver authentication support, with Sessions turned off."
2. I updated the installation from Beijing. I did not want radical changes. Apache-Login has worked well for years. Users have not complained about the need to restart their browser to change identity from TWikiGuest to their WikiName.
3. The Cookie/session perl module was not present in the Perl installation. But given the above (and my distate about cookies in general), I saw no compelling reason to fetch nor install that module.

Apache login gives me (and others) a good feeling, as it's a known and often audited component. Without a password, nobody gets to run any perl nor custom authorization code. Don't get me wrong: I don't say I distrust the TWiki code base, but there's not enough incentive to depart from proven Apache login IMHO. Also I don't know how plugins react w.r.t. security. A quick test of the genPDF plugin showed that it throws an error trying to access a DENYWEBVIEW page.

The webserver and twiki logs haven't contained an error for days (default configuration). I'll test and report with all plugins disabled as you suggest.

FWIW, I've once heard one can achieve the effect of logout with HTTP Basic (Apache Login) by answering with status 401, maybe twice in a row. Then the browser would prompt anew for a password, and possibly clear the old information. So maybe there's a solution to logout after all (Untested).

Regards, Jörg Höhle

---

I wonder why people recommend Template Login instead of Apache Login.

OK, the login page may look nice but everything else sucks. You have to give username and password again and again and again and again. Especially with Internet Explorer.

I recommend any time to use Apache login. Jörg. Install the session perl module and activate it configure. Apache login and sessions - that flies. But you still have to close the browser to logout - which I can live with. Having to re-authenticate all the time - like I have to here on Bugs - is a pain in butt.

The answering 401 twice sounds interesting. That should be tried.

-- KJL

---

To CC: Checking with Sandboxurl...?debugenableplugins= gave identical results (except for the plugin summary): it still says "Log In or Register"; IF context authenticated takes the ELSE branch. Remote_user reports JoergHoehle -- as expected.

To KJL: Why would I need sessions? My understanding is that with SSL+Apache Login, TWiki has enough information to consistently identify users. Of course, I loose the ability to set e.g. skin=classic once for a session, but I can live with that (and could set my homepage to my preferred skin).

I'm investigating possibilities for misconfiguration.

Regards, Jörg Höhle

---

Correct, TWiki has enough information. Here's how it gets communicated:

Without sessions, apache login:

1. User tries to access page with require valid-user condition
2. Apache pulls user through login process
3. Apache sets REMOTE_USER CGI variable and invokes perl
4. TWiki looks for a cookie, but doesn't find one, so....
5. TWiki sets the user login name to the value of REMOTE_USER

Without sessions, already apache logged in:

1. Apache sets REMOTE_USER CGI variable to logged-in user and invokes perl
2. TWiki looks for a cookie, but doesn't find one, so....
3. TWiki sets the user login name to the value of REMOTE_USER

With sessions, apache login:

1. User tries to access page with require valid-user condition
2. Apache pulls user through login process
3. Apache sets REMOTE_USER CGI variable and invokes perl
4. TWiki looks for a cookie but doesn't find one, so....
5. TWiki sets the user login name to the value of REMOTE_USER
6. TWiki sets a cookie with a session ID

With sessions, already apache logged in:

1. Apache sets REMOTE_USER CGI variable and invokes perl
2. TWiki looks for a cookie and finds one, so uses the session. REMOTE_USER is ignored.

So you see the login process should be almost identical for steps 1 though 5, whether you are using sessions or not. Sessions are mainly there in suppoprt of template login, which you are not using.

CC

Dammed good overview Crawford.

A small supplementary note. To make this all work most of the scripts in the bin directory must be authenticated (require valid-user) - otherwise you end up back not having a REMOTE_USER defined. That is at least my experience. With sessions you do not need to authenticate for example view because TWiki redirects to viewauth if access rights does not allow TWikiGuest.

This last thing is important when you use a slow authentication like LDAP can be in many cases. I have seen 3-5 seconds authentication time. I run a TWiki where no guest access is allowed and it ran dammed slow with Apache authentication via LDAP server 7 time zones away. Then I installed sessions so I no longer had to authenticate view and now it runs at acceptable speed. Only the initial authentication takes a few extra seconds. So sessions can be very useful also with non Template login.

KJL

---

Just to add that I experience the same behaviour here. Using Apache auth, with LoginManager set to TWiki::Client::ApacheLogin, if I have ClientSessions disabled the WebLeftBar never recognises that I am logged in. If I enable them, it does, kinda, but the information is misleading as it allows you to "login" and "logout" despite the fact that you are not really doing so in any meaningful way.

I think session support is not properly compatible with Apache auth. They sometimes interfere. In particular, if the session has a different idea of who you are than the authentication, it can cause huge problems. I have seen this in two different ways:

• User attempts to login with wrong username. Despite auth failure, TWiki starts a session with the invalid username. When the user then auths with the correct username, the session keeps the invalid one and she is denied access (by TWiki ALLOW/DENY*) to things she should have access to.
• Admin user attempts to register another user using TWikiRegistration. The registration process changes the session username to the new user's name, so the admin user no longer has rights to create the user topic, alter TWikiUsers etc, so registration fails -- and the rest of admin user's session is now running as the new user ID which doesn't exist and has no rights to do anything.

I intend to raise a separate bug for the registration issues, but I think the core of this bug is that various bits of TWiki do not honour REMOTE_USER when they should (ie when Apache login is in use and there is no username mapping requirement).

Finally, I would like to correct a misconception that is commonly repeated and IMO TWikiUserAuthentication does not make clear enough. "The only reason for using it is on http: sites where password communication is insecure." Basic auth, which is what most people using Apache auth will be using, is encoded not encrypted. It is totally equivalent to sending the username and password in plain text. You get NO extra security whatsoever. Digest auth is better, but not sure to what extent it is supported in browsers. The only sensible way to make passwords secure in transit is to use SSL, and if you do that, there is no difference in security between using ApacheLogin and TemplateLogin. Sessions and cookies do make a difference -- they reduce security by making it unnecessary to know the username and password for the length of the session. But they have advantages, like avoiding re-authenticating every request as KJL said. So my advice would be, if you want sessions, use TemplateLogin, if you use Apache, don't use sessions. And if ClientSessions is disabled, WebLeftBar's idea of whether someone is logged in or not should be entirely down to whether REMOTE_USER is set.

-- BenJWheeler - 21 Jul 2006

Reading and thinking through all the above, I conclude that the issue here is simply as Ben describes: "_Using Apache auth, ... if I have ...Sessions disabled the WebLeftBar never recognises that I am logged in. If I enable them, it does, kinda, but the information is misleading as it allows you to "login" and "logout" despite the fact that you are not really doing so in any meaningful way._

i.e. there are two perceived problems:

• A valid REMOTE_USER does not set context authenticated if sessions are disabled
• The templates suggest you can log out in apache, when you can't really.

CC

I think I worked out the wrinkles. In the course of doing so, I realised that as REMOTE_USER is only set if the script is authed. Thus if you visit a page view a script that is not authed (such as view, normally) then you will appear not to be logged in. However you are, really, and as soon as you use a script that is require valid-user, your old identity will pop up again.

So you really need either sessions or IP mapping enabled for a login to "stick".

CC

4.1.0 released

KJL