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:
- TWikiUserAuthentication says "Firstly, the most secure method is without doubt to use the webserver authentication support, with Sessions turned off."
- 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.
- 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:
- User tries to access page with
require valid-user
condition
- Apache pulls user through login process
- Apache sets
REMOTE_USER
CGI variable and invokes perl
- TWiki looks for a cookie, but doesn't find one, so....
- TWiki sets the user login name to the value of REMOTE_USER
Without sessions, already apache logged in:
- Apache sets
REMOTE_USER
CGI variable to logged-in user and invokes perl
- TWiki looks for a cookie, but doesn't find one, so....
- TWiki sets the user login name to the value of REMOTE_USER
With sessions, apache login:
- User tries to access page with
require valid-user
condition
- Apache pulls user through login process
- Apache sets
REMOTE_USER
CGI variable and invokes perl
- TWiki looks for a cookie but doesn't find one, so....
- TWiki sets the user login name to the value of REMOTE_USER
- TWiki sets a cookie with a session ID
With sessions, already apache logged in:
- Apache sets
REMOTE_USER
CGI variable and invokes perl
- 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