I am having the same problem with my web site, and I have figured out why the problem happens, and why the problem is intermittent…
Here is the problem: a user registers for a BuddyPress account, receives the activation email, follows the link in the activation email, and gets the “Invalid activation key” error. Yet, their account really *is* activated, and they can log in and use their account. A different user does exactly the same thing, and everything works great for them – they get the “Account Successfully Activated” page.
*Some* users have this problem, most don’t. The ones that do? They seem to have “Blue Coat K-9 Web Protection” software installed on their computers. This is software that is generally installed by parents to keep children from viewing inappropriate content on the internet. When the user follows the “activation” link, K-9 (running on the user’s computer) sends the URL to Blue Coat’s servers, which hit the URL (causing the account activation to succeed). Blue Coat’s servers analyse the “account activation succeeded” response, decides that web page is “kid friendly”, and then tells the user’s computer that that URL is “safe”. The user’s browser is then allowed to hit the URL, but, since that BuddyPress account has already been activated (by Blue Coat’s servers), the user sees the “Invalid activation key” error message, because we tried to activate the BuddyPress account twice.
Assuming that Blue Coat’s K-9 software is not the only “internet safety” software that acts in this way, it might be a good idea to change the BuddyPress “account activation” system to display an “activation succeeded” message when a user (or their “internet safety” software) tries to activate a BuddyPress account more than once.
Here are more details, in case if anybody is interested…
I instrumented my site’s “index.php” and my site’s “public_html\wp-content\plugins\buddypress\bp-templates\bp-legacy\buddypress\members\activate.php” with code that logs tons of stuff, including the IP address of the user. This led to the following discovery…
When a non-K-9 user follows the “activation” link, “index.php” gets hit (from their computer’s IP address), which invokes the fore-mentioned “activate.php”, which activates the account and emits the “activation successful” web page, and all is well. One web request happened, as demonstrated by “$_SERVER[‘UNIQUE_ID’]”.
When a K-9 user follows the “activation” URL, however, a MUCH different situation occurs, which involves four separate web requests. The first two requests come from an IP address that is registered to Blue Coat Systems / Symantec Corporation, the makers of the K-9 Internet Protection software. The second two requests come from the user’s computer…
* Web request #1 – Blue Coat’s computer hits “index.php” with the activation URL’s ending slash missing.
* Web request #2 – Blue Coat’s computer hits “index.php” again, with the correct activation URL this time. This invokes lots of PHP code (on my server), which eventually results in “activate.php” running and the account activation succeeding. The reply (the “account activation succeeded” web page) is delivered to Blue Coat’s servers, who analyses it and decide that the web page is “kid friendly”, so it tells K-9 (running on the user’s computer) that it’s OK to show that page.
* Web request #3 – The user’s computer finally hits “index.php”, in order to activate the account.
* Web request #4 – The user’s computer hits “index.php” again, with the registration key removed from the end of the URL this time. This invokes lots of misc PHP code, which eventually results in “activate.php” running and failing this time, because the activation has already happened (back in web request #2, which Blue Coat made, in order to determine if that web page is “kid friendly” or not).
I have no idea why the user’s computer (in #3 and #4) make two requests instead of one. However, even if it made just one, it would still show the error message, because that’s the second time the BuddyPress account was activated.
– kcscience
