protected node not redirecting

Hi ashabi,

I'm not sure I understand what you're saying here...

A user goes to your protected node, enters the proper password, and it asks him for the password again and again? Is that what you're trying to say?

I see that the wrong password behavior is as expected. Good.

Thank you.
Alexis

Ashabi,

Just in case, you need to have cookies working... Are your cookies turned off? If so then it wouldn't work indeed.

Thank you.
Alexis

As far as I know GoDaddy uses Apache on Linux. There is really no reason why the cookies would fail. I use a session variable, so the cookie itself is named by PHP. However, the session tables are being managed by Drupal and once in a while they delete older cookies (mainly anonymous users cookies that did not come back to your site within hours/days...) If somehow that process deletes the sessions too quickly, then it would fail.

Now I'd be really surprised, but you can see it in your database. The table is called sessions and the data is a serialized PHP array. If the table is empty, then that's certainly the problem. It should nearly never be empty (unless you have 0 hits for a while...)

Hmmm... the session is probably just fine. As a test you should be able to enter the password and then go to the protected page. It should not be protected anymore.

The redirect makes use of the $_GET['destination'] variable. More precisely, they use the $_REQUEST['destination'] variable, and that can be overwritten in a form... Now what's strange is that you tried with the same modules on another Drupal system and it worked just fine. So I'm not too sure how I could explain the difference.

In most cases, I have had to check the variables to debug such problems. It's an ugly process... I'm not too sure how I can help you further at this point.

One thing, at least, do you see the ?destination=... variable in the URL when you go to a protected page?

According to this page: http://www.php.net/manual/en/reserved.variables.request.php

the order of the variables is defined in the php.ini as defined here: http://www.php.net/manual/en/ini.core.php#ini.variables-order

There are a few examples here:

; Default Value: "EGPCS"
; Development Value: "GPCS"
; Production Value: "GPCS";
; http://php.net/variables-order
variables_order = "GPCS"

With ssh access you can see the file since it can be read by anyone on a Linux server. But I'd be surprised that would be different from the usual default (i.e. GPCS, and not EGPCS.)

This still doesn't really explain the source of the problem.

Thank you.
Alexis Wilke

Ah... if you're using the fork feature it's somewhat different. In that case it expects one of several password and depending on the password it will go to this or that page.

The fork would have a problem if you also have a destination, in that case the destination would take over no matter what and possibly send you to the wront node and thus send you back to the password screen.

The normal process (without the fork support) sends you here: protected_node/protected_node.redirect.inc

And the destination does its magic which is why we don't see a drupal_goto() in that file.

The culprit maybe protected_node_enterpassword_validate() or protected_node_enterpassword_submit() which both make the password effective (first it is verified and second it is saved in the session.)

Thank you.
Alexis Wilke