backtrace in attachment description

[Christian Boos]

Seen this backtrace in the logs:

[pid  1122634064] 2010-03-22 10:02:24,962 Trac[main] ERROR: Internal Server Error:
Traceback (most recent call last):
  File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 504, in _dispatch_request
    dispatcher.dispatch(req)
  File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 235, in dispatch
    resp = chosen_handler.process_request(req)
  File "build/bdist.linux-x86_64/egg/trac/attachment.py", line 371, in process_request
    parent_name = get_resource_name(self.env, parent)
  File "build/bdist.linux-x86_64/egg/trac/resource.py", line 332, in get_resource_name
    return get_resource_description(env, resource)
  File "build/bdist.linux-x86_64/egg/trac/resource.py", line 329, in get_resource_description
    return manager.get_resource_description(resource, format, **kwargs)
  File "build/bdist.linux-x86_64/egg/trac/attachment.py", line 527, in get_resource_description
    parent=get_resource_name(self.env, resource.parent))
  File "build/bdist.linux-x86_64/egg/trac/resource.py", line 332, in get_resource_name
    return get_resource_description(env, resource)
  File "build/bdist.linux-x86_64/egg/trac/resource.py", line 322, in get_resource_description
    manager = ResourceSystem(env).get_resource_manager(resource.realm)
AttributeError: 'NoneType' object has no attribute 'realm'

This was for the following request:

66.249.65.117 trac.edgewall.org - [22/Mar/2010:10:02:25 +0100] "GET /attachment/attachment/ticket/6109/?action=new HTTP/1.1" 500 9389 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

[Remy Blank]

This looks like a crawler indexed t.e.o in the small time windows where the t.e.o-specific hack wasn't applied (duplicated /attachment).

[Christian Boos]

Right, but nevertheless we shouldn't get a traceback on such links (attachment/attachment/ticket/6109/).

[Remy Blank]

I'm not sure about that. I have always assumed that we should avoid showing tracebacks for any URLs that are generated by Trac (i.e. by clicking and entering something in a form), but take a more relaxed stance if the user manipulates the URL. The /attachment/attachment/* URL is never generated by Trac (except due to user error), so I don't see that as an issue.

Now, my assumption may be wrong, of course. But then, what about the following:

• ​http://trac.edgewall.org/wiki/WikiStart?version=bug
• ​http://trac.edgewall.org/log/trunk?limit=bug (that one actually can be reached by just clicking and entering data in a form, so we should probably fix that)

So my question is: should we avoid tracebacks in all situations, even with URL manipulation?

[Christian Boos]

Replying to rblank:

So my question is: should we avoid tracebacks in all situations, even with URL manipulation?

Right, it's probably not possible to care about every possible misuse of the application.

I'd like to fix that specific issue though, but it's not high priority. The next time I do something in this area of the code ;-)