If a anonymous user is viewing the node content (after passing the password site) the node will get cached and so be available for other anonymous users which don't have to pass the password page if caching is enabled.

All pages are cached for anonymous, so the code part for password protection (protected_node_nodeapi) will not be called until the cache is not more valid.

Comments

emdalton’s picture

emdalton commented

This is a pretty major hole. The whole reason we want to use this module is for anonymous users -- we already have appropriate security on nodes and pages for our registered users. Any chance of a fix?

emdalton’s picture

emdalton commented
Priority: Normal » Critical

Changing priority to "critical."

osopolar’s picture

osopolar
Primary language German
Location 🇩🇪 GER 🌐
commented

The whole problem is because of caching - so the easiest way is to switch it of at all.
If not you want to modify the module i.e. switch caching off only for protected node-type/content try to use hook_exit (not working in aggressive caching mode) and cache_clear_all. If the page is not cached we don't have this problem ... but we still have the problems with the cron and (re-) index search (http://drupal.org/node/231938) and search at all (http://drupal.org/node/233829).
I don't know how to fix these Problems. One idea is not to use the goto for showing the form. Instead we are directly putting out the form by overwriting the node content in hook_nodeapi in the view case. (The problem is that the form gets cached if cache will not get disabled).
I don't like so much the ideas above. Therefore I was looking for another solution. Now I use the url_access module: http://drupal.org/project/url_access ... in the end you have a unique URL (hard to guess) what is almost the same like a password (at least in my case). Try this patch for more customizing: http://drupal.org/node/235726.

links:
http://api.drupal.org/api/function/hook_exit/5
http://www.lullabot.com/articles/a_beginners_guide_to_caching_data
http://api.drupal.org/api/function/cache_clear_all/5
http://api.drupal.org/api/function/hook_nodeapi/5

emdalton’s picture

emdalton commented

I can't turn off caching for performance reasons, and I need to keep the protected pages from being indexed by search engines, so url_access isn't going to solve my problem, either.

Turning off caching selectively for protected nodes needs to be part of this module. The module doesn't work correctly without it.

emdalton’s picture

emdalton commented

I've never tried to implement a hook function. Would it look something like this?

/**
 * Implementation of hook_exit()
 */
function protected_node_exit($destination) {
  db_query('UPDATE {counter} SET hits = hits + 1 WHERE type = 1');
  cache_clear_all();
}

Do we want to specify the table of the cache_clear_all statement?

osopolar’s picture

osopolar
Primary language German
Location 🇩🇪 GER 🌐
commented

have a look on this: http://drupal.org/project/cache_disable

if you just do cache_clear_all you can switch it of ... because this function will be called every time ... that's why the are saying don't use it if there is not not a real need.

http://api.drupal.org/api/function/hook_exit/5

mtolmacs’s picture

mtolmacs commented
Assigned: Unassigned » mtolmacs

Basically this can't be solved with effective caching. Drupal completely ignores every and all node handling hook while loading the cached page.
Either we delete all cached pages every time an anonymous visits a protected node (defeats the whole caching thing) or don't use caching. Currently I'm working on a hack to circumvent this.

emdalton’s picture

emdalton commented

I think what we need to be able to do is turn off caching just for protected pages. Can that be done?

mtolmacs’s picture

mtolmacs commented

AFAIK the answer is no. Caching does not have any hooks or configuration possibility. If you switch it in, then every and all page load which was requested by an anonymous user will be directed to output buffer and at the end of page generation gzipped and pushed down to cache_page table.

I also can't delete the cache table selectively, because I cannot identify pages which contain protected node content. Catch 22.

Still, I think about the problem when I have some spare time, but currently I don't see any method to fix this in the distribution.

One thing tough the modification of the Drupal core on your site but I usually dislike this option.

Edit: The only possibility I see right now is PHP PECL extension named Runkit. With runkit I can redefine the Drupal core function which actually does the caching without modifying the core. But requiring non-default install extensions isn't the best way to win the heart of the users...

mtolmacs’s picture

mtolmacs commented
Status: Active » Fixed

This bug cannot be fixed the way the submitter reported. Caching must be disabled completely if the anonymous users must access a protected content. The 5.x-1.1 release checks whether caching is enabled and does not allow anonymous users to access to the protected contents if it is enabled. Instead redirects them to login.

mtolmacs’s picture

mtolmacs commented

I'm glad to report that I just found out $GLOBALS['conf']['cache'] which controls the caching of the currently generated page. I've done some preliminary tests and it seems to fix the problem perfectly.

5.x-1.2 will contain the fix.

emdalton’s picture

emdalton commented

Excellent! I look forward to testing the fix.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.