I am using CookieCrumbler as an authentication method on a Zope site. I am looking at the feasibility of putting multi CookieCrumbler objects (all with the same settings -- except for the cache setting) on a site in order to allow some parts of the site to be cached in an upstream proxy and forbidding others. Is this a reasonable thing to do? Will it achieve the result I am looking for?
On 11 Jan 2006, at 21:46, Brian Sullivan wrote:
I am using CookieCrumbler as an authentication method on a Zope site.
I am looking at the feasibility of putting multi CookieCrumbler objects (all with the same settings -- except for the cache setting) on a site in order to allow some parts of the site to be cached in an upstream proxy and forbidding others.
Is this a reasonable thing to do? Will it achieve the result I am looking for?
I will not do what you expect to do. The first cookie crumbler to do authentication sets the cookie and even if other cookie crumblers get involved they will not just overwrite that cookie because the lifetime setting on their cookie is different. jens
On 1/11/06, Jens Vagelpohl <jens@dataflake.org> wrote:
On 11 Jan 2006, at 21:46, Brian Sullivan wrote:
I am using CookieCrumbler as an authentication method on a Zope site.
I am looking at the feasibility of putting multi CookieCrumbler objects (all with the same settings -- except for the cache setting) on a site in order to allow some parts of the site to be cached in an upstream proxy and forbidding others.
Is this a reasonable thing to do? Will it achieve the result I am looking for?
I will not do what you expect to do. The first cookie crumbler to do authentication sets the cookie and even if other cookie crumblers get involved they will not just overwrite that cookie because the lifetime setting on their cookie is different.
In some testing I found that the headers (at least the upstream cache setting which is what I was interested in) does seem to be different depending on the first CookieCrumbler to handle the content (I set one in a subdirectory to cache setting 'public' and the main system level one to 'private')- which would seem to imply that higher placed ones recognize the cache header setting and avoid changing it? This seemed to do what I want. If this isn't a strategy for doing what I want to do can anybody thing of one? I have a site that is authenticated using CookieCrumbler. I have a whole bunch of static files/objects, some fairly large isolated in a subfolder on the site. I want the static objects to be cached by upstream proxies, but all other parts of the site not cacheable.
Brian Sullivan wrote:
On 1/11/06, Jens Vagelpohl <jens@dataflake.org> wrote:
On 11 Jan 2006, at 21:46, Brian Sullivan wrote:
I am using CookieCrumbler as an authentication method on a Zope site.
I am looking at the feasibility of putting multi CookieCrumbler objects (all with the same settings -- except for the cache setting) on a site in order to allow some parts of the site to be cached in an upstream proxy and forbidding others.
Is this a reasonable thing to do? Will it achieve the result I am looking for?
I will not do what you expect to do. The first cookie crumbler to do authentication sets the cookie and even if other cookie crumblers get involved they will not just overwrite that cookie because the lifetime setting on their cookie is different.
In some testing I found that the headers (at least the upstream cache setting which is what I was interested in) does seem to be different depending on the first CookieCrumbler to handle the content (I set one in a subdirectory to cache setting 'public' and the main system level one to 'private')- which would seem to imply that higher placed ones recognize the cache header setting and avoid changing it? This seemed to do what I want.
If this isn't a strategy for doing what I want to do can anybody thing of one? I have a site that is authenticated using CookieCrumbler. I have a whole bunch of static files/objects, some fairly large isolated in a subfolder on the site. I want the static objects to be cached by upstream proxies, but all other parts of the site not cacheable. ___
Brian, Can you explain how you are using this? Does cookie crumbler's cache-control apply to *all* authenticated responses? If so, I didnt realize it was so sweeping (I admit i had assumed it applied to the authentication cookie). Have you, for example, considerered branching to different folders (one with all object caches set to no-cache) based on a user role? Can you give more detail? David Good luck! David Its an interesting idea, to cascade cookie crumblers - you might be able to fake the login_screen
On 1/11/06, David Hassalevris <bluepaul@earthlink.net> wrote:
Can you explain how you are using this?
I am not sure what "this" you are referring to. If you mean controlling the cache control http response that is done by setting a property in the CookieCrumbler object.
Does cookie crumbler's cache-control apply to *all* authenticated responses? If so, I didnt realize it was so sweeping (I admit i had assumed it applied to the authentication cookie).
That is my understanding of how it works in all current versions.
Have you, for example, considerered branching to different folders (one with all object caches set to no-cache) based on a user role?
I am not sure what you mean.
Its an interesting idea, to cascade cookie crumblers - you might be able to fake the login_screen
My preliminary testing seems to indicate that this cascading does what I want -- unless there is some gotcha there. I suppose it is easy enough to test -- but I have to first get setup in the proxied environment with somebody that understands the particular proxy.
On 12 Jan 2006, at 00:39, Brian Sullivan wrote:
I will not do what you expect to do. The first cookie crumbler to do authentication sets the cookie and even if other cookie crumblers get involved they will not just overwrite that cookie because the lifetime setting on their cookie is different.
In some testing I found that the headers (at least the upstream cache setting which is what I was interested in) does seem to be different depending on the first CookieCrumbler to handle the content (I set one in a subdirectory to cache setting 'public' and the main system level one to 'private')- which would seem to imply that higher placed ones recognize the cache header setting and avoid changing it? This seemed to do what I want.
If this isn't a strategy for doing what I want to do can anybody thing of one? I have a site that is authenticated using CookieCrumbler. I have a whole bunch of static files/objects, some fairly large isolated in a subfolder on the site. I want the static objects to be cached by upstream proxies, but all other parts of the site not cacheable.
I don't know what you're talking about, the CookieCrumbler has *nothing* to do with caching at all. Are you confusing tools here? Could it be you're talking about the CachingPolicyManager? By the way, the CookieCrumbler doesn't "authenticate", either. It just makes cookie data look like regular basic auth headers so that a real user folder can use that data. jens
On 1/12/06, Jens Vagelpohl <jens@dataflake.org> wrote:
I don't know what you're talking about, the CookieCrumbler has *nothing* to do with caching at all. Are you confusing tools here? Could it be you're talking about the CachingPolicyManager?
AFAIK CookieCrumbler sets the http cache control header value of http responses that it handles. It has a property (at least in current versions) that lets you control what this header value is. My understanding is that the header is set to "private" by default.
By the way, the CookieCrumbler doesn't "authenticate", either. It just makes cookie data look like regular basic auth headers so that a real user folder can use that data.
Yes.
participants (3)
-
Brian Sullivan -
David Hassalevris -
Jens Vagelpohl