Steps to reproduce:

1. Go to the login url at relying site. You'll be redirected to the provider site.
2. Instead of login, create a new account
3. After you click submit you'll be taken to the page where you're being asked if you want to continue
4. Click Yes, just this once
5. You'll be redirected back to the relying site with openid/authenticate as the url and you get a 403

CommentFileSizeAuthor
#2 1218198.patch4.44 KBlelizondo

Comments

lelizondo’s picture

lelizondo commented

I've been digging around this and I found a possible solution:

1. The openid/authenticate path is created by openid and it can be acceded by anonymous users.
2. This path calls openid_authentication_page() which calls openid_authentication($response) if the result of openid_complete() is 'success'

In the patch I'm attaching, I'm cloning two functions: openid_authentication_page and openid_authentication and also using a hook_menu_alter to change the page callback from openid_authentication_page to the clone.

The reason I'm doing this is because I'm changing the success case to call the clone of openid_authentication

This last function, openid_authentication, is the one performing the redirection that is causing the 403. In this function I'm only changing one of the last lines:

from:

drupal_redirect_form($form, $form_state['redirect']);

to:

drupal_redirect_form($form, 'user');

This way the user will be redirected to his/her profile avoiding the 403.

Now, I must say this, I don't know if this is the best approach, this is just something that took me 15 minutes to solve and is probably an easy and working solution but I don't know if this is the best way to solve this bug.

lelizondo’s picture

lelizondo commented
Status: Active » Needs review
StatusFileSize
new 1218198.patch4.44 KB

And here is the patch

niccolox’s picture

niccolox commented
Version: » 6.x-1.x-dev

I tried that patch and a new user gets 403...

I made this change and it worked for me http://groups.drupal.org/node/154879#comment-522834

if I remember correctly the code snippet below is from one of the Dev Seed versions, maybe the OpenAtrium version... 

/**
* Request authentication.
*/
function openid_relying_sso_request() {
  $provider = variable_get('openid_relying_sso_provider', array());
  $front = drupal_get_normal_path(variable_get('site_frontpage', 'node'));
  $values = array(
    'openid_identifier' => $provider['url'],
    'openid.return_to' => url('openid/authenticate', array('absolute' => TRUE, 'query' => "destination=$front")),
  );
  openid_begin($values['openid_identifier'], $values['openid.return_to'], $values);
}4
markwk’s picture

markwk commented

Similar issue. Verdict on the solution?

markwk’s picture

markwk commented

Patch worked. Interesting solution.

niccolox’s picture

niccolox commented

have you tried the latest releases of these modules? I am not sure you need the patch..

xamanu’s picture

xamanu commented

I couldn't reproduce the error. But I was digging around with several things. So anyway I'd ask you to test it again with the newest versions of the modules (please check them out via git, since the script has not been run yet). I spend a day today fixing different stuff and testing general setups.

I don't really agree with lelizondos approach. There are better ways of controlling the redirect. But anyway it should not cause any problems if everything is fine. Where is it redirecting to when you get the access denied error?

Anyway I moved around a bit the OmniAuth things to have branches for 6.x and 7.x versions. So the setup I was testing can be found here right now:

* drush make https://gitorious.org/omniauth/makefiles/blobs/raw/7.x-1.x/omniauth_rely...
* drush make https://gitorious.org/omniauth/makefiles/blobs/raw/6.x-1.x/omniauth_prov...
* drush make https://gitorious.org/omniauth/makefiles/blobs/raw/6.x-1.x/omniauth_rely...

niccolox’s picture

niccolox commented

OpenID is now a contrib module .. .maybe this will speed things up

http://drupal.org/node/556380#comment-4913566

markwk’s picture

markwk commented

So got it working fine with the latest commits.

Ran into an error when I was transferring from a Relying Atrium site group (i.e. site-name.com/group-01/), logged in ok, but get "Accessed denied" @ openid/provider/continue. The error I suppose is coming from how the relying site uses purl. Thus it can have site-name.com/group-01/user/login.

Thoughts on this...?

niccolox’s picture

niccolox commented

I just did a pretty thorough test and got Atrium relying, D7 relying, Pressflow D6 relying all talking to a Pressflow 6 provider

@markwk check its not a username clash or something weird with users... the error message is basic and there could be a number or causes... probably minor config

with OpenID now a contrib module (again) we should all pitch in a bundle an OpenID solution

check out Domain or Deploy for good examples of bundles..

http://drupal.org/project/domain
http://drupal.org/project/deploy

we need to document this too, as far as I can see there are 3 major implementions

1. minimal, no AX, only OpenID
2. OpenID AX, integrated with standard Profile (OpenProfiles)
3. OpenID AX with Content Profile (Omniauth)

OpenProfiles and Omniauth do things differently and its great to have examples for both

but... we dont have Features for the very basic set-up 1.

or maybe it would be better to do a minimal Feature which is 1.5 i.e. OpenID AX but with just AX Username and Email

well done xamanu ! louis, markw

this is actually a very major achievement !

hydra’s picture

hydra commented

For me eht registrationprocess worked fpor relying D7, also as D6 after I reminded to create a new relyingparty at the provider. I think the original Issue is fixed by the actual versions

xamanu’s picture

xamanu commented
Status: Needs review » Fixed

Thank you for testing. If anybody still has this issue. Please reopen.

niccolox’s picture

niccolox commented

couple of comments for other users with this

1. you need to set-up the provider first and add the relying to the provider, then on the relying you add the provider. this must be done in that order (or is it the other way round, too tired right now?)
2. I found for set-up/testing its good to reduce the cookie expiration from 3600 to say 60 seconds
3. caching can be a pain with js etc, try to test without caching if possible

cheers

Status: Fixed » Closed (fixed)

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