403 Forbidden error no longer redirects user to log in

[clinton@…]

In prior versions, a user who is not logged into the Trac environment and where insufficient privileges have been granted to 'anonymous', the error message would be shown to the user but also a prompt to login to resolve the problem would be shown as well.

In Trac 1.0.1 (possibly earlier, but post-0.12), when this situation occurs, a generic HTTP 403 error is returned.

Setting the priority to high, because in the past, whereas you could email or record links in the form of http://server.com/trac/ticket/112, and a user clicks on this link, they would be prompted to login to access the ticket. Now, however, they get a generic message and it's very difficult to understand what you need to do.

The following patch resolves the problem for me:

--- a/trac/web/main.py	Tue May 07 14:33:28 2013 -0400
+++ b/trac/web/main.py	Wed May 08 14:28:34 2013 -0400
@@ -500,10 +500,12 @@
             pass
 
         resp = req._response or []
+
     except HTTPException, e:
-        _send_user_error(req, env, e)
+        resp = _send_user_error(req, env, e)
     except Exception, e:
-        send_internal_error(env, req, sys.exc_info())
+        resp = send_internal_error(env, req, sys.exc_info())
+
     return resp
 
 
@@ -546,6 +548,8 @@
         resp = req._response or []
         pass
 
+    return resp
+
 def send_internal_error(env, req, exc_info):
     if env:
         env.log.error("Internal Server Error: %s",
@@ -637,8 +641,11 @@
     try:
         req.send_error(exc_info, status=500, env=env, data=data)
     except RequestDone:
+        resp = req._response or []
         pass

+    return resp
+
 
 def send_project_index(environ, start_response, parent_dir=None,
                        env_paths=None):

[Christian Boos]

Well, first that should still be the case (try ​http://trac.edgewall.org/demo-1.0/wiki?action=edit don't you see there what you refer to as the "prompt to do the login"?).

Second, the changes you did shouldn't make a difference, I think that resp as returned by _dispatch_request will always be [], before and after your changes (but please verify this on your side).

[anonymous]

I'll admit that I was a bit hasty and didn't thoroughly test all of my changes. The minimal change that is necessary to fix my problem is this:

--- a/trac/web/main.py	Tue May 07 14:33:28 2013 -0400
+++ b/trac/web/main.py	Wed May 08 20:03:14 2013 -0400
@@ -501,9 +501,11 @@
 
         resp = req._response or []
     except HTTPException, e:
-        _send_user_error(req, env, e)
+        resp = _send_user_error(req, env, e)
     except Exception, e:
         send_internal_error(env, req, sys.exc_info())
+
+    env.log.warn('resp is %s' % (resp))
     return resp
 
 
@@ -546,6 +548,8 @@
         resp = req._response or []
         pass
 
+    return resp
+
 def send_internal_error(env, req, exc_info):
     if env:
         env.log.error("Internal Server Error: %s",

Without the patch, what I see in my browser is in the attached screenshot.

The above patch indicates where I log what's in resp. In some cases, it is not [], but contains the HTML document that includes the "You are not logged in" notice.

Anyway, I find that the code here:

         resp = req._response or []

in _send_user_error() to be very strange, if the intent is not to return resp. Obviously I am not that familiar with the Trac code base, so I've only been hacking at it to get it to work.

[Christian Boos]

Well, what your patch does is to return None instead of []… Not sure why this makes a difference in your setup, but for me (testing with tracd), it doesn't make a difference (i.e. it works in both cases).

• what is your web front-end (e.g. Apache httpd + mod_wsgi)?
• do you observe the same behavior when serving over http:?

[Christian Boos]

Replying to cboos:

… it doesn't make a difference (i.e. it works in both cases)

Well, except that returning None is not correct, as this leads to this traceback on the server:

Exception happened during processing of request from ('127.0.0.1', 55808)
Traceback (most recent call last):
  File "c:\Dev\Python273\lib\SocketServer.py", line 582, in process_request_thread
    self.finish_request(request, client_address)
  File "c:\Dev\Python273\lib\SocketServer.py", line 323, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "c:\Dev\Python273\lib\SocketServer.py", line 638, in __init__
    self.handle()
  File "c:\Dev\Python273\lib\BaseHTTPServer.py", line 340, in handle
    self.handle_one_request()
  File "c:\Trac\repos\1.0-stable\trac\web\wsgi.py", line 191, in handle_one_request
    gateway.run(self.server.application)
  File "c:\Trac\repos\1.0-stable\trac\web\wsgi.py", line 98, in run
    for chunk in response:
TypeError: 'NoneType' object is not iterable

But the client already got its answer at this time, so that's why I thought it worked…

It's true that WSGI is somewhat insisting that the content of the response should be returned as an iterable, rather than calling the write() callable returned by start_response():

Note: the write() callable is provided only to support certain existing frameworks' imperative output APIs; it should not be used by new applications or frameworks if it can be avoided — ​PEP:0333

We don't do that and we always return [] as the iterable. Maybe your web front-end doesn't support that (but then, why just for errors, as I imagine it works for the normal situation?).

[Christian Boos]

Closing, as this was going nowhere.