Topic-icon Login refresh losing subdomain

Active Subscriptions:

None
12 years 9 months ago - 12 years 9 months ago #36158 by haibar
I make use of GTranslate that uses subdomains (via reverse proxy) so that each subdomain gets an automatic translation of the content.

If a Spanish speaking user comes to the site... he'll usually go to es.drinkedin.net
What happens now is that coming to that page (and being logged into FB), then JFBConnect recognizes this and wants to log the user into the site (good!) and you even see a FB message (in Spanish) stating that you're being connected via FB. Fine.

When the site refreshes (i.e. logged in), it ONLY goes back to the main domain (in English) - so it will go back to drinkedin.net (without the subdomain).

How do I set it so that the redirect is relative and doesn't mess up the subdomain?

I should add that I have the "Auto Login of Facebook Users" set and this causes the behavior - the problem is that I like having this auto login set... but how do I insure that any user of a foreign language gets redirected during any login back to the same subdomain?
Last edit: 12 years 9 months ago by haibar.
The topic has been locked.
Active Subscriptions:

None
12 years 9 months ago #36163 by haibar
It also seems that when JFBConnect logs the user into the site (even when using a foreign language subdomain), he is redirected and logged ONLY into the main domain. So, if I try to go back to the foreign language subdomain, then I'm still not logged in, JFBConecct recognizes this and does an automatic login back to the main domain. Thus I can never stay in the subdomain logged in.
The topic has been locked.
Active Subscriptions:

None
12 years 9 months ago #36224 by haibar
Has anyone else addressed a problem like this? Is this a FB restriction that would prevent redirection to subdomains? Is there something in the cookie so I could redirect back to the subdomain?
The topic has been locked.
Support Specialist
12 years 9 months ago #36229 by alzander
We've never experienced this, and what you're saying shouldn't be a problem. Facebook isn't the one choosing the redirection on login, that's completely JFBConnect. The only requirement Facebook has is that the redirection is to a sub-domain based off your primary domain: es.drinkedin.com, en.drinkedin.com, blah.drinkedin.com are fine... en.somewhereelse.com would be a problem.

The first question I'd have is what your Returning User and New User Redirections are set as. If they are set to "Same Page", I'd think it should work as expected. If you're redirecting to the Home Page or some other menu item, I could see JFBConnect using the primary domain.. so check that and let me know how it's configured (or try Same Page if not already).

Regarding not being logged in on both subdomain and main site, check your "Cookie Domain" setting in the Global Configuration area of Joomla. My guess is that it isn't set. It should be ".drinkedin.com" (no quotes, but make sure you have that . in the front). That will make all cookies set in either the subdomain or main site work on the others. That would be important for JFBConnect and Joomla in general.

I hope that helps, but keep me posted on how it goes,
Alex
The topic has been locked.
Active Subscriptions:

None
12 years 9 months ago #36237 by haibar
I understand what you're saying and this makes sense since I don't remember it being a problem with the built-in FB Connect of JomSocial.

1. I do have it to return to "Same Page"
2. I do have Facebook's URL set to the main domain of drinkedin.net with no subdomain mentioned
3. I do have the cookie domain set to .drinkedin.net (with the preceding period).

Still - when I login via FB, I get redirected from a subdomain back to the main domain.

Where in JFBConnect is this redirect happening?
The topic has been locked.
Active Subscriptions:

None
12 years 9 months ago - 12 years 9 months ago #36254 by haibar
I've been looking through the code, trying to find the exact place for this redirect. As best as I can figure, it's in the login.php file in the controllers directory. However, making modifications didn't lead anywhere.

I can find the subdomain that the user was on (via a header variable from the reverse proxy) - if I know where the redirect takes place, I can insure that it's back to the correct subdomain... so please let me know where this is occurring.
Last edit: 12 years 9 months ago by haibar.
The topic has been locked.
Support Specialist
12 years 9 months ago #36285 by alzander
I just investigate further and have some good information for you. The problem isn't actually the redirect itself. The redirect is a relative link from the domain that JFBConnect detects. The problem is that JFBConnect isn't detecting that it's being run on a subdomain properly, for some reason.

We use some Javascript to set the 'base' URL, which should be your base domain. That is always being set to drinkedin.net, and never to es.drinked.net. Where we do this is in the /components/com_jfbconnect/libraries/provider/facebook.php file with the following line:
"jfbc.base = '" . JURI::base() . "';\n" .
JURI::base() should be returning the full 'home' URL of your site, but isn't. You'd need to fix whatever is wrong with your multi-lingual approach that isn't properly updating JURI::base to make things work. Alternatively, you could fix that line to detect the domain a different way. I wouldn't recommend that last approach though as you'll need to make that change with each JFBConnect release *and* the wrong JURI::base() may cause other problems with JFBConnect or other extensions in the future.

Just so you know, I tried this solution by updating the jfbc.base Javascript variable in the browser console and it does properly leave the user in the right domain.

I hope that helps explain, but if not, let us know.

Thanks,
Alex
The topic has been locked.
Active Subscriptions:

None
12 years 9 months ago #36299 by haibar
Thanks for the reponse. I have a further complication in that the subdomains (i.e. languages) are sent via reverse proxy to pull in translations on the fly from the English content - this means that the server actually never "knows" it's being called from a subdomain as the proxies always pull from the main domain). However, there is a solution (for GTranslate) in that I can use the PHP variable sent in the header _SERVER which corresponds to my subdomain. Now all I have to do is reconstruct the base this way.
The topic has been locked.
Active Subscriptions:

None
12 years 9 months ago - 12 years 9 months ago #36300 by haibar
Just for the record, I'll post the changes here for someone else. I did hardcode my domain since these are custom changes anyway and must be reintegrated back for every JFBConnect update (unless you have a better place to override this behavior). Note that $returnLang being NULL implies the main domain (i.e. no translation)... otherwise, I do have a foreign language subdomain:

$returnLang = $_SERVER;
if (!$returnLang)
$returnBase = "drinkedin.net/";
else
$returnBase = "http://" . $returnLang . ".drinkedin.net/";
$doc->addCustomTag('<script type="text/javascript">' .
$logoutFacebookJavascript . "\n" .
"jfbc.base = '" . $returnBase . "';\n" .
"jfbc.return_url = '" . base64_encode($return) . "';\n" .
"jfbc.login.scope = '" . $requiredPerms . "';\n" .
"jfbc.login.show_modal = '" . $showLoginModal . "';\n" .
"jfbc.login.auto = '" . $this->configModel->getSetting('facebook_auto_login') . "';\n" .
"jfbc.login.logged_in = " . (!$user->guest && JFBCFactory::usermap()->getProviderUserId($user->id, 'facebook') ? 'true' : 'false') . ";\n" .
"jfbc.token = '" . JSession::getFormToken() . "';\n" .
$debugCmd .
"jfbc.init();\n" .
"</script>");
Last edit: 12 years 9 months ago by haibar.
The topic has been locked.
Support Specialist
12 years 9 months ago #36307 by alzander
Awesome! I'm glad to hear that got you going and you're running smoothly now.

Also, thanks for sharing your change back with us. I have add an investigation note into our issue tracker to look into if and how we should add this in the future. It won't be in the next release, and may not make it in any release if it could cause wider problems, but it is something we'll investigate later this year.

Until then, keep making the change when you update, but hopefully it's not too annoying now that you've found it.

Thanks, and good luck,
Alex
The topic has been locked.