Happy New Year Everyone!
As nobody objected until today, I will go on and do the fix on the
@@ -29,6 +29,11 @@
# Set the error status to 403 (Forbidden) in the case when we don't
# challenge the user
+ self.request.response.setHeader('Expires', 'Mon, 26 Jul 1997 05:00:00
+ self.request.response.setHeader('Cache-Control', 'no-store, no-cache,
+ self.request.response.setHeader('Pragma', 'no-cache')
principal = self.request.principal
auth = zapi.principals()
and backport it also to 3.3 and 3.2
Wednesday, December 20, 2006, 3:05:10 PM, you wrote:
> On Wed, Dec 20, 2006 at 02:36:59PM +0100, Adam Groszer wrote:
>> Just happened the following:
>> squid proxy
>> / \
>> / \
>> / \
>> userA userB
>> Both my users are sitting behind a squid proxy/firewall.
>> That is a usual out-of-the-box SuSe linux firewall/proxy config.
>> Each request goes through the squid proxy.
>> userA does NOT have permission to http://zope3/ap_test/folder1.
>> userB has permission to everything, including http://zope3/ap_test/folder1,
>> he might even be a zope.manager.
>> 1. userA accesses http://zope3/ap_test/folder1
>> 2. userA gets the usual "Unauthorized, You are not authorized" message
>> 3. userB accesses http://zope3/ap_test/folder1
>> 4. BANG!, userB gets also the "Unauthorized, You are not authorized" message
>> Investigating further, the request at 3. does not get to the zope3
>> server. It got served by squid.
>> Adding the "no-store, no-cache, must-revalidate" etc. headers to the
>> Unauthorized page solves the problem.
>> Any opinions about that? Is it my mistake, a squid bug, a Z3 bug?
> Er, more like a squid feature, see negative_ttl. Not sure what the best
> way is to get around this though, "no-cache" is probably reasonable.
Adam mailto:[EMAIL PROTECTED]
Quote of the day:
Avoid reality at all costs.
Zope3-dev mailing list