Support Forum
Has anyone else reported that when guests create a thread reply, the guest name and e-mail address is sometimes pre-filled with the previous user's information? By previous user, I mean the person who last wrote in the thread. I haven't investigated the code around this yet; just want to see whether it's been reported by others yet.
yes it is... why?
you can control this... on forum - options - member settings, you can choose to remember guests with a cookie or not... if a cookie for that guest is found, it will pre fill...
Visit Cruise Talk Central and Mr Papa's World
Actually upon further testing I'm finding that the behavior is pre-filling the user information from the creator of the thread (not the latest thread reply; it was simply a coincidence in the first reported case that the latest thread reply had been from the thread creator).
This isn't the expected "remember" behavior, which should pre-fill only with the particular visitor's information. The reported bad behavior is of course an issue in that everyone can see the thread creators' e-mail addresses. This doesn't seem to be related to the cookie setting.
more testing might be needed, but I cannot seem to duplicate it...
if I turn the cookie off, it will not prefill anything...
with cookie on, when I posted as guest, it got my last post as guest, but not the first post... but you might have multiple cookies on your machine from each guest post... so it might grab the first one it finds vs the last one...
can you clear your cookies... post as guest... clear cookies... post as new guest... try posting again and see what you get? think it will be the second guest poster... but good data to have...
Visit Cruise Talk Central and Mr Papa's World
With more testing, it looks like it pre-fills with the last guest in the thread, which is sometimes the first post, sometimes the last post, and sometimes somewhere in between And you won't see this behavior if you are a recurring guest, because you'll have cookie data.
It appears to be related to this code from forum/content/forms/sp-form-post.php (and possibly similar with the add topic form):
global $sfvars, $spThisUser, $spThisTopic, $sfglobals;
extract($a, EXTR_SKIP);
# Check for a failure package in case this is a redirect
$f = sp_get_transient(1, true);
if (isset($f['guestname']) ? $guestnameval = esc_attr(stripslashes($f['guestname'])) : $guestnameval = $spThisUser->guest_name);
if (isset($f['guestemail']) ? $guestemailval = esc_attr(stripslashes($f['guestemail'])) : $guestemailval = $spThisUser->guest_email);
Specifically, if there is no value in the cookie, it defaults to the value in $spThisUser, which for the guest_name and guest_email values at least, have been set to a user in the thread.
This is not quite what that code is doing.. and this could be the source of your issue.
It checks for a transient record in the options table. If, for any reason, a post fails validation then a transient record is created so that when the page refreshes an appropriate message can be displayed and the various fields on the post form re-filled. If that does not exist then it assumes this to be a new post and uses the values stored in the $spThisuser object which always refers to the current user of the system. It is the $spThisUser object that interrogates the cookie.
Now I am not really a fan of WP transient processing. You give it a timeout after which it is supposedly no longer available but it really does not always work that well. This particular transient is created with a key of the IP address of the user and a timeout value of 900 seconds. So - a possible scenario for what you are seeing is that if you are testing with various user accounts and as a guest you may have had a transient created using your IP address that is fooling the above code into thinking that you have had a post failure. And it will use the credentials of the user that suffered the failure.
We do send the 'kill' transient when we look for it but as I say - Wp transient processing can be a little shaky which is why I am not a big fan though most f the time it mainly works.
So - could this perhaps be a part of what you are witnessing?
You can dump the contents of $spThisUser of course to see what is getting set from the guest cookies...
YELLOW
SWORDFISH
|
I don't think it's the transient records or cookies. That appears to be working fine.
It has been reported by several users in the live environment, and isn't due to repeated posting of the same guest user trying to use different names and e-mail addresses (in other words, it's not just me pretending to post as multiple people for testing purposes).
If I replace this:
if (isset($f['guestemail']) ? $guestemailval = esc_attr(stripslashes($f['guestemail'])) : $guestemailval = $spThisUser->guest_email);
with this
if (isset($f['guestemail']) ? $guestemailval = esc_attr(stripslashes($f['guestemail'])) : $guestemailval = '');
Then the issue is solved (at least in a band-aid way) because we don't fall back to $spThisUser values.
This is possibly traced back to the in-memory caching in sp-api/sp-api-class-user.php, which populates $spThisUser several times in a page load:
function sp_get_user($userid=0, $current=false) { global $USERS; if(!array_key_exists($userid, $USERS)) { $USERS[$userid] = new spUser($userid, $current); } return $USERS[$userid]; }
If you have a guest post in a thread, it fills the $USERS global with ID 0, and I think that's how it ends up pre-populating the guest name and e-mail fields with someone else's information. (See also line 287 in forum/content/classes/sp-topic-view-class.php)
$t[$tidx]->posts[$pidx]->user = sp_get_user($r->user_id);
This only happens on posts since 5.x, because user_id in the wp_sfposts table now gets ID = 0 for guest posts while this used to be NULL.
Let me know if you want me to show a live example and I'll send you a PM with some instructions. (I applied the band-aid patch on my live install to prevent people from abusing the e-mail address leaks.)
Oh good catch. Now I really DO feel stupid !
I will open up a ticket immediately and get this fixed up. It might be an easy fix too although I will have to check the logic. But if good then all we will need to do is re-interrogate the cookie for any user_id set to zero...
Amazed this hasn't been discovered by anyone else. Thanks for the find.
YELLOW
SWORDFISH
|
1 Guest(s)