[MAGNOLIA-2894] Wrong content-encoding in HTTP header prevents "not authorized" pages from beeing displayed Created: 13/Oct/09  Updated: 23/May/13  Resolved: 23/May/13

Status: Closed
Project: Magnolia
Component/s: cache
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Andreas Antener Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: cache, encoding, security
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tested browsers: Firefox 3, IE 7


Attachments: JPEG File encoding problem.jpg    
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   

In some cases, where the currently logged-in user has no access to the requested site, the browser is not able to display the response (see attachement).

If the cache is completely disabled everything works as expected so we suspect that caching the forbidden pages causes the problem.

Also if ACLs get changed through the author instance, those cached pages don't get flushed (this is pretty confusing while testing security).



 Comments   
Comment by Magnolia International [ 15/Oct/09 ]

One simple approach would be to disable the cache "when logged in" (I believe there is a voter for that in the configuration)

Patch the cache so that it doesn't cache error pages (or make that configurable) is not the end of the story, since you still want to verify ACLs in all cases; since the contentSecurity filter is after the cache filter, that would mean you'd serve pages to users who can't see them.

Another approach is to have a custom CachePolicy; maybe one that has a cache zone per user, per group, per role, whatever is fit to your case.

edit: I don't see the connection with encoding ?

Comment by Magnolia International [ 15/Oct/09 ]

Oh wait, your actual problem is to do with the fact that error pages are sent with gzip encoding ?

"in some cases" - can you elaborate on that? What are the conditions ?

Comment by Andreas Antener [ 26/Oct/09 ]

Ok, the voter for not caching if authenticated is a workaround, but caching for logged in user should be possible imho.

You can still produce the error though. I tried to figure out the steps necessary:

  • setup magnoliaAuthor and magnoliaPublic instances (I used the enterprise version 4.1.1 with samples module and PUR module)
  • browse on the public instance and get the demo-project site cached
  • configure the "anonymous" role like the following: read acces for the whole website ("/") but deny "/demo-project/service", and url access for "get & post" to "/*"
  • activate the "anonymous" role
  • now I still see the "Service" menu item on demo-project. When I go there (and on the sub-sites) I get the described error
Comment by Andreas Antener [ 23/May/13 ]

Closing this issue since I believe it isn't relevant anymore.

Generated at Mon Feb 12 03:41:10 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.