Edgewall Software
Modify

Opened 16 years ago

Closed 14 years ago

#3821 closed defect (worksforme)

problem with login and mod_python

Reported by: Benoit Chesneau <benoitc@…> Owned by: Christopher Lenz
Priority: normal Milestone:
Component: web frontend/mod_python Version: 0.10.3
Severity: major Keywords:
Cc: Axel.Thimm@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

I use apache 2.2.3 and modpython 3.6.10, trac 0.10. The login window don't popup and I have this error when I'm trying to login :

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 356, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 224, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.4/site-packages/trac/web/auth.py", line 95, in process_request
    self._do_login(req)
  File "/usr/lib/python2.4/site-packages/trac/web/auth.py", line 116, in _do_login
    assert req.remote_user, 'Authentication information not available.'
AssertionError: Authentication information not available.

My vhost conf is :

<VirtualHost *>
        ServerName project.archlinuxfr.org
        DocumentRoot /home/trac/archlinuxfr

        <Location />
                SetHandler mod_python
                PythonHandler trac.web.modpython_frontend
                PythonOption TracEnv /home/trac/archlinuxfr
                PythonOption TracUriRoot /
                PythonPath "sys.path + ['/home/trac/archlinuxfr']"
                PythonDebug on
        </Location>

        <Location /login>
                SetHandler mod_python
                PythonHandler trac.web.modpython_frontend
                AuthType Basic
                AuthName "Arch Linux FR - Project"
                AuthUserFile /home/trac/archlinuxfr/.htpasswd
                Require valid-user
        </Location>

        Alias /chrome/common /usr/share/trac/htdocs
        Alias /trac-static /home/trac/archlinuxfr/htdocs

        Alias /trac/ "/usr/share/trac/htdocs/"
        <LocationMatch /trac-static/*>
                SetHandler none
        </LocationMatch>

        <LocationMatch /chrome/common>
                SetHandler none
        </LocationMatch>
</VirtualHost>

any idee ? Akready 6 hours to mess with it whithout any success :\

Attachments (0)

Change History (17)

comment:1 by Benoit Chesneau <benoitc@…>, 16 years ago

url to see this error : http://project.archlinuxfr.org/login

comment:2 by Emmanuel Blot, 16 years ago

Priority: highnormal
Resolution: worksforme
Severity: criticalnormal
Status: newclosed
Version: none

Please ask installation issues on the MailingList, do not submit new tickets - as already detailled in the New Ticket page…

Remove

  SetHandler mod_python
  PythonHandler trac.web.modpython_frontend

from the /login location: Python handler is already defined for the parent location (/)

comment:3 by Emmanuel Blot, 16 years ago

Version: 0.10

comment:4 by Benoit Chesneau <benoitc@…>, 16 years ago

Resolution: worksforme
Severity: normalcritical
Status: closedreopened

I change nothing. In fact I added this to do more tests. sry for that.

comment:5 by Emmanuel Blot, 16 years ago

Resolution: fixed
Severity: criticalnormal
Status: reopenedclosed

comment:6 by Emmanuel Blot, 16 years ago

Resolution: fixed
Status: closedreopened

(wrong action, sorry)

comment:7 by Axel.Thimm@…, 15 years ago

Cc: Axel.Thimm@… added
Severity: normalmajor
Version: 0.100.10.3

This seems to happen when using trac on the root URL like above.

If the URLs are prefixed with for example "trac" then apache's authentication kicks in before mod_python passes control to trac. Otherwise the authentication is skipped and you get the 'Authentication information not available.' output, because mod_python/trac indeed did not get any authentication credentials.

As I'm not that familiar with apache's Handler API and mod_python's, I can't say whether this is a genuine apache/mod_python bug, or whether apache/mod_python consult the trac code before doing authentication and maybe this kills it off.

In any case it makes it very difficult to setup sites dedicated to trac, e.g. where the top URL is already the trac install, so I'm moving it up to a major defect.

comment:8 by Axel.Thimm@…, 15 years ago

It doesn't work on FreeBSD with

httpd-2.2.2, mod_python-3.3.1 and trac-0.10.3

but seems to work on Linux with

httpd-2.2.3, mod_python 3.2.8 and trac-0.10.3.1

comment:9 by mrenzmann@…, 15 years ago

I'm running Trac 0.10.3.1 (plus some personal modifications, none related to the issues discussed here) on Apache 2.2.3 with mod_python 3.1.3 under Debian Etch for http://madwifi.org. We're using short URLs. At this time we make use of the AccountManagerPlugin and it's login form rather than Basic Authentication, but I'm pretty sure I had Basic Authentication running on this host without any issues a few weeks ago.

comment:10 by Axel.Thimm@…, 15 years ago

The AccountManagerPlugin deals with authentication on trac's level, e.g. you have a common Location for everything. Did you have separate Locations ("/" and "/login"), when you tried w/ plain Basic Authentication? If put in one section it works, but then you need to login right from the top URL.

Also, if you have the AccountManagerPlugin working w/ LDAP I would immediately switch to that, but since this is off-topic for this bug (it would be just a workaround) I'll contact you in PM if you'd like to share details, thanks!

comment:11 by anonymous, 15 years ago

This isn't a defect in trac though, so you should move this discussion, as eblot already mentioned, to the Mailing List, or offline entirely —;

comment:12 by Axel.Thimm@…, 15 years ago

I'm not sure this isn't related to trac. If I deactivate the trac environment and only let the mod_python handler working the setup "works" - the trac instance is broken, of course, but authentication under /login is initiated. Once trac gets its environment, trac works, but /login authentication breaks again. Before you ask: I've recreated new trac envs from scratch w/o any non-default settings to test whether my trac env is broken.

Furthermore I already reported this on the list a month ago and there was no solution. I also reported it to mod_python developers.

comment:13 by hyuga <hyugaricdeau@…>, 15 years ago

Hmm…I'm having trouble visualizing from your description exactly what your setup is. Could you post your Apache configuration?

comment:14 by Axel.Thimm@…, 15 years ago

I've done so much testing that I can give you about a dozen configs.

One of the smallest exhibiting the issue is the following

  DocumentRoot /ext/test/empty

  <Location "/">
    Order allow,deny
    Allow from all
    SetHandler mod_python
    PythonPath "sys.path+['/opt/TWWfsw/trac010/lib/python242']" 
    PythonHandler trac.web.modpython_frontend 
### Uncommenting the next line breaks the Location /login
#    PythonOption TracEnv /ext/test/trac
#    PythonOption TracUriRoot /
  </Location>

  <Location /login>
    SetHandler server-info
    AuthType Basic
    AuthName "MyCompany Trac Server"
    AuthUserFile /ext/test/.htpasswd
    Require valid-user
  </Location>

/login is on a arbitrary non-mod_python SetHandler on purpose, in order to demonstrate that Location "/" has an effect on Location /login, even when /login has no mod_python handler anymore. Furthermore I used the simplest authentication possible as the original example was based on LDAP.

The problem is that once trac has an environment to work on access to /login, which previously would return a request for authentication to the browser, doesn't anymore and /login is processed w/o any credentials. If /login is pointing into mod_python/trac again you get the original reporter's "Authentication information not available."

Unfortunately the bug cannot be isolated to either purely apache, mod_python or trac. Only in full combination does the authentication request of /login not happen.

Just to make it clear: The bug means that the user is never asked for a user/password pair, not that one is given and forgotten. If the user had logged in successfully (by disabling trac) and the config is changed to the state that no authentication is requested, the system works!

Which means that the credentials passed by the browser are processed OK, but if the browser hasn't cached them, the server doesn't ask for them.

comment:15 by Matthew Good, 15 years ago

Resolution: worksforme
Status: reopenedclosed

I've tested the config posted in the previous comment on Apache/2.0.55 (Ubuntu) mod_python/3.2.8 just changing the paths for my system and it works fine.

Enabling the TracEnv setting may trigger this problem in some way, but the Trac code is not responsible for this problem. Trac relies on the web server processing the authentication before it reaches Trac, if this does not happen it's either a config issue, or a bug in mod_python or Apache. At this point I think it would be best to take this issue up with the mod_python developers since they obviously have more detailed knowledge of the module.

comment:16 by anonymous, 14 years ago

Resolution: worksforme
Status: closedreopened

I know this issue is old, but I've just spend almost the whole day trying to resolve exactly same problem (<Location /> and <Location /login> not working, whilst Trac installed in subdirectory was working fine).

I've tried everything, read more than hundreds of posts about "Authentication information not available" with "/" location. I even tried downgrading to various versions of mod_python and so on (tried 3.2.10 & 3.2.8).

My setup is: Centos 4.6 + Apache 2.0.63 + mod_python/3.3.1 + Python 2.5.2 + Trac 0.11

Fortunately I had similar server with the same software installed and the strange thing was that on one machine it worked and it didn't work on the second one (!). After comparing all configuration files it turned out that the problem is in the httpd.conf, ErrorDocument Directive for HTTP code 401 broke everything:

ErrorDocument 401 /401.shtml

commenting out this line did the trick.

I'm not a Python programmer so I don't know if this is something that can be fixed on your side, feel free to close it again if you can't create a workaround for it.

comment:17 by ebray <hyugaricdeau@…>, 14 years ago

Resolution: worksforme
Status: reopenedclosed

Yeah, this is still just a configuration issue. Nothing about this can be done from the Trac side.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christopher Lenz.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christopher Lenz to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.