View Issue Detail

ID	Project	Category	Submitted / Last Updated
01262	UserSpice	Plugins	2021-06-14 14:34:57 / 2022-05-13 10:43:50
Reported	IPEG Developer	Assigned To	Unassigned
Priority	none	Reported	5.2.5
Status	closed	Resolution Version and Commit
Summary	UserInfo form data is being updated during cloaking with the UserInfo plugin active
Description	As we discussed in the #PluginSupport server on discord, when the UserInfo plugin is active, the information in the users_form for the user we&#039;re cloaking FROM is being written into the user_form for the user we&#039;re cloaking TO. Any form update is probably unwanted during cloaking. To stop the form from updating, I&#039;ve modified the UserInfo plugin to stop the form update if the &#039;cloak&#039; var is present in the POST body. BangingHeads also suggested checking for &#039;delete&#039; as well. I&#039;ve modified the user_settings_post.php file in the UsersInfo plugin to the following. You may do this differently if you see a better, way. &lt;?php if(count(get_included_files()) ==1) die(); //Direct Access Not Permitted global $user,$userId,$usFormUpdate,$form_valid; $usFormUpdate = $user-&gt;data()-&gt;id; $check = $db-&gt;query(&quot;SELECT id FROM users_form&quot;)-&gt;count(); if($check &gt; 0){ if(pluginActive(&quot;forms&quot;,true)){ if(!empty($_POST)){ $isCloaking = array_key_exists(&#039;cloak&#039;,$_POST) ? $_POST[&#039;cloak&#039;] &gt; 0 : false; if(!$isCloaking) { $response = preProcessForm(); if($response[&#039;form_valid&#039;] == true){ //do something here after the form has been validated postProcessForm($response,[&#039;update&#039;=&gt;$usFormUpdate]); $form_valid=TRUE; }else{ } } } } } alternatively, BangingHeads suggested something like this which might be more readable and also includes the &#039;delete&#039; var. &lt;?php if(count(get_included_files()) ==1) die(); //Direct Access Not Permitted global $user,$userId,$usFormUpdate,$form_valid; $usFormUpdate = $user-&gt;data()-&gt;id; $check = $db-&gt;query(&quot;SELECT id FROM users_form&quot;)-&gt;count(); if($check &gt; 0){ if(pluginActive(&quot;forms&quot;,true)){ if(!empty($_POST)){ if(isset($_POST[&#039;delete&#039;]) \|\| isset($_POST[&#039;cloak&#039;])) return; // Added this line to stop the updating. This seems to be a simpler way to do the checking $response = preProcessForm(); if($response[&#039;form_valid&#039;] == true){ //do something here after the form has been validated postProcessForm($response,[&#039;update&#039;=&gt;$usFormUpdate]); $form_valid=TRUE; }else{ } } } }

November 2021

That's a fair assumption Brandin. I had thought about it and my thought was that I'm probably not updating a user as I'm cloaking into that user, however, I also agree with your assortation that user updating should not be blocked since you are clicking an 'update' button in order to cloak, therefore, one would expect that the update would actually take place. So, I'm convinced! You guys do what you need to!
November 2021

I would say if a user is being cloaked into, we would still allow changes, since it may be a form change that needs to be reproduced. However, we should resolve the issue that the wrong data is being displayed/written, but this action should not be prevented.
November 2021

I think this is more of a chrome autofill/password manager issue. We'll investigate
May 2022

I'm guessing this is probably happening more on localhost where you have multiple installs with the same session id? I can't duplicate this issue. I am sticking with my guess it's a password manager or some other browser issue