I'm using r403login for quite some time and it worked very well. Now, for some reason I can't name, the user is not redirected to the page he was trying to access, after he logged in, if that page is the frontpage and the redirection url is "user/login?destination=". This issue could be related to the lates D6 release (6.16) but I have no chance to test that with D6.15 at the moment. The user is directed to his profile page after the login.

Anyone experiencing the same problem or anyone with an idea for a solution?

CommentFileSizeAuthor
#15 common-destination-741434-15.patch573 bytesbrad.bulger
#12 common-destination-741434-12.patch731 bytesbrad.bulger
#9 common-destination-741434-9.patch720 bytesbrad.bulger
#6 common-destination-741434-5.patch741 bytesbrad.bulger
#2 common.destination.patch502 bytesbrad.bulger

Comments

Anonymous’s picture

Anonymous (not verified) commented
Title: No redirection after login » No redirection to frontpage after login
Project: Redirect 403 to User Login » Drupal core
Version: 6.x-1.2 » 6.16
Component: Code » user.module

Sorry, that seems to be a drupal core issue. When visiting the Login form directly with no destination given, the user is redirected to his profile, but should be redirected to the frontpage. Updated description:

After logging in with an empty destination, the user is redirected to his profile instead of the frontpage. When a user visits the frontpage of a site and has no access rights, he is redirected to his profile after the login but expects to get to the frotnpage, he just requested.

brad.bulger’s picture

brad.bulger commented
Component: user.module » base system
StatusFileSize
new common.destination.patch502 bytes

this looks like a bug introduced in 6.16 - it's testing if $destination is not empty, should test that it is not FALSE to allow for an empty string. this is the change in question, i believe - a copy of a Drupal 5 change?

anyway, changing that test makes an empty destination - where the url has destination= - work again.

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Needs review

Interesting. I've never seen that !== operator before, but that works fine for me. Th patch still needs some review from someone who knows what has been the intention of the change that was made to that code in D6.16.

Status: Needs review » Needs work

The last submitted patch, common.destination.patch, failed testing.

brad.bulger’s picture

brad.bulger commented

=== and !== are strict about data types. so 0 == "" is true but 0 === "" is not true. and yes about the patch. i don't know what the related 5.x change was, it might be that something needs fixing there too.

brad.bulger’s picture

brad.bulger commented
StatusFileSize
new common-destination-741434-5.patch741 bytes

ah, i was misreading the revision log. it looks like this was part of a security fix in the latest releases of 6.x and 5.x. this fix ought to be OK but yes, someone needs to review it. the automated system is trying to apply it to 7.x as far as i can tell and that will never work anyway. fwiw, i'm attaching a new file against CVS DRUPAL-6.

brad.bulger’s picture

brad.bulger commented
Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, common-destination-741434-5.patch, failed testing.

brad.bulger’s picture

brad.bulger commented
Status: Needs work » Needs review
StatusFileSize
new common-destination-741434-9.patch720 bytes

trying again...

Status: Needs review » Needs work

The last submitted patch, common-destination-741434-9.patch, failed testing.

gsutcliffe’s picture

gsutcliffe commented

As an FYI for other users this same problem can be reproduced using the Email Registration module. That module redirects to the user page when a user is authenticated. It took me a while to track that issue down today and wanted to share.

brad.bulger’s picture

brad.bulger commented
Version: 6.16 » 6.17
StatusFileSize
new common-destination-741434-12.patch731 bytes

i don't seem to be able to make this patch file correctly. any suggestions anyone might have as to what might be wrong would be great. meantime, here's another go, against 6.17

bryrock’s picture

bryrock commented

(subscribe)

sinergieunisone’s picture

sinergieunisone commented

Try to visit admin/config/system/site-information and see at the end of the page what address is set like homepage (by default is /node) and put it like destination.

brad.bulger’s picture

brad.bulger commented
Version: 6.17 » 6.22
Status: Needs work » Needs review
StatusFileSize
new common-destination-741434-15.patch573 bytes

reroll against 6.x from git - let's see if it gets tested........

Status: Needs review » Needs work

The last submitted patch, common-destination-741434-15.patch, failed testing.

Pav-2’s picture

Pav-2 commented
Title: No redirection to frontpage after login » After failed login I'm taken to destination=node%2F793 ? - please help
Version: 6.22 » 6.20

Hi there,

I'm on 6.20 and getting a similar issue where only in case of a failed login I'm getting Server Error (in Chrome) and white screen in FF - this page is appended with destination=node%2F793. If I remove the =node%2F793 or the whole destination=node%2F793 I'll get my page as desired - with a warning that I've entered wrong password or username.
It also appears fine if I reload the page.

This happens if I enter wrong login to the site (password or username) while going into it from a login box placed in Panel on the page which is permission protected.

If I do this from /user or /admin this is fine.

I've tried disabling the login toboggan and login destinations but with no result.
Any help will be much appreciated.

Cheers,

Pav

brad.bulger’s picture

brad.bulger commented
Title: After failed login I'm taken to destination=node%2F793 ? - please help » No redirection to frontpage after login
Version: 6.20 » 6.24

Restored actual issue title and last tested version. This bug is still present in 6.24. I will try to create a patch file again. If anyone reads this who has a better grasp on that, the change is extremely simple, to line 327 of includes/common.inc:

-  if ($destination) {
+  if ($destination !== FALSE) {
     // Do not redirect to an absolute URL originating from user input.
Anonymous’s picture

Anonymous (not verified) commented
Version: 6.24 » 6.25

doesn't works for me... changed line 327 of common.inc, as you wrote, but still redirecting to the user account page after login
used actions&triggers to fix that problem

Status: Needs work » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.