Attachments from bug reports don't open when there is an empty space in url
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
Critical
|
Robert Collins |
Bug Description
Bug #824470
Screenshot from comment #1
error ID OOPS-2050AX76
Bug #825046
Screenshot from comment #1
error ID OOPS-2050EDGEA60
Bug #825004
Screenshot from comment #1
error ID OOPS-2050EDGEE63
Bug #824916
Screenshot from comment #1
error ID OOPS-2050EDGEB79
Traceback (most recent call last):
Module zope.publisher.
publication
Module canonical.
raise NotFound(
NotFound: Object: <canonical.
Exceptions from title: the url from screenshots there don't contain empty space.
Bug #825313
Screenshot from comment #1
error ID OOPS-2050EDGEA81
Bug #825296
Click on linked bug report in comment #5
error ID OOPS-2050EDGEB89
- - - - - Below are ok.
Bug #819029
Screenshot from comment #4 is ok.
Bug #824953
Screenshot from comment #1 is ok.
description: | updated |
description: | updated |
Changed in launchpad: | |
status: | New → Triaged |
importance: | Undecided → High |
description: | updated |
summary: |
- Screenshots from bug reports don't open when there is an empty space in + Attachments from bug reports don't open when there is an empty space in url |
tags: | added: critical-analysis |
This is a regression: we recently changed our url processing to only accept urls we would generate, and we forgot that we use untrusted data (filenames) in urls sent to the main appserver (because the appserver needs to check authentication cookies before deciding whether to redirect to the private librarian, for the case of private bugs). This change was made to avoid a set of systematic bugs and glitches in url routing.
one way to address this would be to change our implementation of that change, another would be to make the urls we generate, even for attachments with unicode elements or whitespace, match our more restrictive rules (e.g. by folding the name down).