I have a problem in Boost module I have a dynamic site that Allow user to logged in to edit his content

after log into the site the login links disappear and another links loaded that contain user links (Check code below for a custom block)

but after installing boost the menu of login still appear after registration (still read the caching page)

is there any option that make pages to anonymous user only

This is my code

function login_block_info() {
    $blocks = array();
    $blocks['mylogin'] = array(
        'info' => t('Custom Login'),
    return $blocks;
function login_block_view($block_name = '') {
    if ($block_name == 'mylogin') 
        $output ="";
            global $user;
            $query = "select nid from node where uid = " . $user->uid;
            $result =db_query($query);
            $nodes = array();
            $output ='<ul class="register-menu">';
                foreach ($result as $node) {
                    $alias = drupal_get_path_alias('node/'.$node->nid);
                    $output .= '<li>'.l($node->title,'node/'.$node->nid.'/edit').'</li>';
            $output .= '<li>'.l(t('Change password'),'user/'.$user->uid.'/edit').'</li>';
            $output .= '<li>'.l(t('log out'),'user/logout').'</li>';
            $output .= "</ul>";
            $output .='<ul class="register-menu">
                         <li><a onclick="open_login()">log in</a></li>
                         <li><a onclick="open_register()">sign up</a></li>
            $output .= render(drupal_get_form('user_register_form'));
            $output .= '</div>';
        return array(
            'subject' => t(''),
            'content' => $output,


#8 boost-1616356.patch1.06 KBbgm
Members fund testing for the Drupal project. Drupal Association Learn more


bgm’s picture

Category: bug » support


When logged in, if you do "View source" on the HTML, do you see the boost signature at the bottom of the page? (generated by boost, ...)

Can you double-check your htaccess configs? The rewrite rules check for the DRUPAL_UID cookie. If you remove that, then logged in users will hit the cache.

ahm_hefni’s picture

Thanks a lot for you reply
I checked .htaccess and I found DRUPAL_UID cookie
and this is scenario happens to me
after user logged in I redirect him to home page (and it display the original page not the cached)
then after navigation to the site it display the cached page until user goes to a page that not cached at all after that All page appear as un-chaced
and this is my .htaccess

# RewriteBase /

   ### BOOST START ###

  # Allow for alt paths to be set via htaccess rules; allows for cached variants (future mobile support)
  RewriteRule .* - [E=boostpath:normal]

  # Caching for anonymous users
  # Skip boost IF not get request OR uri has wrong dir OR cookie is set OR request came from this server OR https request
  RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$ [OR]
  RewriteCond %{REQUEST_URI} (^/(admin|cache|misc|modules|sites|system|openid|themes|node/add|comment/reply))|(/(edit|user|user/(login|password|register))$) [OR]
  RewriteCond %{HTTPS} on [OR]
  RewriteCond %{ENV:REDIRECT_STATUS} 200
  RewriteRule .* - [S=5]

  # GZIP
  RewriteCond %{HTTP:Accept-encoding} !gzip
  RewriteRule .* - [S=2]
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html,E=no-gzip:1]
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.json -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.json [L,T=text/javascript,E=no-gzip:1]

  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html]
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.json -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.json [L,T=text/javascript]

  ### BOOST END ###

  # Pass all requests not referring directly to files in the filesystem to
  # index.php. Clean URLs are handled in drupal_environment_initialize().
bgm’s picture

It might be hitting the browser's cache. Do all browsers give the same result?

You can try debugging with the network console (Firebug->Network, or Chrome->Inspect->Network).

ahm_hefni’s picture

I check IE and chrome and firefox they give me same problem
I checked network with chrome it download the page not from cached
and this is the result of debuging
companies GET 200 OK text/html Other 31.03KB 30.63KB 1.31s 236ms

I am using Drupal 7.8 and the latest beta version of boost

_paul_meta’s picture

I am noticing this same behaviour. Boost cached pages are displayed after logging in, making it look like login didn't work. But a hard refresh in the browser loads the correct logged in page.

Any ideas why this is happening ?

Thanks !

drupso’s picture

I can reproduce this problem.
I have a login and register custom block in my front page. When user logins in site, he is redirecting to other page (not front page). If this user returns to front page, this block appears cause front page is cached (in view inspector bottom region appears boost cached message).
Anybody could get how to avoid this?

jchin1968’s picture

I'm having the same problem and I believe the issue is with the boost cookie DRUPAL_UID not being set correctly at login.

The problem lies in the function boost_cookie_handler() and with the fix for Issue #1242416 (http://drupal.org/node/1242416).

Note: the line numbers referenced below is for version 7.x-1.0-beta1 and the problem still exists in the latest dev release on June 5, 2012.

When an anonymous user submits their login detail, boost_cookie_handler() is called and line 616, boost_set_cache(-1), is executed which sets DRUPAL_UID=-1.

On redirection to the user's profile page, ie. /user/{uid}), boost_cookie_handler() gets called again. This time, since DRUPAL_UID=-1, line 603, boost_set_cookie($uid, REQUEST_TIME - 86400); gets executed and the cookie DRUPAL_UID expires immediately. No more DRUPAL_UID!

Now, when an authenticated user browses to a boost cached page (ie. ), the Boost mod_rewrite rules kicks in, sees there is no DRUPAL_UID and fetches the cached page and bypasses Drupal completely. So, hook boost_init() never gets executed nor does boost_cookie_handler() and DRUPAL_UID never gets created.

DRUPAL_UID eventually gets created when the user navigates to a non-cached page and boost_init() and boost_cookie_handler() gets called again.

I have a quick work-around to this problem but it's a bit of a hack. Perhaps some Boost expert can guide us to a more elegant solution. My fix is to invoke hook_user_login in a custom module and set the cookie DRUPAL_UID at login.

function custommodule_user_login(&$edit, $account) {
  global $user;  

This works because hook_user_login() is called after DRUPAL_UID is set to -1.

bgm’s picture

Status: Active » Needs review
1.06 KB

Thanks jchin1968 for the excellent debugging.

The source of the bug is in boost_cookie_handler() : the order of the conditions needed to be changed, and had to add a tiny check before setting boost_set_cookie($uid) for logged in users.

Can you test?

Edith Illyés’s picture

#8 works well for me. Thanks.

bgm’s picture

Category: support » bug
Status: Needs review » Fixed

Committed to 7.x-1.x e3e94aca8bb3c688c4c06d2fa4930a5c3d5ae70a

Status: Fixed » Closed (fixed)

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

jvieille’s picture

Version: 7.x-1.0-beta1 » 6.x-1.21
Status: Closed (fixed) » Active

I have this problem, but with D6.
It always needs 2 attempts to log in
I tried to apply the patch in #8 to the corresponding code in boost_init line 468+, but it did not help.

Thanks for help

Philip_Clarke’s picture

Did you check that you are getting a boost page ? as in when you view source is there a boost comment the first time you see the page (before the second log in attempt ? BTW that patch was for 7.x I would revert back to the version of 6 you are using if you applied the patch automatically.

jvieille’s picture

Thanks for taking care.
No patch is applied at all at the moment.

The first time I try to log in, I get this warning (The last line in French is about the failed login)

Form session reuse detected. An old form was submitted again, which may happen if it was retrieved from browser history using "Back" button.
Please try again - fill all entries on this page without going "Back".
Désolé, nom d'utilisateur ou mot de passe non reconnu. Avez-vous oublié votre mot de passe ?

I don't see anything related to boost in the html source apart (hidden) Boost block related elements

Login works normally when Boost is disabled.

Thanks again

Philip_Clarke’s picture

It does sound very much like a caching problem where the form should not have been cached and so contains a unique identifier that is stale. What's in you htaccess file and what is the url of the log in page (user example.com to replace your domain name). The rewrite rules should not cache the page because of this kind of issue. (I read french if it helps).

jvieille’s picture

The login url is in the same domain than the base domain, no redirect involved, if it is what you mean.

The login issue appears in all situations, when login from a specific node / page using the login bloc.
It however succeed through the user/login page.

Content of the .htaccess - I kept the old commented stuff.

# Apache/PHP/Drupal settings:

# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl|svn-base)$|^(code-style\.pl|Entries.*|Repository|Root|Tag|Template|all-wcprops|entries|format)$">
  Order allow,deny

# Don't show directory listings for URLs which map to a directory.
Options -Indexes

# Follow symbolic links in this directory.
Options +FollowSymLinks

# Make Drupal handle any 404 errors.
ErrorDocument 404 /index.php

# Force simple error message for requests for non-existent favicon.ico.
<Files favicon.ico>
  # There is no end quote below, for compatibility with Apache 1.3.
  ErrorDocument 404 "The requested file favicon.ico was not found.

# Set the default handler.
DirectoryIndex index.php

# Override PHP settings. More in sites/default/settings.php
# but the following cannot be changed at runtime.

# PHP 4, Apache 1.
<IfModule mod_php4.c>
  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass

# PHP 4, Apache 2.
<IfModule sapi_apache2.c>
  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass

# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass

# Requires mod_expires to be enabled.
<IfModule mod_expires.c>
  # Enable expirations.
  ExpiresActive On

  # Cache all files for 2 weeks after access (A).
  ExpiresDefault A1209600

  <FilesMatch \.php$>
    # Do not allow PHP scripts to be cached unless they explicitly send cache
    # headers themselves. Otherwise all scripts would have to overwrite the
    # headers set by mod_expires if they want another caching behavior. This may
    # fail if an error occurs early in the bootstrap process, and it may cause
    # problems if a non-Drupal PHP file is installed in a subdirectory.
    ExpiresActive Off

# AddOutputFilterByType DEFLATE text/html text/plain text/xml
AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript

# solve feed issue "Your feed appears to be encoded as "UTF-8", but your server is reporting "US-ASCII"
AddCharset UTF-8 .php

# Various rewrite rules.
<IfModule mod_rewrite.c>
  RewriteEngine on

  # If your site can be accessed both with and without the 'www.' prefix, you
  # can use one of the following settings to redirect users to your preferred
  # URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
  # To redirect all users to access the site WITH the 'www.' prefix,
  # (http://example.com/... will be redirected to http://www.example.com/...)
  # adapt and uncomment the following:
  # RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
  # RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]
  # To redirect all users to access the site WITHOUT the 'www.' prefix,
  # (http://www.example.com/... will be redirected to http://example.com/...)
  # uncomment and adapt the following:
  # RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
  # RewriteRule ^(.*)$ http://example.com/$1 [L,R=301]

  # Modify the RewriteBase if you are using Drupal in a subdirectory or in a
  # VirtualDocumentRoot and the rewrite rules are not working properly.
  # For example if your site is at http://example.com/drupal uncomment and
  # modify the following line:
  # RewriteBase /drupal
  # If your site is running in a VirtualDocumentRoot at http://example.com/,
  # uncomment the following line:
   RewriteBase /

  ### BOOST START ###

  # NORMAL - Cached css & js files
  RewriteCond %{DOCUMENT_ROOT}/cache/perm/%{HTTP_HOST}%{REQUEST_URI}_\.css -s
  RewriteRule .* cache/perm/%{HTTP_HOST}%{REQUEST_URI}_\.css [L,QSA,T=text/css]
  RewriteCond %{DOCUMENT_ROOT}/cache/perm/%{HTTP_HOST}%{REQUEST_URI}_\.js -s
  RewriteRule .* cache/perm/%{HTTP_HOST}%{REQUEST_URI}_\.js [L,QSA,T=text/javascript]

  # Caching for anonymous users
  # Skip boost IF not get request OR uri has wrong dir OR cookie is set OR request came from this server OR https request
  RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$ [OR]
  RewriteCond %{REQUEST_URI} (^/(admin|cache|misc|modules|sites|system|openid|themes|node/add|comment/reply))|(/(edit|user|user/(login|password|register))$) [OR]
  RewriteCond %{HTTPS} on [OR]
  RewriteRule .* - [S=3]

  RewriteCond %{DOCUMENT_ROOT}/cache/normal/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
  RewriteRule .* cache/normal/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html]
  RewriteCond %{DOCUMENT_ROOT}/cache/normal/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.xml -s
  RewriteRule .* cache/normal/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.xml [L,T=text/xml]
  RewriteCond %{DOCUMENT_ROOT}/cache/normal/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.json -s
  RewriteRule .* cache/normal/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.json [L,T=text/javascript]

  ### BOOST END ###

  # Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_URI} !=/favicon.ico
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

#  RewriteCond %{HTTP_HOST} ^see\.shareontheweb\.com$ [NC]
#  RewriteRule ^(.*)$ http://www.see.asso.fr/$1 [L,R=301]

# RewriteCond %{HTTP_HOST} ^see\.asso\.fr$ [NC]
# RewriteRule ^(.*)$ http://www.see.asso.fr/$1 [L,R=301]

# RewriteCond %{HTTP_HOST} ^www\.see\.asso\.fr$ [NC]
# RewriteRule ^(.*)$ http://web2.see.asso.fr/$1 [L,R=301]

# RewriteCond %{HTTPS} on
# RewriteCond %{HTTP_HOST} ^web2\.see\.asso\.fr$ [NC]
# RewriteRule ^(.*)$ http://web2.see.asso.fr/$1 [R=301,L]

RewriteRule ^sites\/see.shareontheweb.com\/files\/(webform\/distinctions\/brillouin2012\/.*)$ index.php?q=system/files/$1 [L,QSA]

Great for French, but better to keep English for the Good of the Community :)

Philip_Clarke’s picture

I think I understand exactly what is happening, anti-session hijacking CSRF data is included in the form that is on the cached page and it is stale, honestly I have no idea what to do in that except not to have the log in box and to have a link to the log in page (which I think is what this site does too). We may have to wait for NGM to turn up (the original author), but I'm pretty sure he'll say the same thing, that there's no way around it.

jvieille’s picture

In short, Boost does not allow a login block to operate normally?

The problem with the login page is that it does not get the user at the place I want.
For example, I am using a particular page with available files to download sing a guest login.
The authorized people receive a link to that page and a login.
This page is not access protected, but what the visitor sees depends on his permissions (An OG group)
If they have to go to the login page, they will have to manually go to this page after - a cumbersome process.

Would it work with other login niceties (Ajax or else?) that can log in while at a given page?

Philip_Clarke’s picture

In short, Boost does not allow a login block to operate normally?

if the block contains a CSRF token then it would not work unless the database kept avery long track of tokens and allowed multiple users access using the same token which rather defeats the point.

Would it work with other login niceties (Ajax or else?) that can log in while at a given page?

It really does depend on the structure of the code and the CSRF protection.

For CSRF protection to work, a session cookie must be active (or some other form of tracking) and in that case then DRUPAL_UID should have been set, so your diagnosis is correct, that boost is probably presenting cached pages when it should not, but if every page has a log in block, then boost should not work at all unless CSRF protection is disabled.

jvieille’s picture

Status: Active » Closed (fixed)

I don't know how to control the CSF protection,...

I tried to login another way, using http://drupal.org/project/modalframe_contrib "User register".
That solved the problem apparently : the login is entered in the modal frame from a block set to appear on every page. The connexion proceeds normally, without leaving the original page.

Thanks for the precious and timely help.

Hope this will help others too.

Philip_Clarke’s picture

Assigned: Unassigned » Philip_Clarke
Priority: Major » Normal
Status: Closed (fixed) » Needs review

I'm just rescheduling this as it's worth looking at that module (thanks) and seeing how it works, if it's a log in frame inside a block then it would get around the issue described above and certainly would be worth adding the the "related modules" tab that I put together in 7.x-dev

bgm’s picture

Status: Needs review » Needs work

"needs review" is for patches that need review :)

Philip_Clarke’s picture

Status: Needs work » Needs review

And I'll whack the status back to needs review for the "solutions" require documentation changes and I don't have the privileges "hint hint" ;-). This is an "instruction" issue as a quick fix related module doesn't exist for 7.x that I can find that is bolt-on without extensive re-theming.

The issue:

  • Some people want to use the menu block user login
  • The menu block has a anti CSRF hidden field form_build_id
  • This field is cached so users have to double log in as it expires after either the first person uses the form from a cached page, or it may expire on cron
  • An ajax module for log in is available but it is very blocky in design being made only as a framework for theming later


A new module generating iframe based block with nocache set so that the CSRF tag is always generated correctly.
Advising disabling the user login menu and having links to the login/ register pages (documentation needs changing)
Install an ajax module like http://drupal.org/project/ajax_register and modify it to the theme (am open to appending it to "related modules")


Search does not appear to have this issue with checking the CSRF tag, it appears to ignore it, so this may crop up again.

Philip_Clarke’s picture

Issue summary: View changes

Edit Code