Hi,
I have a rather special problem. We have an installer that relies on a wget to a protected page on my Drupal site for authentication. The wget goes something like this:
wget -q --post-data 'name=$username&pass=$password&form_id=user_login_block' http://mysite.company.com/dl/installers -O - > /dev/null
So the wget supplies a username and password. If the user with that name and password is able to reach the /dl/installers page, then a 200 OK is returned, and the user is authenticated. Otherwise a 403 forbidden is returned, and the user is denied access to install the program. To be successful, the username/pw must belong to a user with the role "partner" (or above).
Now this worked nicely until I installed Authcache (with File Cache). Even when I specify that pages should not be cached for users with role=Partner (and then flush everything imaginable), it does not work.
Disabling Authcache and running with File Cache alone, it does work.
I know that this is a specialized situation, but could it be a hint that something isn't working right?
I must admit I can't really see through it all at that level. I just know that I'd like to have Authcache running again..!

Comments

znerol’s picture

Authcache should not store / serve cached pages when there is POST data present on the request. This check for POST-data is implemented at two locations:

In authcache.inc, line 63. Here we ensure that there is no POST data on the request before attempting to return a cached version of the page:

62         // Attempt to retrieve page from cache
63         if (empty($_POST)) {

In authcache.helpers.inc, line 34. At this spot it is decided whether the result of the current page request can be stored in the cache:

  34   if (!empty($_POST)) {
  35     $_authcache_info['no_cache_reason'] = 'POST request';
  36     return FALSE;
  37   }

Those two spot is where you should place your breakpoints to debug the problem.

If you are not into analyzing this problem, you also may try to just exclude the installer-path by adding it to a page caching rule in admin/config/development/performance/authcache/pagecaching.

DeNelo’s picture

Thank you, I will look into that!

DeNelo’s picture

Hmm, I'm sorry to say that excluding the installer page did not help. I re-enabled Authcache, added the installer page as an exception (even adding the real path (node/xx) for good measure), saved and cleared, cleared every cache, and ran the wget command. It came out with a 403 every time.
The page does not have to be served from the cache; I'm only testing for access to the page. And somehow Authcache doesn't let me.

znerol’s picture

Please run wget with the -S flag such that response headers are written to stderr. Then examine the output for the header "X-Drupal-Cache" header. When the page was properly excluded from the cache that header should be missing.

simg’s picture

Status: Active » Postponed (maintainer needs more info)
DeNelo’s picture

Sorry for being so long.
With Authcache disabled, the header says, "X-Drupal-Cache: MISS"
Authcache enabled: There is no X-Drupal-Cache, but I get the ERROR 403: Forbidden. Slightly edited output below:

 HTTP/1.1 302 Found
  Date: Tue, 27 Aug 2013 08:01:32 GMT
  Server: Apache/2.2.3 (CentOS)
  X-Powered-By: PHP/5.3.3
  Expires: Sun, 19 Nov 1978 05:00:00 GMT
  Last-Modified: Tue, 27 Aug 2013 08:01:32 +0000
  Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
  ETag: "1377590492"
  Content-Language: en
  Set-Cookie: SESS2eccfddd8845eabd833b109a91903e3b=Rb06zzTtwTaa3PCdKuf-RexMVfbgqiVCUOHsVZ4gT2Y; expires=Thu, 19-Sep-2013 11:34:54 GMT; path=/; domain=.resources.company.com; HttpOnly
  Set-Cookie: nocache=1; expires=Thu, 19-Sep-2013 11:34:52 GMT; path=/; domain=.resources.company.com
  Set-Cookie: drupal_user=ANN1; expires=Thu, 19-Sep-2013 11:34:52 GMT; path=/; domain=.resources.company.com
  Set-Cookie: drupal_uid=98; expires=Thu, 19-Sep-2013 11:34:52 GMT; path=/; domain=.resources.company.com
  Location: http://resources.company.com/dl/installers
  Connection: close
  Content-Type: text/html; charset=utf-8
Location: http://resources.company.com/dl/installers [following]
--2013-08-27 10:01:34--  http://resources.company.com/dl/installers
Connecting to resources.company.com|172.16.13.34|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.0 403 Forbidden
  Date: Tue, 27 Aug 2013 08:01:34 GMT
  Server: Apache/2.2.3 (CentOS)
  X-Powered-By: PHP/5.3.3
  Expires: Sun, 19 Nov 1978 05:00:00 GMT
  Last-Modified: Tue, 27 Aug 2013 08:01:34 +0000
  Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
  ETag: "1377590494"
  Content-Language: en
  Link: </node/272>; rel="shortlink",</access-denied>; rel="canonical"
  X-Generator: Drupal 7 (http://drupal.org)
  Connection: close
  Content-Type: text/html; charset=utf-8
2013-08-27 10:01:35 ERROR 403: Forbidden.

Stumped, I am.

DeNelo’s picture

I've now disabled caching entirely for those roles that should have access to downloading the installers. That seemed to do the trick. Strange, because I tried that before.
The trouble is of course that roughly half our users have one of those roles...

znerol’s picture

Ok, the log you posted clearly indicates that authcache does not attempt to serve a previously cached "access denied" page.

In order to proceed I would like to know some more details about dl/installers. Is this page implemented using a custom module or do you use some contrib project in order to restrict access to that page?

DeNelo’s picture

Access to the dl/installers page is restriced to users having certain roles, using the Content Access module.
"Per content node access control" is enabled for the content type in question (called "download"), but no additional users have been given access to the dl/installers page.

znerol’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Closed (outdated)