Redirect back to the slave site's destination

Does this happen every time for you? If so, make sure the list of slaves in the master settings form is complete.

I find this happens to me intermittently, but I can't seem to find a pattern yet.

Just marked #839342: Bakery does not redirect you back to subsite when logged in as duplicate of this, and this happens reliably on drupal.org. Quoting what I said there.

I think this worked before, and got broken when we updated Drupal with the GET destination spoofing security fix. So external URLs are not possible to pass in GET destination anymore. That this broke it is just a speculation, did not have time to look into it. We should definitely get back this functionality, because now when you log in, you get to be on a site you've not even tried to visit, so its very confusing. Seen this make people perplexed at Drupal Summer Camp Hungary this last week.

I've just tested this with drupal.org as follows:

- I logged out of drupal.org, went to groups.drupal.org and onto a group homepage.
- Clicked login from g.d.o.
- Was redirected to d.o. and logged in.
- Was redirected back to exact page I was on before on g.d.o. (from destination

So seems to be working for me...

Is this the method that you're talking about too?

The times I have seen this issue are on my own installations, but as I said before, it is intermittent and I haven't seen a pattern yet.

The redirection to the slave site doesn't happen in api.drupal.org, in example. If, for any reasons, you are not logged in on api.d.o, when you click on the Log in link you are redirected to d.o, but after logging in you are not redirected to api.d.o.

This could depend from the version of Bakery used on api.d.o; it could be the problem has been fixed on Bakery, but api.d.o is not using an updated version of Bakery. Another explanation is that g.d.o is using custom code to redirect the user back to its pages.

Any updates on this? I am evaluating Bakery to implement into a site network for a client preferring its profile passthrough to Shibboleth's but need to know this is working.

Here is a patch for review.

EDIT: It needs applying to the MASTER site. It does not matter whether the slave site is patched or not.

I don't think that works well for us. We added the feature to make sure that it didn't redirect to external sites as a security measure, so circumventing it is a bad idea.

We could perhaps confirm the destination against the list of slave servers before redirecting as a way to maintain good UX and moderate security.

I suppose there would be no harm in checking against the list of slave sites, although considering that the destination is taken from the (encrypted) cookie, it is perhaps a little unnecessary? i.e. - the requester has to know the bakery_key .

So that we can get a fix for this bug out, here is a patch that checks for whether the url in the cookie destination is saved as a bakery slave. I think it is a mainly cosmetic security enhancement considering the bakery_key is needed for the cookie to be valid anyway.

If the destination is not a bakery slave, this is logged in the watchdog.

It seems good to me.
I think it's better to check once more than to be sorry then; once the the destination URL is checked against the list of slave domains, we are 100% sure nobody can play tricks with bakery cookies.

It occurs to me that during the D7 port, the drupal_goto had the external attribute added which is why this bug is only applicable to D6.

Hopefully it doesn't have to slow the D6 fix up, but if #10 is OK, we'd probably want to add the slave check into D7 also.

@kiamlaluno,

Can you RTBC based on the patch in #10?

+++ bakery.module	22 Sep 2010 22:08:49 -0000
@@ -490,7 +490,22 @@ function _bakery_taste_oatmeal_cookie() 
+      header('Location: ' . $cookie['destination'], TRUE, 302);
+      exit();

Since this is manually redirecting, I think we should duplicate some of the shutdown code from http://api.drupal.org/api/function/drupal_goto/6

Powered by Dreditor.

@coltrane: Do you mean something like this?

I re-rolled the patch for the latest development of Bakery.

New version with more comments.

All seems good to me. Seems like a good improvement and really well commented.

Now that you can register and log in from the slave site, is this issue needed anymore?

I'd only say so if we planned to turn the slave register and login into optional functionality.

I apologize if I am reporting it in the wrong place, but I tried to log out from l.d.o and to log in; when I click on Login / Register, from l.d.o I am redirected to http://drupal.org/translate/downloads?destination=translate%2Fdownloads&no_cache=1287581302, which is a not existing page, nor is the login page.

subscribe

This is a critical bug for chicago2011. (Subscribe)

Unless we make slave login optional let's alter the discussion here to be about the problem of carrying the destination parameter through the login process. I think that's the only missing functionality now.

Holding onto the destination in the cookie is probably good, but the master will still have to return the user to the Bakery specific slave callback, then the destination can be pulled for the correct redirect.

Here's an operational patch, but CNW. It should verify the destination is on the slave and also work for the registration form.

Actually, using the second argument to parse_url() means an absolute URL won't be parsed, so I don't believe any further protection is needed.

Also, rewriting URLs would be required to carry the destination param to user/register, something Bakery shouldn't do I think.

This patch makes the first comment, and is CNR.

Looks great to me. http://drupal.org/cvs?commit=504588

It seems this needs some more urlencoding/decoding to work properly.

From a "login to post comments" link I ended up on node/389%2523comment-form instead of node/389#comment-form

How's this?

annoyingly subscribing because I think this is a v important UX issue that drive me utterly nuts and I want to poke it if it gets waylaid ;)

Now committed - http://drupalcode.org/project/bakery.git/commit/6c10b45

I should say: I tested/reviewed this and it seems like the ideal way to handle this.

Deployed on drupal.org so this should work with any subsite that has a moderately recent version of Bakery.

I logged in this morning from my iPhone - clicked on a 'reply to this' link in an email generated by Groups, had to log in and was taken to my profile page.
What's next? See if Groups need to update Bakery?

Indeed it was necessary to update bakery on groups.drupal.org. I've just done that and it seems to work.

Also, marking this fixed since we are not going to port these individually. See #1107692: Port bakery 6.x-2.x to 7.x-2.x for more details if interested.

yep, had the same situation last night (as per #33) and it worked perfectly. thanks!