Juser and Upsert plugin

[Sadler]

Hi,

I have a form which runs a juser plugin when a record is edited to create a new user in the system. I am running an upsert plugin after that to copy the details to a new table.
The upsert plugin is working fine but when I look at the data I am getting the plain text version of the password being inserted into the table rather than the encrypted password.

I am using the starting field name (e.g. {my_Form__my_Field}) as the data for the upsert so I guess I need to use another variable name to access the encrypted password, anyone have any ideas on how to access this data rather than the field value?

Carl

 

[cheesegrits]

Ah, OK, I think I see why that's happening. It'd be a bit tedious to set up a test case here, so can you try this fix for me ...

In ./plugins/fabrik_form/juser/juser.php, around line 622, at the end of the onBeforeStore() method, just before we 'return true', try adding ...

$formModel->formDataWithTableName[$this->passwordfield] = $data['password'];
$formModel->formDataWithTableName[$this->passwordfield . '_raw'] = $data['password'];

The upsert plugin uses that formDataWithTableName[] array, rather than the more often used formData[], because it runs after we've written data out to the tables, and part of that process removes the tablename___ prefix from the formData[] keys. So we maintain a separate data array for use after data has been stored, when we need to index it by 'full' element name.

And although I think the password field in the formData[] array gets changed to the encrypted value, the formDataWithTableName[] doesn't.

-- hugh

 

[Sadler]

Hi Hugh,

updated the juser.php. Still gives me the encrypted data in the original table and the unencrypted data in the target table, attached is modfied juser.php just in case I have it wrong - it is not throwing any errors.

Carl

 

[cheesegrits]

Ah, I see the problem with that, we overwrite formDataWithTableName with formData after that plugin hook is run.

One thing that was puzzling me is how you were getting the encrypted password at all, as I couldn't see anything in the juser code which modifies the form data after creating the user.

So I figure you must be using the password element plugin? Which encrypts as part of it's storeDatabaseFormat() method.

-- hugh

 

[Sadler]

Yep,
the form has a password element on it, when I look at the original record (using Navicat) the password is stored encrypted but when I look at the record created by the upsert plugin it is clear text.

The upsert target table is the one used by registered users to edit/update their data which includes a juser plugin so I wanted to avoid anyone updating their details and screwing up their password.

That being said it does not seem to be an issue as yet, though usually when I think that I then get flooded with angry calls and emails!

Carl

 

[cheesegrits]

I've been looking at this for a while, and there isn't really a good way of doing this.

I can put a little hack in place, but here's the issue ...

We have to retain the clear text value of password elements, up till the point we write it to the database, because people need it for things like sending passwords in signup emails (yes, I know sending cleartext passwords in email sucks, but people still do it).

And at the point where we do the encryption, in storeDatabaseFormat(), we no longer have a concept of "repeat count" (critical for data in joined / repeated groups) as we are far enough through the processing flow that we are now writing individual rows to the database, and it's just a case of inserting or updating a row.

So although technically i could poke the encrypted value back into the formDataWithTableName array that upsert uses, it wouldn't work for repeat data (which are arrays indexes by repeat count), it'd just be a kind of hacky attempt at setting it for anything that exists on the main form / table.

I'm also worried about backward compat for people that have rolled their own code that runs onAfterProcess, who may well be expecting the clear text value (for instance if they are doing things like adding the same user to some other web service, like adding Magento users, etc).

So I'm tempted to just leave this be for now, you let me know if it becomes a problem, and we'll figure something out that won't break backward compat.

-- hugh

 

[Sadler]

Sounds reasonable, as I said it appears to be a non-issue so if it becomes an issue I will let you know. Will close the thread.

Thanks

Carl