Posted by Spechal on January 10, 2012 at 5:35pm
So we use page level caching on our Pressflow 6 multisite installation and some of the sites use a module for IP based role assignment.
There is an issue with using page caching and IP based role assignment in which a user will get a cached page from Varnish despite having an IP that will give them an authenticated role.
The current solution is to use a Varnish ACL and add the IP addresses to it and have Varnish pass when an IP is found. This causes duplication of IP addresses (in the ACL and Drupal DB), which is not ideal. When the Drupal DB is updated, the ACL needs updated, creating duplicate work.
Does anyone have any advice on determining a solution to this issue?
Comments
Can you create a menu
Can you create a menu callback that is not cached and instruct users to "log in" by visiting that?
knaddison blog | Morris Animal Foundation
Unfortunately not, the goal
Unfortunately not, the goal behind using IP based roles is to bypass standard authentication.
Use Varnish Restart function?
I would also either use one uncached path, which is automatically logging them in (user/* ?) or the only other possibility I could think of would be Varnish restarts.
Like:
Connect to Varnish
-> Check authentication server url
=> forward to login URL or do nothing
-> Restart request with proper URL
The problem here is that the authentication server is queried each time and if you don't want this, you need some cookie / SESSION support again ...
However clicking on a button somewhere to login (and POSTs are not cached) should not be that hard, so I think I would not go with restarts for this use case ...
Best Wishes,
Fabian
This is sort of the route I
This is sort of the route I was thinking, (setting a cookie and Varnish will pass when it finds it) but the user will get a cached page so it will never hit the back-end to get the cookie.
Not to
rain on anyone's parade. But I suggest that you switch to using Nginx cache. If I understand correctly this issue could easily be solved using standard Nginx directives. E.g.,
geo $no_cache {
default 0;
127.0.0.1 1;
192.168.60.0/24 1;
}
map $remote_addr $no_cache {
default 0;
::1 1; # can specify IPv6 addresses here geo doesn't support it
}
map $http_cookie $no_cache {
default 0;
~SESS 1;
}
This will burst the cache if the user comes from a given set of IPs (6 and/or 4) or if he has a session cookie issued.
Then just use the standard cache bursting directives.
Just an idea.
I've been looking to use
I've been looking to use nginx, but this is not currently an option. Thanks for your suggestion.
What about only maintaining
What about only maintaining the IP list in Varnish. Then have Varnish set add a special HTTP header to designate the IP-based role before the HTTP request is sent to Drupal. Then in Drupal write some custom code to look for that HTTP header.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
That might be a possibility,
That might be a possibility, but the goal is to get the ACL out of Varnish and keep everything in Drupal. To keep the operations and development parts separated.
An HTTP header would be
An HTTP header would be better because you can keep it entirely hidden from the user. The logic would be something like:
Then in the section that decides to pass or not:
- If a whitelist cookie exists (SESS*, etc.)
- or the custom HTTP header is set
then pass the request to the backend
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
Concept
You could maybe reuse the general concept behind http://blog.neovatar.org/index.php?/archives/34-Caching-authenticated-do...
Basically you set a drupal service to identify if an IP is allowed and tell varnish act accordantly
Hope this help ;)