Question

Hi,

I am having the same problem as described in Support.ApachePasswordsUnix. I need to ensure users can only 'edit' pages once they are logged into the site, and so have enforced authentication with .htaccess. I followed the instructions as per the TWiki.TWikiInstallationGuide and registration appears to work ok to a certain point:

• Users register using the TwikiRegistrationPub saved as TwikiRegistration form
• The email is sent to them confirming their registration
• A new line is added to .htpasswd file to record their username/password

However, when a registered user then tries to authenticate themselves they are asked their details three times and then sent to the "OOPS - Authentication failed" page, despite the fact that the details supplied were correct.

I have done extensive research on the TWiki Support pages to solve this as it seems to be a fairly common problem (Codev.ApachePasswords, Support.ApachePasswordsUnix, Support.AuthenticationFails, Support.TwikiAuthentication to name a few!), however none of the described solutions seem to help me.

I have noticed that when registering a new user the following lines are printed in the Apache Error Log:

register: Use of uninitialized value in concatenation (.) at /usr/dev/TeamWebsite/twiki/lib/TWiki/Store/RcsLite.pm line 582.
register: Use of uninitialized value in concatenation (.) at /usr/dev/TeamWebsite/twiki/lib/TWiki/Store/RcsLite.pm line 390.
register: Use of uninitialized value in concatenation (.) at /usr/dev/TeamWebsite/twiki/lib/TWiki/Store/RcsLite.pm line 391.
register: Use of uninitialized value in substitution (s///) at /usr/dev/TeamWebsite/twiki/lib/TWiki/Store/RcsLite.pm line 370.
register: Use of uninitialized value in concatenation (.) at /usr/dev/TeamWebsite/twiki/lib/TWiki/Store/RcsLite.pm line 371.
register: Use of uninitialized value in substitution (s///) at /usr/dev/TeamWebsite/twiki/lib/TWiki/Store/RcsLite.pm line 370.
register: Use of uninitialized value in concatenation (.) at /usr/dev/TeamWebsite/twiki/lib/TWiki/Store/RcsLite.pm line 371.
register: Use of uninitialized value in concatenation (.) at /usr/dev/TeamWebsite/twiki/lib/TWiki/Store/RcsLite.pm line 582.

...although the new user seems to be added to the .htpasswd file ok anyway:

<<<.htpasswd file:>>>
TWikiGuest:zK.G.uuPi39Qg
TestUser6:GKoSouimhY3mA
TestUser7:qw7BVMLJG6Q6M

(Note that TestUser6 and TestUser7 both have passwords as "test")

When the login is subsequently rejected, the following line is printed in the error log:

[error] [client 10.216.62.43] user TestUser6 not found: /twiki/bin/edit/ISDCAG/WebHome

Could anybody suggest where I can start looking for the cause of this problem? Is it possible that there is a problem with the way the .htpasswd entries are encrypted and written to file? Any help at all would be really appreciated...

Julie

Environment

-- JulieSmythe - 28 Feb 2005

Answer

This is most likely due to an inconsistency in your authentication setup. Make sure that TWiki.cfg and .htaccess in the bin directory (or however you have your BasicAuth set up) are pointing to the same htpasswd file. Also look at you access_log and error_log. It might be an encryption inconsistency, but I really doubt it, if you are using 'crypt'. You can try manipulating your encryption using the settings in TWiki.cfg and from the command line using the htpasswd program, which supports all the different encryption schemes.

-- CrawfordCurrie - 01 Mar 2005

Hi,

Thanks for your suggestions. I have gone over my .htaccess and TWiki.cfg file with a fine tooth comb and have found that all the paths to my .htpasswd file seem to be alright. However, it seems that the authentication procedure is simply not able to find it.

My password file is located under:

/usr/dev/TeamWebsite/twiki/data/.htpasswd

and has 777 permissions.

My TWiki.cfg file appears to be correct. The relevant areas of it are included below:

$dataDir = "/usr/dev/TeamWebsite/twiki/data"; # Data (topic files) root directory (file path not URL):
$htpasswdFormatFamily = "htpasswd";
if( $OS eq "WINDOWS" ) {
   $htpasswdEncoding   = "sha1";   #windows apache 
} else {
   $htpasswdEncoding   = "crypt";
}
#  Pathname of user name/password file for authentication :
if ( $htpasswdFormatFamily eq "htpasswd" ) {
   $htpasswdFilename   = "$dataDir/.htpasswd";
} elsif ( $htpasswdFormatFamily eq "hdigest" ) {
   $htpasswdFilename   = "$dataDir/.htdigest";
}

In addition, my .htaccess file is located under /usr/dev/TeamWebsite/twiki/bin/.htaccess and has 644 permissions (rw-r--r--). It is as follows:

# bin/.htaccess
#
# Controls access to TWiki scripts

SetHandler cgi-script
AuthUserFile /usr/dev/TeamWebsite/twiki/data/.htpasswd
AuthName 'Enter your WikiName: (First name and last name, no space, no dots, capitalized, e.g. JohnSmith). Cancel to register if you do not have one.'
AuthType Basic

ErrorDocument 401 /twiki/bin/oops/TWiki/TWikiRegistration?template=oopsauth

<Files ~ "[^/]*\.html$">
       SetHandler blabla
       allow from all
</Files>
<Files "viewauth">
       require valid-user
</Files>
<Files "edit">
      require valid-user
</Files>
<Files "preview">
       require valid-user
</Files>
<Files "save">
       require valid-user
</Files>
<Files "attach">
      require valid-user
</Files>
<Files "upload">
       require valid-user
</Files>
<Files "rename">
      require valid-user
</Files>
<Files "rdiffauth">
       require valid-user
</Files>
<Files "manage">
       require valid-user
</Files>
<Files "installpasswd">
      require valid-user
</Files>
<Files "*">
       allow from all
</Files>

Despite all these settings, my error_log still shows up with "user TestUser14 not found" when I try to authenticate. The access_log doesn't seem to show anything unusual. It just lists the pages that have been requested. For example:

10.216.62.43 - - [02/Mar/2005:10:09:18 +1100] "GET /twiki/bin/edit/Main/WebHome?t=1109718555 HTTP/1.1" 401 3149
10.216.62.43 - TestUser14 [02/Mar/2005:10:09:24 +1100] "GET /twiki/bin/edit/Main/WebHome?t=1109718555 HTTP/1.1" 401 3149
10.216.62.43 - - [02/Mar/2005:10:09:28 +1100] "GET /twiki/pub/TWiki/PatternSkin/layout.css HTTP/1.1" 304 -
10.216.62.43 - - [02/Mar/2005:10:09:28 +1100] "GET /twiki/pub/TWiki/PatternSkin/style.css HTTP/1.1" 304 -
10.216.62.43 - - [02/Mar/2005:10:09:28 +1100] "GET /twiki/bin/view/TWiki/ HTTP/1.1" 400 301

Are there any other suggestions as to what might be causing my problem? And how can I get my Tiki.cfg file to print out to the error_log what path it is actually resolving when looking for my .htpasswd file?

The only other thing I can think of is that there may be a problem with my Apache httpd.conf configuration. Currently the TWiki part is set up is as follows:

ScriptAlias /twiki/bin/ "/usr/dev/TeamWebsite/twiki/bin/"
 Alias /twiki/ "/usr/dev/TeamWebsite/twiki/"
 <Directory "/usr/dev/TeamWebsite/twiki/bin">
    AllowOverride All
    Options +ExecCGI
    SetHandler cgi-script
    Allow from all
 </Directory>
 <Directory "/usr/dev/TeamWebsite/twiki/pub">
    Options FollowSymLinks +Includes
    AllowOverride None
    Allow from all
 </Directory>
 <Directory "/usr/dev/TeamWebsite/twiki/data">
    deny from all
 </Directory>
 <Directory "/usr/dev/TeamWebsite/twiki/templates">
    deny from all
 </Directory>

Thanks again in advance. Any help is really appreciated.

Julie

-- JulieSmythe - 01 Mar 2005

I had a similar issue to solve - we authenticate users against their corporate ID so Apache will tell TWiki that they are "OK". I wanted to make sure that the person was also registered with TWiki so I added a bit of code to EDIT.CGI to make check for the existence of the proper "home page" of the person trying to perform the edit. The code (about 2 lines I think) simply checks for the existence of a Main.<corporate-id> -- of course, there is none so the user is directed to register. Works pretty well. I can provide the code snippet but is is very trivial.

-- SteveRJones - 02 Mar 2005

So you did not use .htaccess to achieve authentication? Interesting...

If possible I would prefer to use .htaccess to authenticate my users if anyone has any other suggestions as to the cause of my problem. It's really got me curious now!!

-- JulieSmythe - 02 Mar 2005

There are lots of ways to authenticate; Steve looks up an LDAP directory. I have seen many other authentication schemes in use.

Everything you have done looks right (by inspection) and you have answered all the questions I can think of. I'm left thinking that maybe there is some issue with your BasicAuth Apache module. Unlikely, but possible I guess. Does cancelling the login prompt take you to the registration page?

You might test using BasicAuth without involving TWiki at all. Change your httpd.conf setup for "pub" to be:

<Directory "/usr/dev/TeamWebsite/twiki/pub">
    Options FollowSymLinks +Includes
    AllowOverride None
    Allow from all
    AuthUserFile /usr/dev/TeamWebsite/twiki/data/.htpasswd
    AuthName 'WikiName and password'
    AuthType Basic
    require valid-user
</Directory>

then try and access a file in pub e.g. http://your.server.com/twiki/pub/TWiki/PatternSkin/layout.css - it should prompt for a login. If this fails, then there may be something wierd in your BasicAuth module. Check further back in your httpd.conf.

-- CrawfordCurrie - 02 Mar 2005

this entry looks quite wrong:
10.216.62.43 - - [02/Mar/2005:10:09:28 +1100] "GET /twiki/bin/view/TWiki/http://twiki.org/p/pub/TWiki/PatternSkin/empty.css HTTP/1.1" 400 301 !

perhaps all you need to do is to place a copy of http://twiki.org/p/pub/TWiki/PatternSkin/empty.css on your local TWiki.PatternSkin page ?

perhaps UnresolvedVarsInURL, HttpOneDotOneSupport, SafariBrowserIssues might help...

-- WillNorris - 02 Mar 2005

Hi,

Thanks for all your help so far, but have unfortunately still had no success in finding the source of my problem. I have fixed the problem identified by WillNorris above but fixing this seemed to have no effect on the security problem

I am beginning to wonder if there is something about my Apache set up that is prohibiting my .htaccess from working properly. CrawfordCurrie suggested above that maybe there is something wrong with my BasicAuth module config. I would like to test this, however since it is very difficult for me to change the httpd.conf file I am reluctant to do what he suggested. Could anyone tell me which text in the httpd.conf file actually controls the installation and configuration of the BasicAuth module? For example, is there a "LoadModule BasicAuth" directive or something? My knowledge of Apache is limited so sorry if this is a stupid question!

Many thanks in advance, Julie

-- JulieSmythe

Are you absolutely certain that there is no other .htaccess on the path to your bin directory? Check again; try to log in as a user. Is the prompt for a password the same every time, and is it the prompt you set in AuthName in your htaccess? For example, if there was a .htaccess in your installation directory, that would banjax you.

Oh, and attach your twiki.cfg to this topic, if you feel comfortable doing so. I have a sneaking suspicion.....

-- CrawfordCurrie - 16 Mar 2005

I am having a similar problem (see InvalidActionInRegister) with a freshly installed DEVELOP branch (so my twiki.cfg is in SVN). I will attach my LocalSite.cfg.

-- ArthurClemens - 19 Mar 2005

Hi Crawford,

The prompt for a password from a user is always the same. That is, the same text that I have set in the AuthName directive of my .htaccess file ('Enter your WikiName: (First name and last name, no space, no dots, capitalized, e.g. JohnSmith). Cancel to register if you do not have one.')

I am not sure how to check whether there is another .htaccess file getting in my way like you suggested. One thing that does worry me, though, is that when I execute:

which htaccess

the reply was as follows:

no htaccess in /opt2/pvcs/vm/solaris/bin /opt2/pvcs/vm/common/bin/solaris 
/dba/sybase/ase/12.0/ASE-12_0/bin /dba/sybase/ase/12.0/OCS-12_0/bin 
/usr/bin /bin /usr/sbin /sbin /opt/openssh/bin ./ /opt/SUNWappserver/bin/ 
/opt/SUNWappserver/jdk/bin /opt/SUNWspro/bin/ /usr/sbin /usr/bin /usr/local/bin 
/usr/ucb /usr/etc /usr/ccs/bin /usr/openwin/bin /usr/openwin/bin/xview 
/opt2/pvcs/vm/solaris/bin/admin /usr/dev/TeamWebsite/pvcs/scripts/ 
/usr/dev/TeamWebsite/uat/script/

Does this seem strange to you???

Also, I have attached my TWiki.cfg file and will be happy with any suggestions you may have. Thanks so much for your ongoing help.

Julie

No, not strange. which is for finding programs on the path. You need to find /usr/dev/TeamWebsite -name '.htaccess' -print

I really don;t think this is anything to do with TWiki, but we can try something to establish this: In your .htaccess, before the first "Files" block, add:

<Files "bog">
require valid-user
</Files>

Then add the bog script to the twiki bin directory, as follows:

#!/bin/sh
echo "Content-type: text/plain"
echo ""
echo ""
echo "Squelch"

chmod 777 and run bog from the command line first to make sure it prints the right thing.

• Shouldn't that be chmod 700? -- ArthurClemens - 23 Mar 2005

Then visit http://foddev1:8080/twiki/bin/bog - it should show

Squelch

in the browser. If it requires multiple passwords, that confirms the problem is with your apache setup. If it seems to work OK, then maybe the problem is with TWiki.

-- CrawfordCurrie - 23 Mar 2005

I have followed your instructions. With require valid-user it asks me for a password, but I don't succeed in entering a valid one. With allow from all the page shows Squelch. My error log says:

[Wed Mar 23 02:57:08 2005] [error] [client 194.109.230.189] user arthurclemens: authentication failure for "/devtwiki/bin/bog": password mismatch
egrep: Invalid content of \{\}

But user = arthurclemens= is in my .htpasswd. Could it be that the password sent from the registration form is a different password that I entered? That somehow the password is mangled before it is stored in .htpasswd?

-- ArthurClemens - 23 Mar 2005

Quick query Julie.

Is your SunOS box to give access to PCs on a Windows domain? The only reason I ask is because mod_NTLM is an apache module that makes authentication via the domain very easy and there is a very good set of instructions (WindowsInstallModNTLM) that worked well for me. Just a suggestion if current

-- SteveMayes - 23 Mar 2005

Arthur's question about the disparity in passwords is a good one.

I've been doing a lot of testing of Dakar/DEVELOP I-A-A and often work from resetting the password from the command line.

I'm getting to wonder if the code doesn't produce the same results as the Apache utility, since I can always log in after a command line reset but can never log in after I've requested a password reset as an anonymous user (ResetPassword) and when I try resetting my password after logging in successfully from the papche POV (ChangePassword) the "Old Password" is not accepted.

I'd mark this as a BUG if I could (but its in Support not Codev) and suggest the use of the CPAN module rather than the current code.

See also InvalidActionInRegister

• I've filed the bug report: PasswordsAreMangled -- ArthurClemens - 23 Mar 2005

-- AntonAylward - 23 Mar 2005

Hi all,

I followed your advice, CrawfordCurrie, and created the "bog" file. Like ArthurClemens experienced, it still kept asking me for a password as it does with other Twiki pages. Unlike him, however, my error log states:

[Thu Mar 31 14:53:40 2005] [error] [client 10.216.60.5] user TestUser16 not found: /twiki/bin/bog

(Note: TestUser16 is a valid entry in my password file)

When I type: 'Allow from all' then the page successfully shows Squelch. Does this suggest there is something wrong with my Apache config?

I also executed the command: find /usr/dev/TeamWebsite -name '.htaccess' -print to see if there were any other .htaccess files in the way of the one in /twiki/bin and there doesn't appear to be.

I am really stumped. Any suggestions on where I can go from here? Thanks again to all for your help and patience.

Julie

-- JulieSmythe - 31 Mar 2005

Can you please try reseting the password from the command line using the "htpasswd" command then try to log in.

There is growing evidence that there are a cascading series of bugs in the DEVELOP HtPasswd code which means that its idea f a password and the PAache idea are not in sync.

Despite the "TWiki version: TWikiRelease02Sep2004" in the environment above, I presume from the mention of LocalSite.cfg that you are running DEVELOP.

I'm working on this at the moment, between the times when I have to do things to keep alive and the bills paid :-/

-- AntonAylward - 31 Mar 2005

I haven't gone through all the details of this page yet, but I too can only successfully set passwords from the command shell using htpasswd .

-- MattWilkie - 31 Mar 2005

There are two problems here; one is JulieSmythe's webserver problem, and the other is user registration on DEVELOP branch. Please let's not confuse them; the problem we are discussing here is the webserver problem, which is probably nothing to do with TWiki.

Julie, I'm afraid that the bog has confirmed that your problem is with Apache, and not with TWiki. I don't understand what you mean when you say "when I type Allow from all". Do you mean, when you add that to the .htaccess file? Or when you add it to httpd.conf? In either case, it sounds like you have some sort of restriction on which IP addresses can be used to access your site. If "allow from all" works, then leave it in; see the Apache documentation to understand what it does. The other scripts ought to work as well.

P.S. It might be faster to debug this by talking to people on TWikiIRC (or failing that, on #apache on IRC)

-- CrawfordCurrie - 03 Apr 2005

Hi Crawford,

What I meant when I said "Allow from All" allows me to view the "bog" page is when I change the .htaccess configuration for bog to the following:

<Files "bog">
        Allow from All
</Files>

rather than the initial "require valid-user", I am granted access to the page. Also, when I type the following in the .htaccess file, I am given access to the bog page too:

<Files "bog">
   Order deny,allow
   Deny from all
   Allow from 10.216.60.5    #ie, my IP address
</Files>

I am sure the problem is in my Apache configuration too, although I am not sure how to troubleshoot it. Maybe someone would have an idea if I attached my httpd.conf file...? It's worth a try!!

Thanks for all the help, Julie

-- JulieSmythe - 04 Apr 2005

Well, it would work, wouldn't it - since authentication is only applied when you require valid-user

From a quick look at your httpd.conf I don't see anything fishy. Basic auth is so simple, I'm amazed it isn't working, TBH.

If you want to stop beating your head against this, give up with apache authentication, and install SessionPlugin and AuthPagePlugin and use TWiki-specific logins instead.

-- CrawfordCurrie - 06 Apr 2005

Closing this older question. Please reopen if needed.

-- PeterThoeny - 06 Jun 2005