Can someone please confirm if the integration of the registration process is working? While the sign-in / out process appears to be working as intended, the registration from within Vanilla is not affected at all. Regardless of settings (manual / auto), with proper values filled in, the 'Apply for Membership' link doesn't redirect to the WP registration URL as specified.
The plugin definitely has no effect on the registration process, however I found out that manually setting a registration URL in config.php has the desired effect: $Configuration['Garden']['Authenticator']['RegisterUrl'] = 'REGISTERURL';
When I login to WordPress and view the forum and login with the same credentials, it cannot login as admin, so I can not access the Vanilla Dashboard. But still be able to login as member.
When I logout, I get redirected to WordPress login form, not to the forum page. Now, everytime I login to forum via forum 'Sign in' link, I get login automatically without providing password.
I've curious and tell my friend in another place to click the 'Sign in' link forum, and he got logged in automatically with my last member account without providing password too, even he can change the profile picture. Weird.
I think this is a big security issue and you should fix it as soon as posibble.
@rio That really sounds weird, however I don't think that it relates to a major security issue in either Vanilla or ProxyConnect. If you can access your Admin-Dashboard, try disabling ProxyConnect, properly clear your cookies and then maybe start anew. If you cannot acces your dashboard, maybe manually editing your config.php and removing everything related to ProxyConnect could help (without any warranty;).
@rio you are being logged in automatically because cookies have not expired or have been not been cleared.
It is NOT a security problem except at public terminals in say Libraries, Universities and Schools when you should exit the browser rather than just log out, even rebooting the machine if necessary.
You can always login to the admin interface (avoiding proxy authentication) via http://example.com/yourforum/entry/password but only to accounts e.g. the original admin account i.e. id/1 that have been setup explicitly with accounts in Vanilla rather than WordPress.
I'm stuck.. and my problem sounds a bit like Rio's issue.
I have a WordPress 3.0.1 installation and I've created a brand new install of Vanilla 2.0.10 and installed ProxyConnect 1.8 with Manual configuration (since the WordPress auto config still gives me errors). At the very least, can someone tell me why my WordPress 3.0.1 won't allow ProxyConnectAutoconfigure? The only HTTP header that I'm seeing from the ProxyConnect WordPress plugin is:
X-ProxyConnect-Enabled: yes No other ProxyConnect HTTP headers are displayed. This implies to me that WordPress isn't set up for autoconfigure.
Moving on...
Besides that issue, how is it possible that I can set up the brand new Vanilla install and log in as the admin on WordPress, then use the SyncScreen to link my WordPress admin account to my Vanilla admin account (upon the first Vanilla login)......and then create a brand new user in WordPress using a different email address, clear my cookies, clear my cache, restart my browser and log in to WordPress as that new user and go to Vanilla only to see I'm logged in as the Vanilla admin?? (i.e. the last user that was logged in)
I've reinstalled Vanilla twice now, from scratch, and I get the same result every time. I don't understand how Vanilla can keep logging me in as the admin (or last logged-in user) when I'm doing everything in my power to clear my cookies/cache/history and log in as a new WordPress user. Even if I create additional WordPress users, they all log into Vanilla as the last Vanilla user to log in (the admin account in this case). I just can't get ProxyConnect to create a new Vanilla user no matter what I do.
Regarding ProxyConnectAutoconfigure, I've done fresh installs of WordPress 3.0.1 and WordPress 3.0 with Vanilla 2.0.10 and ProxyConnect 1.8 on a completely different domain (same server) and I still can't get WordPress to Autoconfigure with ProxyConnect and its WP3 plugin.
Is everyone else here able to Autoconfigure Vanilla with WordPress 3.0+?
(I'm also still experiencing the same-user bug described above by me and Rio)
@dan39 I guess sharing cookies across different domains is always problematic. Furthermore, AutoConfigure doesn't seem to work in a localhost environment, whereas it works fine when both WP and Vanilla are on the same domain (Vanilla in a subfolder).
I'm not sharing cookies across different domains. (I'm pretty sure that's not even allowed by HTTP). I was merely replicating the same bug on two separate, and completely independent, domains (i.e. two separate clean installs of Vanilla and WordPress that have nothing to do with each other).
No matter what I do, I can't seem to get WordPress to autoconfigure with Vanilla on the same domain... and when I set ProxyConnect up via Manual configuration, I get the same problem that Rio gets.
The fact that I can replicate the same problems twice with completely clean installs (on the same server) — and since Rio describes similar issues — should all give some credence to this.
I figured it out. My server was missing some modules. For those having similar issues described above, you'll need to double-check your server configuration against the Official Requirements for Vanilla.
Just a little request, but it would save a lot of time and bug reporting for others in the future if there were a way for Vanilla (and/or the WP plugin) to throw off more descriptive errors when things aren't working properly.
Maybe I am missing something, but the latest version of this plugin (1.8) contains no code for actually saving settings. Forget the fact that it's missing some wrapper divs for the slices that are trying to be loaded.
I have hacked my way through it to get it to what I might consider a beta version. The three files that need updated can be found here.
Regarding ProxyConnectAutoconfigure, I've done fresh installs of WordPress 3.0.1 and WordPress 3.0 with Vanilla 2.0.10 and ProxyConnect 1.8 on a completely different domain (same server) and I still can't get WordPress to Autoconfigure with ProxyConnect and its WP3 plugin.
Is everyone else here able to Autoconfigure Vanilla with WordPress 3.0+?
(I'm also still experiencing the same-user bug described above by me and Rio)
I've created a little screencast of how I use ProxyConnect. Could you watch and tell me how you do it differently?
Thanks Tim. That was helpful. If you see my previous comment (from Oct 5th), I was able to figure it out. It turns out my server wasn't configured properly. I'm sorry for the confusion and for wasting everyone's time.
Due to my experience, I've suggested having Vanilla do a server check before it lets you install it. If I remember correctly, SimplePie has a "SimplePie Compatibility Test" script that you can run before you even try to install their framework. Would save everyone a lot of time (you especially!) if Vanilla could have the same thing!
Had the same issue as Dan39 and rio. The reason is that I didn't have cURL installed (which, I assume, ProxyConnect uses to parse the results of the AuthenticateURL).
If you're having similar problems, first check and make sure cURL is installed by running phpinfo() and looking for a curl section. (Create check.php with contents <?php phpinfo() ?>.)
To install cURL on Ubuntu, type sudo apt-get install curl libcurl3 libcurl3-dev php5-curl To install cURL on Windows, find the line in php.ini with;extension=php_curl.dll and remove the semi-colon.
(And, I'd echo dan39's request to build a cURL check into ProxyConnect.)
It was pure stupidity. I admit it. I was sure that I had cURL installed already on that server. Never took the time to confirm it. Unfortunately, I won't be the last to make that mistake.
You probably don't need something that elaborate, but it's an interesting approach nonetheless.
I know it sucks, but ultimately a compatibility test in the core will make Vanilla more polished product and there will be fewer frustrated users who's first instinct will be to mistakenly blame the software.
And it's worth keeping in mind that Vanilla's requirements are a bit stricter than other comparable software out there. Take a look at the requirements for WordPress, which could not be easier to install:
Comments
While the sign-in / out process appears to be working as intended, the registration from within Vanilla is not affected at all. Regardless of settings (manual / auto), with proper values filled in, the 'Apply for Membership' link doesn't redirect to the WP registration URL as specified.
$Configuration['Garden']['Authenticator']['RegisterUrl'] = 'REGISTERURL';I have these conditions:
WordPress script on http://mysite.com/wp/ but got live in http://mysite.com/
and I install Vanilla on http://mysite.com/forum/
When I login to WordPress and view the forum and login with the same credentials, it cannot login as admin, so I can not access the Vanilla Dashboard. But still be able to login as member.
When I logout, I get redirected to WordPress login form, not to the forum page. Now, everytime I login to forum via forum 'Sign in' link, I get login automatically without providing password.
I've curious and tell my friend in another place to click the 'Sign in' link forum, and he got logged in automatically with my last member account without providing password too, even he can change the profile picture. Weird.
I think this is a big security issue and you should fix it as soon as posibble.
you are being logged in automatically because cookies have not expired or have been not been cleared.
It is NOT a security problem except at public terminals in say Libraries, Universities and Schools when you should exit the browser rather than just log out, even rebooting the machine if necessary.
You can always login to the admin interface (avoiding proxy authentication) via
http://example.com/yourforum/entry/password
but only to accounts e.g. the original admin account i.e. id/1 that have been setup explicitly with accounts in Vanilla rather than WordPress.
I have a WordPress 3.0.1 installation and I've created a brand new install of Vanilla 2.0.10 and installed ProxyConnect 1.8 with Manual configuration (since the WordPress auto config still gives me errors). At the very least, can someone tell me why my WordPress 3.0.1 won't allow ProxyConnectAutoconfigure? The only HTTP header that I'm seeing from the ProxyConnect WordPress plugin is:
X-ProxyConnect-Enabled: yesNo other ProxyConnect HTTP headers are displayed. This implies to me that WordPress isn't set up for autoconfigure.
Moving on...
Besides that issue, how is it possible that I can set up the brand new Vanilla install and log in as the admin on WordPress, then use the SyncScreen to link my WordPress admin account to my Vanilla admin account (upon the first Vanilla login)......and then create a brand new user in WordPress using a different email address, clear my cookies, clear my cache, restart my browser and log in to WordPress as that new user and go to Vanilla only to see I'm logged in as the Vanilla admin?? (i.e. the last user that was logged in)
I've reinstalled Vanilla twice now, from scratch, and I get the same result every time. I don't understand how Vanilla can keep logging me in as the admin (or last logged-in user) when I'm doing everything in my power to clear my cookies/cache/history and log in as a new WordPress user. Even if I create additional WordPress users, they all log into Vanilla as the last Vanilla user to log in (the admin account in this case). I just can't get ProxyConnect to create a new Vanilla user no matter what I do.
Please help.
Is everyone else here able to Autoconfigure Vanilla with WordPress 3.0+?
(I'm also still experiencing the same-user bug described above by me and Rio)
No matter what I do, I can't seem to get WordPress to autoconfigure with Vanilla on the same domain... and when I set ProxyConnect up via Manual configuration, I get the same problem that Rio gets.
The fact that I can replicate the same problems twice with completely clean installs (on the same server) — and since Rio describes similar issues — should all give some credence to this.
Just a little request, but it would save a lot of time and bug reporting for others in the future if there were a way for Vanilla (and/or the WP plugin) to throw off more descriptive errors when things aren't working properly.
I have hacked my way through it to get it to what I might consider a beta version. The three files that need updated can be found here.
Part 1 - http://screenr.com/UHl
Part 2 - http://screenr.com/hHl
Vanilla Forums COO [GitHub, Twitter, About.me]
Due to my experience, I've suggested having Vanilla do a server check before it lets you install it. If I remember correctly, SimplePie has a "SimplePie Compatibility Test" script that you can run before you even try to install their framework. Would save everyone a lot of time (you especially!) if Vanilla could have the same thing!
Had the same issue as Dan39 and rio. The reason is that I didn't have cURL installed (which, I assume, ProxyConnect uses to parse the results of the AuthenticateURL).
If you're having similar problems, first check and make sure cURL is installed by running phpinfo() and looking for a curl section. (Create check.php with contents <?php phpinfo() ?>.)
To install cURL on Ubuntu, type
sudo apt-get install curl libcurl3 libcurl3-dev php5-curlTo install cURL on Windows, find the line in php.ini with
;extension=php_curl.dlland remove the semi-colon.(And, I'd echo dan39's request to build a cURL check into ProxyConnect.)
http://www.vanillaforums.org/page/Requirements
I could build in a check I suppose. Probably into core though. Sigh.
Vanilla Forums COO [GitHub, Twitter, About.me]
I will try to mix Vanilla 2.0.11 with ProxyConnect 1.8 and share the result here. Wish me luck
Cheers.
btw @Tim, Here's what simplepie's compatibility test page looks like:
http://dl.dropbox.com/u/778166/simplepie-test.png
...and here's the code:
http://svn.simplepie.org/simplepie/trunk/compatibility_test/sp_compatibility_test.php
You probably don't need something that elaborate, but it's an interesting approach nonetheless.
I know it sucks, but ultimately a compatibility test in the core will make Vanilla more polished product and there will be fewer frustrated users who's first instinct will be to mistakenly blame the software.
And it's worth keeping in mind that Vanilla's requirements are a bit stricter than other comparable software out there. Take a look at the requirements for WordPress, which could not be easier to install:
http://wordpress.org/about/requirements/
Since Vanilla has more requirements, a compatibility test is really not such a bad idea.