#5831 closed defect (bug) (fixed)
Activation link - change from "?key=" to action variable
Reported by: | r-a-y | Owned by: | djpaul |
---|---|---|---|
Milestone: | 2.2 | Priority: | normal |
Severity: | normal | Version: | 1.5 |
Component: | Members | Keywords: | has-patch needs-testing |
Cc: |
Description
Referenced in a support forum thread:
http://jrfom.com/2014/08/11/buddypress-and-lighttpd/
This might be causing a lot of the activation email issues that we've been having.
Let's switch from using this:
example.com/activate/?key=XXX
to:
example.com/activate/XXX/
or:
example.com/activate/key/xxx/
While keeping the older $_GET
method for backward compatiblity.
Attachments (1)
Change History (17)
#2
@
10 years ago
I've just seen http://bloggingatmidnight.wordpress.com/2014/08/26/topic-new-user-invalid-activation-key-the-solution-%c2%b7-buddypress-org/ which is interesting to look at.
#3
@
10 years ago
I think ?key
hits spam / malware email filters a certain way. Both the WordPress ticket and the bloggingatmidnight post kind of confirm this.
We just need some testers once this ticket has a patch :)
#4
@
10 years ago
- Keywords has-patch needs-testing added; needs-patch removed
01.patch
changes the activation link to example.com/activate/XXX/
and also supports activating with older links (example.com/activate/?key=XXX
).
Needs testing for those that have had activation email problems in the past.
#5
@
10 years ago
Patch looks OK, we need to figure out how to create users in the unit tests that aren't automatically activated so we can test this.
#6
@
10 years ago
Upon consideration, this would be more of an integration test, especially now we have BP_Signups class, so I'm not going to worry about that.
#7
@
10 years ago
- Owner set to djpaul
- Resolution set to fixed
- Status changed from new to closed
In 9109:
#8
@
10 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
This is certainly going to break backwards compatibility for anyone checking the $_GET on their own.
Can we post something on BP Devel? I think we should encapsulate the key getting logic in a function to direct people to; if our new approach doesn't fix the issue (or breaks again years from now) the function gives us a way to change the innards without breaking changes again.
#9
@
10 years ago
I've just experienced a host having a spam filter installed that follows the external validation link in the outbound email, activating the users accounts always automatically rendering the activation link useless...
https://buddypress.trac.wordpress.org/ticket/6049
Am happy to help how i can :D
#11
@
10 years ago
This is certainly going to break backwards compatibility for anyone checking the $_GET on their own.
If plugins were doing checks for the key on their own, wouldn't the plugin need to remove how BP does its activation process with:
remove_action( 'bp_screens', 'bp_core_screen_activation' );
I think we should encapsulate the key getting logic in a function to direct people to
Sure, I think that's fair.
#13
@
10 years ago
vimes1984 - Your comments should be left in #6049. This is a slightly, different issue.
I've tried the IRC but it seems pretty dead...
We now use Slack instead of IRC. Check out this post for more info on how to get on Slack:
https://bpdevel.wordpress.com/2014/10/28/were-going-to-move-our/
#14
@
10 years ago
jjj - Have you read comment:11?
I don't see a way how a dev checks the old $_GET['key']
and adds their own implementation without getting rid of the existing activation screen.
Here's the old code for reference:
https://buddypress.trac.wordpress.org/browser/tags/2.1.1/src/bp-members/bp-members-screens.php#L214
If there are problems with this implementation, can you let us know?
I'm going to leave this ticket open during beta.
Sounds fine to me.
See also https://core.trac.wordpress.org/ticket/25350