After working through a plan to upgrade an old Trac installation from
version 0.12 to 1.6, due to the need to shift to python 3, I believe I have
discovered an issue with how Python 3 is parsing cookies when they are
"invalid" cookies present for a session.

First of all, I have made a small change to the code of trac/web/auth.py
that seems to work for my environment where the entire Trac installation
requires authentication to access.  Trac receives the REMOTE_USER
information from wsgi, but the trac_auth cookie may not be set on a user's
initial login.  My code change is in the authenticate function:

--- auth.py.orig        2025-03-04 17:46:22.942392186 -0500
+++ auth.py     2025-03-05 16:59:47.074857014 -0500
@@ -91,13 +91,28 @@

     def authenticate(self, req):
         authname = None
+        # following added by cshelton - 1/22/2025
+        self.env.log.debug("in authenticate function")
         if req.remote_user:
             authname = req.remote_user
+            self.env.log.debug("REMOTE_USER is copied to authname as %s",
authname)
+            self.env.log.debug("request cookies are %s",
req.incookie.output)
+            if not 'trac_auth' in req.incookie:
+                self.env.log.debug("no trac_auth cookie found, so empty
authname and return None")
+                return None
+
         elif 'trac_auth' in req.incookie:
             authname = self._get_name_for_cookie(req,
                                                  req.incookie['trac_auth'])
+            self.env.log.debug("found trac_auth cookie")

         if not authname:
+            self.env.log.debug("authname not set, returning None")
             return None

         if self.ignore_case:

This change causes the authenticate function to return None if the
remote_user is set, but there is not a trac_auth cookie present.  This
triggers the noanonymousplugin to redirect the request to /trac/login, to
set the trac_auth cookie, then redirects back to the page the user was
trying to access.

This setup has been working well for several years with my Trac 0.12
installation, but has been inconsistent with Trac 1.6.  After much
frustration, I finally discovered this issue reported by the Django project:
https://code.djangoproject.com/ticket/26158
The issue that I am having is very similar to this one, in that there are
several cookies regularly set by a large ERP system used by my organization
that are presented to my Trac installation.  There is at least one invalid
or unnamed cookie set at a higher level (.iu.edu), while my Trac
installation runs at a subdomain (.prvt.controller.iu.edu).

When I remove the cookies for the .iu.edu domain, or when running Trac in
an incognito window, it behaves normally.  But when the .iu.edu cookies are
present, Trac (or really Python) fails to parse any cookies at all, leading
to a redirect loop when trying to initially login.  The Django project
ticket noted that python 3 will fail to parse any cookies at all when only
one invalid cookie is found.  Their workaround for this issue was to write
their own cookie parsing routine, and remove references to SimpleCookie and
BaseCookie:
https://github.com/django/django/commit/93a135d111c2569d88d65a3f4ad9e6d9ad291452

Would it be possible to implement a similar fix for Trac to manually parse
cookies instead of relying on the python3 cookie code that seems to discard
all cookies if only one cookie is "bad"?  I am tempted to try to implement
a similar change in Trac as the Django project, but my python coding skills
need some improvement.

Thanks for any advice regarding how to best implement a fix for this issue.

Chris

-- 
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/trac-users/CAB0jkdxDbb5VKT8OS08UDUMV8Jq3BevB6TkHZPj%3D2MdfbDnqxA%40mail.gmail.com.

Reply via email to