"You need a token to be here!" error preventing janrain Engage login to Drupal 6 website

Unfortunately, this module has never been tested with multi-site
Drupal and it may or may not work with such.

I ran a trace against your site and it looks like Drupal multi-site
redirects POST requests to the token URL by returning 302, which
results in the browser issuing a GET request to the same URL with the
parameters (including the token) stripped (hence the "You need a token
to be here" error message).

I suspect there could be a setting in the Drupal multi-site configuration
which would disable those redirects. Can you try? If there isn't one, we can
turn this report into a feature request.

Thanks,
George

However, could the same issue about

[Our sites] redirect POST requests to the token URL by returning 302, resulting in the browser issuing a GET request to the same URL with the parameters (including the token) stripped (hence the "You need a token to be here" error message).

still be the cause... but not be related to multisite?

OK, I see the same issue with your core site. There's something weird with your Drupal installation - any GETs or POSTs to the rpx token handler URL (created by this module) are redirected. You can see it for yourself by visiting www.addmysupport.com/rpx/token_handler. You can also compare the behaviour with the demo site by visiting http://drupal7.janraindemo.com/rpx/token_handler (notice that there's no redirect).

Perhaps some 3rd party module you have installed causes those redirects for requests to non-core drupal endpoints?

I also noticed that all redirects are to http://www.addmysupport.com/user/login. That would suggest that some setting (or module) within drupal requires the user to be logged in before letting them access the /rpx/token_handler endpoint.

I checked again, looks like the redirect happens because the module issues "access denied" if there's no token.
Anyway, can you try turning off any 3rd party modules that change the login/permissions subsystems of Drupal? Does this fix the problem?

Also, can you check the drupal error log right after a failure to sign in, to see if there are any error messages from 'rpx' or 'rpx_core'?

Chris, I just sent you a private message.

Chris,

When it comes to other modules modifying the standard Drupal login flow, the Janrain Engage module usually needs to have built-in support for them. Unfortunately, it hasn't been updated to support the Content Profile module and is incompatible with it at this moment.

I'm marking this as a clone of the Content Profile feature request ticket:
http://drupal.org/node/1197012

George

I don't think this issue is actually a clone of the Content Profile issue. We've run into this issue on our site.

I was able to track down the issue to the rpx_token_handler() function *blindly* setting the destination= query string when it redirects to the user/register page. Here's the scenario:

* User navigates to /user/login page.
* NEW user logs in via WordPress.com credentials
* WordPress.com does NOT provide email address (like some other providers), so the user is redirected to the user/register page to complete the registration process.
* Once the user fills in the email address and submits the form, user is redirected to the rpx/token_handler page with the "You need a token to be here!" message, BUT the user IS successfully logged in, they've just been incorrectly redirected back to rpx/token_handler.

The culprit is this code here near the end of the rpx_token_handler() function:

        $dest = drupal_get_destination();
        unset($_REQUEST['destination']);
        drupal_goto('user/register', $dest);

This code ASSUMES that the destination= query string will always be set when the login form is used. This is not a valid assumption. In fact, only the login *block* forces the setting of the destination query string. If a site doesn't use the login block, then the destination query string is likely to not be set. If the destination query string is NOT set, then drupal_get_destination() will *rightfully* return the CURRENT page(ie $_GET['q']), which, when this code is being executed, is the rpx/token_handler page. So, the destination string is being set to rpx/token_handler in this case. Once the registration has completed, the user is sent back to the token_handler, this time WITHOUT a token. They're logged in, but the redirect has kicked in.

The destination query string should never be set to rpx/token_handler. The proper way to handle this is to check to see if $_REQUEST['destination'] has a value BEFORE blindly setting it to something incorrect. Indeed, we worked around this issue by patching this section of code to look like this:

        if (!empty($_REQUEST['destination'])) {
          $dest = drupal_get_destination();
          unset($_REQUEST['destination']);
          drupal_goto('user/register', $dest);
        } else {
          drupal_goto('user/register');
        }

The above should allow the rpx module to play more nicely with other modules that may also alter the login flow... It definitely fixed our issues.