Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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 ="";
if(user_is_logged_in())
{
global $user;
$query = "select nid from node where uid = " . $user->uid;
$result =db_query($query);
$nodes = array();
$output ='<ul class="register-menu">';
if(count($result)>0)
{
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>";
}
else
{
$output .='<ul class="register-menu">
<li><a onclick="open_login()">log in</a></li>
<li><a onclick="open_register()">sign up</a></li>
</ul>';
$output .= render(drupal_get_form('user_register_form'));
$output .= '</div>';
}
return array(
'subject' => t(''),
'content' => $output,
);
}
}
thanks
Comment | File | Size | Author |
---|---|---|---|
#8 | boost-1616356.patch | 1.06 KB | bgm |
Comments
Comment #1
bgm CreditAttribution: bgm commentedHi,
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.
Comment #2
ahm_hefni CreditAttribution: ahm_hefni commentedThanks 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
Comment #3
bgm CreditAttribution: bgm commentedIt 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).
Comment #4
ahm_hefni CreditAttribution: ahm_hefni commentedI 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
Comment #5
_paul_meta CreditAttribution: _paul_meta commentedI 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 !
Comment #6
drupso CreditAttribution: drupso commentedI 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?
Comment #7
jchin1968 CreditAttribution: jchin1968 commentedI'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.
This works because hook_user_login() is called after DRUPAL_UID is set to -1.
Comment #8
bgm CreditAttribution: bgm commentedThanks 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?
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commented#8 works well for me. Thanks.
Comment #10
bgm CreditAttribution: bgm commentedCommitted to 7.x-1.x e3e94aca8bb3c688c4c06d2fa4930a5c3d5ae70a
Comment #12
jvieille CreditAttribution: jvieille commentedI 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
Comment #13
Anonymous (not verified) CreditAttribution: Anonymous commentedDid 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.
Comment #14
jvieille CreditAttribution: jvieille commentedThanks 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)
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
Comment #15
Anonymous (not verified) CreditAttribution: Anonymous commentedIt 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).
Comment #16
jvieille CreditAttribution: jvieille commentedThe 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.
Great for French, but better to keep English for the Good of the Community :)
Comment #17
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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.
Comment #18
jvieille CreditAttribution: jvieille commentedIn 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?
Comment #19
Anonymous (not verified) CreditAttribution: Anonymous commentedif 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.
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.
Comment #20
jvieille CreditAttribution: jvieille commentedI 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.
Comment #21
Anonymous (not verified) CreditAttribution: Anonymous commentedI'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
Comment #22
bgm CreditAttribution: bgm commented"needs review" is for patches that need review :)
Comment #23
Anonymous (not verified) CreditAttribution: Anonymous commentedAnd 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:
Solutions:
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")
Note.
Search does not appear to have this issue with checking the CSRF tag, it appears to ignore it, so this may crop up again.
Comment #23.0
Anonymous (not verified) CreditAttribution: Anonymous commentedEdit Code