Facebook Connect Login: Redirect to access denied...

Hi @all,

i have the same issue.

Has anyone a solution?

Thx.
Tom

interesting. I'm not sure where the best fix for this is. Could be in fb.js... it might look for the destination parameter instead of simply reloading. It's too bad drupal denies access to that page when user is registered.

Trying to solve those redirect issues, too, this is what I came up with: the culprit seems to be the fb.reload_url setting, which ignores any URL parameters. The attached patch tries to fix two issues:

1. If a destination is set, it is used.
2. If the connect button is shown on the login page, redirect away to the user profile page (i.e., imitate Drupal's default behavior) to avoid an 'access denied' which would normally appear due to reloading the same page.
   However, this might only be true if local accounts are created. Since I'm currently after this functionality and have only limited knowledge about other use cases, this needs a second look from someone with more in-depth knowledge.

There's already a change like this in the module. Try updating, it should honor destination.

And you're right that in the case where an account is not created automatically, your logic to redirect to the user page will be the wrong thing.

Frankly, I consider it a problem with drupal that it returns access denied on those pages. And I'm not sure the best workaround.

There's already a change like this in the module. Try updating, it should honor destination.

I'm already on HEAD, so if there is already code in place it doesn't seem to work.

my mistake. It is not yet checked in. Sorry I was confused. Here's the change in my working copy.

Again this does not fix the access denied, only honors the destination.

Perfect, #7 worked like a charm. Thank you Dave.

assuming fixed unless I hear otherwise

subscribing...

Patch #7 works great, however any destinations with fragments within them are unable to pass properly through url(). url() expects the fragment in an option and not in the $path variable; but even if we did pass the fragment into url(), fb.js tacks something at the end of the destination negating the effects of the anchor.

I went ahead and created a new js variable called reload_url_fragment that is extracted before url() and to be tacked on at the last minute with fb.js

This patch builds off of patch #7.

As for the second point in comment #3 regarding user redirecting the user the appropriate spot, there are three approaches that we could take:

1) Have fb.js send the user to /user if it notices that it is logged in and redirecting to /user/register or /user/login
2) Add a manual redirect in template.php that will send any logged in user trying to access /user/register or /user/login to /user:

function dreamy_preprocess_page(&$vars) {
  global $user;
  if( $user->uid != 0 &&
      (
          (arg(0) == 'user' && arg(1) == 'login') ||
          (arg(0) == 'user' && arg(1) == 'register')
       )
     ) {
    header('Location: '. "/user", TRUE);
  }
}

My approach was #2 as it fits my needs; #1 needs a little more introspection from the community. No action needed here relating to this comment, just thought I'd dump my notes here to this part of the problem.

Thanks mcpuddin for patch #11, I've added it to my local copy and should make it into next release.

Your suggestion for #12 could also be in a module's init function and looks reasonable. Its really a problem with Drupal that just happens to appear when using facebook connect. Not a bug in modules/fb, IMHO.

checked in mcpuddin's patch for fragments.
Also fb_example_init() contains code similar to mcpuddin's #12.

Thanks.

Thanks dave for being an awesome maintainer and moving the code along! I believe I'll see you this monday at SFDUG

There is still one case where this doesn't work.

When you log in from the user/login page you get redirected back to the user/login page, for which access is denied.
It should probably default to the home page in this case.

It also doesn't use login redirects from modules like login_toboggan.
If possible it would be good if it would use those if logging in from the user/login page.

When you log in from the user/login page you get redirected back to the user/login page, for which access is denied.
It should probably default to the home page in this case.

Wow. Did you even read the thread?

It also doesn't use login redirects from modules like login_toboggan.

Unrelated problems belong in another thread. Submit a new issue (preferably with a patch).

Whoops sorry about that.

A big thank to #12 -- that did it for me to avoid the access denied issue when logging on from user/login...

Might be good to put that in the README file...