[MAGNOLIA-529] Filenames with special characters produce 403 Created: 23/Aug/05 Updated: 24/Sep/05 Resolved: 24/Sep/05 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | core |
| Affects Version/s: | 2.1 Final |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Michael Aemisegger | Assignee: | Boris Kraft |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | 0.75d | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | 0.75d | ||
| Environment: |
all |
||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
Example: If the filename specified in the samples download paragraph contains special characters (e.g. german umlaute), then magnolia returns a 403 http status code. Even if the requested filename is URL encoded. In AccessManagerImpl.getPermissions(String) the requested URL is matched against the ACL. The internal ACL patterns do not support special characters, hence a AccessDeniedException is thrown. A temporary solution would be to change the ACL patterns in SimpleUrlPattern to ".*", since the dialog values do not get validated anyway. |
| Comments |
| Comment by Fabrizio Giustina [ 24/Sep/05 ] |
|
duplicate of |
| Comment by Michael Aemisegger [ 24/Sep/05 ] |
|
A task is always a duplicate of itself. But that's no reason to close it. Did you want to refer to another task? I remember having mistakenly filed this bug to bpn. |
| Comment by Fabrizio Giustina [ 24/Sep/05 ] |
|
right |