[edit] This turned out much longer than I first had in mind, so feel free to skip to the final fix part
[/edit]
The following works on Vanilla 2.0.17.9 + ProxyConnect 1.9.3 combination, but I guess it will work on the whole 2.0.17.x line, hence the title.
After reading sottwell’s little guide I was also amazed by the simpleness of the vanilla’s single sign-on integration with modx, but after failure at the first attempt I immediately got in the infamous "nothing in the life is easy/free, especially if it appears to be so at the first glance" kind of state.
So I ventured once more on that many-times-traveled pilgrimage to knowledge which always lasts many moons just to prove myself for the umpteenth time that "the correct solution to the problem is always the simplest one"
Testing was done on the localhost but with virtual hosting setup in xampp which should emulate real server conditions.
Two subdomains are set: one for modx the other for vanilla:
http://modx.localhost.com and
http://vanilla.localhost.com
The original code was slightly changed:
snippet:
<?php
if(isset($_SESSION['webInternalKey'])) {
$output = "UniqueID=" . $_SESSION['webInternalKey'] . "\n";
$output .= "Name=" . $_SESSION['webShortname'] . "\n";
$output .= "Email=" . $_SESSION['webEmail'];
return $output;
}
return;
removed extra blank lines
plugin:
<?php
$e = &$modx->Event;
switch($e->name) {
case 'OnWebLogout': // integrated logout
setcookie('Vanilla', ' ', time() - 3600, '/', '.localhost.com');
setcookie('Vanilla-Volatile', ' ', time() - 3600, '/', '.localhost.com');
setcookie('VanillaProxy', ' ', time() - 3600, '/', '.localhost.com');
unset($_COOKIE['Vanilla']);
unset($_COOKIE['Vanilla-Volatile']);
unset($_COOKIE['VanillaProxy']);
break;
}
maybe at least that volatile cookie should be kept, don’t know..
But after trying (almost) all possible combinations of vanilla versions from 2.0.3 - 2.0.17.10 and proxyconnect 1.6 - 1.9.3 I could not believe that all exhibited the same behavior:
In spite everything was setup the correct way (and I’m also positive I won’t be clearing any more caches soon
), the plugin kept creating user with the blank credentials and nothing more!
Then after many trials and errors I ended up with the combination of the code & patches as follows, that according to the knowledge gathered should be bulletproof, but still nothing -
(and at the end when reverting everything to default state the ONLY thing needed for my testbed was that FINAL FIX:), but I’ll share all just in case, since there are people that needed at least some of the things on their setups:
path-to-vanilla/conf/config.php
added (temporarily, removed at the end of the process):
$Configuration['Garden']['Authenticator']['SyncScreen'] = TRUE;
to stop blank user creation due to automatic login..
/library/core/functions.general.php
if (!$Success)
return $Response;
Change to:
if ($Success)
return $Response;
to avoid vanilla bug that "eats" the first characters of the authentication resource data
Patch /library/core/class.cookieidentity.php
public static function GetCookiePayload($CookieName, $CookieHashMethod = NULL, $CookieSalt = NULL)
{
if (!self::CheckCookie($CookieName)) return FALSE;
$Payload = explode('|', $_COOKIE[$CookieName]);
+ array_shift($Payload);
+ array_shift($Payload);
+ array_shift($Payload);
- $Key = explode('-', $Payload[0]);
- $Expiration = array_pop($Key);
- $UserID = implode('-', $Key);
-
- $Payload = array($UserID, $Expiration);
return $Payload;
}
to avoid bug that destroys the cookie content before login
When configuring proxyconnect in vanilla select wordpress from the dropdown, wait, then select manual for java to kick in...
Also domain setting ain’t sticking so add (change to appropriate) ".localhost.com" to Cookie Domain value in /conf/config.php
(On some combinations authentication url, and even all setting weren’t beeing saved - but manually entering them in db showed nothing in the settings form fields, so beware!)
- Noticed that 2.0.17.10 doesn’t like proxy 1.9.3, settings aren’t showing no metter what, and appears to be working with 1.8.4, but I choose to ditch it in favor of 1.9.3 which people are complaining less about
So after trying all of this and having read 99% of the stuff written about the issue (luckily the info was relatively "sparse") I concluded that because many are still reporting that nothing works beyond 2.0.16 (for me that lower versions were not working also:) I was just about to give up, and then..
Then I finally checked that print cookie and noticed that vanilla is not reading the modx cookie - even though the manual for the plugin says that it should work for subdomains without a glitch!
(Disclaimer: I know Susan Sayz that first thing to do is to check that frak^%@ cookie, but why take the easy route
)
So after couple of head-banging days the solution came naturally:) - modx creates session cookie on the "base path", and to change that one needs to create the following variable in core system settings so here goes
(finally:) THAT
FINAL FIX: "session_cookie_domain" - set it to your root domain in the familiar format of ".localhost.com"
Maybe that was not necessary for earlier versions and it worked "out of the box", but I only recently started with 2.0.8 and all tests were done on that so I wouldn’t know..
Then proxyconnect will finally see the modx cookie, and bam: everything (?) is working!
Bu not without:
..(possible) caveats:
- if you don’t remove print_r($_COOKIE); from index.php when you try to e.g. enable plugin, theme, etc you will be greeted with the ingenious "fatal error: success" message..
- empty user is still created - proxyconnection really likes to do that:) - if you encounter this just fill the name and mail for the blank user and switch "him" to banned, that should rectify it..
in some cases:
- login link don’t link back to modx - remedied by hard coding
$Configuration['Garden']['SignIn']['Popup'] = FALSE;
$Configuration['Garden']['Authenticator']['SignInUrl'] = enter your path ...
- login works only when first attempt is done from modx side
- ...add more here...
I guess this covers all that matters on the troubleshooting front (I’m sure you experienced at least a thing or two), so maybe some will find it useful, and as the result won’t be breaking their computer peripherals, small furniture items, both at the same time:), etc...
It would be great if more MODxers try this, I don’t like the fact that not everything is perfect (as someone said "it still feels wobbly"), which may lead to not so trivial problems in production environment cause maybe there are still things left to correct, but it looks like vanilla is a great companion to modx - at least till Discuss arrives in full glory
The most important 1% of the links read:
http://rtfm.modx.com/display/revolution20/session_cookie_domain
(this "bug" still exists
http://modxcms.com/forums/index.php?topic=62299.0)
http://modxcms.com/forums/index.php?topic=53538.0
http://vanillaforums.org/docs/proxyconnect_sso
http://vanillaforums.org/discussion/13698/patch-for-proxyconnect-problems
http://vanillaforums.org/discussion/15492/manual-integration-on-2.0.17.-
☆ A M B ☆