I have the login block enabled on my website. If I logout and then try and log back in using the login block, it just redirects me back to the frontpage and I'm not logged in.

Logging in using any other page works fine.

I believe it's either related to http://drupal.org/node/113327 (I tried changing it from "/" to "node" but that didn't work) or it could be this line:
if(substr($_REQUEST['q'], -1) == "/") {
which I believe would match "http://www.example.com/", causing a problem.

I've had a few users complain to me already that they can't login (a couple even registered new accounts because they thought their accounts were deleted). That's why I put this bug as "critical".

Comments

denney’s picture

denney commented

I should of tested a bit more before I posted that.

The offending code is:

    //Nothing above has been matched - lets do a check to compare the current url to the site's frontpage.
    //  If matches, redirect to the frontpage (eg, http://www.mysite.com/)
    $frontpage = variable_get('site_frontpage', 'node');
    if($_REQUEST['q'] == $frontpage) {
      drupal_set_header("HTTP/1.1 301 Moved Permanently");
      drupal_goto('');
      exit();
    }

Commenting that code out and the login works properly again.

Can I just ask why, if a user is on the frontpage, you would be re-directing them back to that same page?

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

That code looks wrong - I'm 100% sure I updated it to use the proper Drupal 5.0 drupal_goto() command (it now has header stuff as arguments)... Bloody CVS!

The reason I do that check is that you could set node/123 to be your frontpage which means you have 2 URL's representing the same content (site.com/node/123 and site.com/)

The slash check is because if you map node/123 to about.html then Drupal will match an alias on node/123 but not node/123/ - which, although could be considered a seperate and unique URL, it does return the same content as node/123.

Christoph C. Cemper’s picture

Christoph C. Cemper commented

Oh wonderful... wish I found this before I troubled 30+ minutes thru my fresh install
to find this bug without even a watchdog error

http://drupal.org/node/64975#comment-196657

I found 3 revisions in CVS being identically... looks like you committed the old module with the comment of the new one

can you supply us the working version ASAP please?

thanks,christoph

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

I apologists for that - i;m away from my dev machine at the moment so have no access to the latest code. In my defense, CVS is the most non-intuitive thing on earth (at least to me) and thats why there may me a very strange set of commit's for this version.

Bevan’s picture

Bevan commented

I was about to post a new bug report when I thought I'd check to see if someone has already posted it -- and here I am...

I found that by changing <form action="/node?destination=node"> to <form action="/?destination=node"> or even simply <form action="/"> in the User login block form made the login post and process work properly. I'm not a coder, so I don't know how to fix that in the module.

User login forms work fine on pages other than the homepage, as the
is either the path of the current page, OR action="/?destination=path%2Fof%2Fcurrent%2Fpage". (I'm not sure what the condition is that sets this; I think it could be related to whether the current page is an admin page.)

Looking forward to a patched release. :)

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

I can confirm - this happens in all versions. I'm currently trying to fix it. Hopefully will commit a working 4.7 version tonight and a 5.0 one tomorrow.

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

I have a fix - on the first line of globalredirect_init(), change the if statement to:

if(isset($_REQUEST['q']) && function_exists('drupal_get_path_alias') && !isset($_REQUEST['destination'])) {

that last bit checks if drupal is meant to do a redirect itself - if so, let drupal get on with it and dont interrupt. That way, on the next page load which you DO get directed to by drupal, Global Redirect will check and redirect that, if necessary. Yeah it might end up with multiple 301's - but it works. Its either that or no frontpage redirection as Drupal seems to like setting the action to the alias of the frontpage path and the destination to the system path of the frontpage. This causes an eternal loop when drupal sends you to something like node/2 and global redirect detects it and sends you back to the frontpage but preserves the arguments on the url - which then sends you to node/2 - which then directs to frontpage.... See the pattern? :-)

I'm committing this change for 4.7 and, pending CVS killing my soul and time permitting, maybe 5.0 too...

zart’s picture

zart commented

I solved this problem by changing code to

function globalredirect_init() {
  if(($_SERVER['REQUEST_METHOD'] == 'GET') && isset($_REQUEST['q']) && function_exists('drupal_get_path_alias')) {
  ...

ie. allowing redirects only on GET requests and not on POST.

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

Interesting and valid alternative.

Whats the pro's of using your method over my one? (I'm completely open to suggestions!)

zart’s picture

zart commented

I thought this was bug in 5.0 and waited till 5.1, then figured out that globalredirect is culprit. My guess was that redirect happens before drupal has a chance to process login form in POST so login doesn't happen. Thus I disabled redirects for anything except GET. This was few days ago, before you posted your version of fix. I can't say whether my approach is better or worse then yours, imo both fixes are complimentary.

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

Cool - well (and thanks for the idea) unless anyone can suggest a reason why your idea is a better sollution than the idea I've already implemented, I'll leave this one for people to find an use if they want to.

Thanks for the idea zart! :-)

hass’s picture

hass commented

i think the GET method limitation is a very good idea and will solve many possible problems! Let's think about - why we really need or use "Global Redirect". I think we must answer - Search Engines... so - for internal users it doesn't matter what the URL looks like... to outside it must be correct for not creating duplicate content... - global redirect only prevents duplicate content - everything else doesn't matter.

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

This is true - the initial spec was a lightweight module which simply redirected system paths with aliases to their alias.

Since then, though, its expanded to take on frontpage redirection + a check if there is a slash.

Personally - I'd like to see some more features added to it which a user can enabled and disabled from a settings page. This could include (as suggested in another post) a primary/secondary alias setup and any other suggestions that seem applicable.

Also - i'm not sure what your comment was going for - i saw no direct link between commenting on keeping Global Redirect simple and to the point and the discussion on if filtering by Request Method or by checking for the presence of the destination argument in the URL.

Could you please explain a little further?

(btw, thanks for the comments!)

nicholasthompson’s picture

nicholasthompson
Primary language English
commented
Status: Active » Fixed

Well after about a week with no complaints - I think this is considered fixed...

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)
netlynx’s picture

netlynx commented
Version: 5.x-1.0 » 6.x-1.2
Status: Closed (fixed) » Active

Reawakening this old bug from 5.x-1.0 - or can anyone explain what I'm missing please?

Following the below changes the symptoms described by previous posters are displayed - redirect to blank page from home page after login using login block but using domain/user page login all is fine.

Following 3 days of updating modules and picking through minor bugs patches etc. I have just activated a migrated site from 5.x to 6.x
All was working fine until I made the switch to live.
My go-live routine included
- renaming the db to the live db name (and flushing the db)
- renaming the sites/mydomain.com directory to the live domain
- updating settings.php with live db name
- updating apache file (just renaming the server from test to live domain)

All was in order prior to these changes. I have emptied sessions and watchdog and flushed the db. What's changed that effects this redirect?!

I can see there are code fixes pasted in here but 1. they do not indicate where these code changes should be and 2) they are for 5.x and 3) they do not appear to be approved/committed to core.

Any thoughts please?

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Version: 6.x-1.2 » 5.x-1.0
Status: Active » Closed (fixed)

Instead of re-opening an issue that's been closed for over three years, please file a new issue.