in my login destinatin module I have setted to go at this path after login http://www.forniture-alberghiere.net/ dashboard/3
but when legal module is acting with a new agreement to accept, he force the redirect to the view of users area, in my case http://www.forniture-alberghiere.net/ users/estufe I hope that colaborating with author of http://drupal.org/project/legal module you can patch soon this simple but big problem.
Here direct link to contact him:
http://drupal.org/user/3555/contact

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

matteoraggi’s picture

If someone find the same problem that I was having, you can find the patch of legal module here:
http://drupal.org/node/447476#comment-1539240
hoping that after version 6.x-2.2-beta4 this patch will be added to code.

rsvelko’s picture

posponed

rsvelko’s picture

Status: Active » Postponed
oskar_calvo’s picture

Status: Postponed » Active

what about this bug?

Oskar

rooby’s picture

Version: 6.x-2.3 » 7.x-1.x-dev
Status: Active » Needs review
FileSize
888 bytes

Here is a patch that fixes it for me in drupal 7.

Note that this won't port directly to drupal 6 as is because the hook_drupal_goto_alter() method of redirecting isn't used in drupal 6 (and can't be as the hook doesn't exist in drupal 6).

It might give someone direction on making a drupal 6 patch though (I haven't looked at the D6 code).

rooby’s picture

By the way, the drupal 7 symptoms are that the login destination redirect overrides the legal module's drupal_goto(), which means the user isn't sent to the legal page and they are logged out again silently.

mithy’s picture

@robby. Thank you for your continuous patches. However the root of this problem is a flawed way in which the Legal module handles logins and I will refrain from adding an error-prone hack in LD to fix it:

The problems in Legal module are:

  1. It calls drupal_goto in the login process. It has been discussed many times in this queue why it is not a good idea. It should alter the drupal_goto instead, same as LD module does.
  2. It logs the user out in user_login, if the terms were not accepted. Of course all modules assume that the user is logged in on this place and perform their actions (which is redirect in case of LD). This should be handled in user_validate instead.
mithy’s picture

Status: Needs review » Needs work
rooby’s picture

I see your point.
I'll have a look at doing a patch on the legal side of things. It definitely should be doing it's work in the validation stage.

On a side note, this is the first time I've seen the goto alter hook. It's a nice addition.

mithy’s picture

Definitely! Without this hook there is no way to do login destinations right. That's why it will never work for d6. This thread #761254: not working with content profile module ? has some explanations.

I posted about this bug in the queue of Legal module (#447476: conflict at login with login_destination module).

oskar_calvo’s picture

I think that one of the module should build a hook and the other one check this hook or will not way to resolve this problem.

Oskar

mithy’s picture

The problem can be solved without a hook and this is really not a time for major changes in API.

amaisano’s picture

Issue summary: View changes

FYI the May 2017 Legal update 1.7 breaks the dirty hack/patch (that I was using). To fix, just adjust the if condition to this instead:

if ($path && substr($path, 0, 12) == 'legal_accept')

Basically the security update removes the arguments from the URL, so there is no trailing slash.

Still hoping one or the other modules implements a stable fix to this.

matman476’s picture

#5 combined with #13 works for me!

arne_hortell’s picture

Add this to prevent issues with combination TFA//Legal//login_destination

if ($path && substr($path, 0, 10) == 'system/tfa') {
return;
}

rsvelko’s picture

Adding exceptions for 'legal_accept', 'legal_accept/' and 'system/tfa'.

  • rsvelko committed 337b311 on 7.x-1.x authored by rooby
    Issue #447480 by rooby, mithy, rsvelko, matteoraggi, amaisano: conflict...
rsvelko’s picture

Category: Bug report » Feature request
Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

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