Im sorry, we do not have you listed as an authorized user of this plugin. From where was your copy of it obtained?

It was purchase by the lead developer at our firm. I don’t have his username.

No problem. Please either have them log in and confirm the purchase on this comment thread, or request the purchase code from them and send it to us via the author contact form here

sent

Thank you. We have received your email, but it does not contain the purchase code. The purchase code can be obtained by having the purchasing user click on the “download” link under the item on their downloads page. There it will be available as a .pdf or .txt file.

Thank you, we have received your valid purchase code. Please check with your lead developer that your WordPress installation has sufficient write permissions to its own directory for initial set up. If you have various restrictions in place disallowing this you can enable them again after setup is complete.

Can you tell me exactly what to open up, permissions wise? I saw a post that said it might be an issue with the includes folder needing to be opened. We did that and it still did not generate or save a key.

Do you have higher folder level restrictions in place?

You can always generate your website key manually if needed. If you cannot ascertain the server permissions blocking the key generation please e-mail us again and we will send you instructions for manual key generation.

These manual generation instructions have just been added to the next version of the plugin as well.

Hello,

Encryption verification mode is for viewing your entry data as the raw encrypted database values ..if it is encrypted.

Is the data for the entries you are viewing encrypted? It will not show unencrypted data as if it were encrypted, It only reveals actual encrypted values.

If you are looking to see a sample of an encrypted value, the “DATABASE STORED DATA” field in the “ENCRYPTION TEST” is a sample of encrypted data.

If you need to encrypt old entries that were submitted before encryption was turned on for the fields you can use the “Encrypt/Decrypt Form Entries” tool at the bottom of the settings page to accomplish this. Please follow all instructions on the tool carefully.

The sample of an encrypted value does show encrypted data. I submitted a new form entry after the plugin was activated and configured, however, the new form submissions are not encrypted in the database. What else might I look for? Everything has green checks by it and it does say that encryption is on from the plugin settings screen.

Ok we would be glad to help out with that.

First please be sure to read and follow full instructions for each option on encrypt/decrypt tool. Most common reason for that behavior is a missing option setting that is required.

To run basic batch form decryption you need to enter “decrypt” into the encrypt / decrypt option on top, and specify the form to decrypt. You also need to enter a number in the “max entries per run” option if you are not specifying certain entry numbers for that form. Otherwise it defaults to running 0 as a safety measure. You can just set it at 200 to run up to 200 entries per run. If you have more entries than that do the next run with the “start offset” option beginning at 200. ..next run would be at 400. ..etc.

You do the same thing to encrypt after updating but change the encrypt/decrypt setting to “encrypt”

Yea…..it “is” the small things isn’t it? SMH LOL Thanks for your help!

No problem, glad to be of assistance

Hey….sorry. One more thing. Why wouldn’t it save the website key?

It’s a specially separately generated key. It should regenerate the same key when you save unless you changed it from the unique auto one for some reason, but when you upgrade ,be sure to follow the readme file upgrade instructions. There’s one instruction in there that covers this issue.

Nothing was changed, I had saved the webkey from previous generations, but it gives me the “Website Key: NO “Save settings to generate key” This site promoted from a dev server, and when I upgraded the dev server, everything went fine. Everything else with the plugin works just fine, except saving the website key.

Check out the “Native search permission” option on the settings page. That will allow specified users to also retrieve encrypted values in their searches.

Without using that, standard searches will sometimes return encrypted values if the searching user has decrypted view permissions for that field data but standard searches are very unreliable do to the nature of encryption. Because if you search for “bob” and “bob” is encrypted as ”!?75457fhcb)(!!” ..there’s no “bob” to find.

Hope this helps resolve your search issues

Well, If it were myself I would log into the SQL database and show them the direct encrypted data.

On the wordpress end its not built to necessarily show the direct encrypted data within the admin interface, but you could always just deactivate the plugin for a second and view the entries page, or a single entry. You’ll see all the encrypted data there instead of the pretty restricted display. .. although the plugin would be down during that time if the site is live.

Perhaps the next version should have an option to simply pass the full encrypted data instead of the restricted displays. However, it wouldn’t be recommended to leave it on.

ok so i installed the plugin on a staging version of the same site (because i dont have access to the database of the live site). i made a submission on the form but in the database i’m not seeing the data as being encrypted. on the encryption settings once all the requirements are checked green, all forms should then be encrypted right? if there’s more i need to do please advise.

Please read the full instructions at the top on the settings options page to get started.

This plugin does not globally encrypt all data on all forms. You need to set the fields requiring encryption to be encrypted within the forms edit page using the fields advance tab. Once plugin setup is complete and encryption is turned on for a given form field, that forms submissions will have that fields data encrypted in the database.

Thank you for the purchase John.

Lets get you up and running here.

It would appear that you yourself do not have access to the encrypted field data. You likely have the “Encrypted Field Restricted Display” and “Hide Field Value Restricted Display” on the options page left empty which means that users without access with be returned nothing/blank for encrypted and/or hidden field data. ..sometimes this is useful, but most likely you’ll want to put something in there so that users without access can tell if theres even any data there or not and wether its encrypted or just hidden. ..all they will see is whatever you type into that restricted display.. so something like “XXXXX” for encrypted data and “information hidden” for hidden data would let you easily distinguish between the two.

If you are the only admin who needs access to that field data, you can just enter “lockdown” in the User Lockout List on the options page. Then just put your username into the User Access List directly below that and save changes.

You should be able to see ALL encrypted and hidden field data in the entries lists and detail pages then aside from any user owned fields that you did not submit. ..this goes for export/reporting as well. if you have no access you cant export it, but you would see the restricted display instead. if you have access it will display as readable in your exports.

once you have something in the restricted displays, and the User lockout list set to “lockdown” you can be sure its working by just removing your name from the “User Access List”, and you’ll start seeing the restricted displays for any encrypted or hidden fields instead of nothing. the encryption test on the option page is also very reliable indicator.

If you really wanted to see the encryption in action and you can afford to do this in your working environment just disable the plugin for a second and view the entry data again. That would show you the full encryption strings for encrypted field data. ..or you could play with the developers tool “Encrypted Merge Tags” in the options page and put custom encrypted merge tags into the forms confirmations to see the full strings show up through merge tag output.

Hopefully this helps get you up and running

Well, offhand these sound more like configuration issues.

Your second issue with the merge tag info is likely not a bug but working as designed. Do you have anything set to display for the encrypted restricted display? If not you should really put something in there like XXX or whatever so that you can tell whether something actually simply isn’t showing up or the user triggering the display or action just does not have access to that data. Only users with access to the encrypted or hidden data can send out unencrypted merge tag data by simply turning the merge tag filter off. If some random customer thats not logged in r has no admin access to that data fills out the form it will always send out the restricted display for the data they have no access to in merge tags.

If you are trying to send out the unencrypted data for fields through merge tags all the time the way to do this would be to turn the merge tag filter back on, and use the tool for that called {gfef_decrypt_FIELD ID}

Decrypted Merge Tags

instructions are on that tool if thats what you are looking to do.

Ill get back on the first issue in one sec

..For the Native Search functionality, please first be sure that the usernames that you want to have this ability are listed as instructed in the

User/Role Encrypted Field Native Search Permission

option on the settings page.

This option needs to be locked down to admin control because otherwise unauthorized users can just search for specific strings and they would know that any entry returned that is encrypted for say a select or radio button where that is an option would have that encrypted data revealed since it was returned even though its not displayed as readable for them.

Also, we would like to make sure you know that the listed functionality of the Native Search is limited to “exact terms”. You cannot search for partial content of field data. so if a field contains “this field data is encrypted” , and you only search for “encrypted” .. it would not be returned in the search. you would have to search for “this field data is encrypted” and it would be returned. You can use the “contains” or the “is” to search for the data, but you have to search for the complete data as entered.

So finding partial strings in a paragraph or sentence or word that was entered is not an option.

The search however is useful for looking up an entry by ..say a first name, or a SSN or a check/order number , DOB, city, zip, or anything else that would be a single word entry where you can simply search for the exact word/data entered.

Note: ..currently the search is also case sensitive. So it really does have to be exact. In the next version we will likely add into the Native Search so that it simply automatically also tries finding the search term with the first letter capitalized of each word and all letters in caps and all letters in lower case as well for ease of use.

We’ve also just updated the language on the merge tag filter bypass option to clarify its purpose and point to the decrypted merge tag tool for the next version. It was a little unclear as to what it would do in the current verbiage.

That’s a good question. Originally they were presenting some issues with functionality, but the plan is to revisit them to attempt to suss it out when possible. So while it’s hopefully a possibility, it’s not a given on any current development roadmap.

as far as encrypting previous form entries, if you have entered “0” for max entries per run , then 0 entries will be processed. You need to enter a number between 1-200 to process the given amount of entries for the specified form.

As far as the form submission field data being stored as plain text, have you turned on encryption for any fields on the form? Please refer to the “Full Instructions” -> “SETUP” section at the top of the settings page to make sure you have turned encryption on for any fields. This would be done per field while editing the form in the each fields advanced tab under “Encryption”.

OK gotcha. The instructions are very long so I tried to skim to find what I needed rather than spend quite a while reading everything. But I get it now. I can confirm everything is encrypted and it’s working….

However, one feature I thought would be possible is being able to search forms to find a submission by name, etc. It doesn’t seem like you can search any encrypted fields, is this correct? So search function does not work?

Excellent! Im glad you are up and running

Limited search functionality works in all of our testing. It generally returns most or many of the entries with the given field search data but can be returning differentiating partial results. We are looking into how to improve this, but currently we recommend using non encrypted fields or other criteria such as date range to find specific entries.

..item details list "some search and order functionality is retained" .   I have now changed this description to be more specific as to the exact expected behavior.

OK. Bummer. In our implementation, we really need to encrypt the customer’s name. But we also need to be able to search submitted forms by customer name to bring up the record. We are using the standard name field. But searching for names does not work once encrypted – it brings up no results.

hmm, It might be of use to associate the names with a secondary field or data such as entry ID. If you supply the customer with the given entry ID via notification and confirmation or other generic token that is unencrypted you can always look it up by that.

..Also try using the “contains” search rather than the “is” search criteria.

..and try using the “any form field” rather than “name” specifically.

In all of our extensive testing we can generally return the desired entries while searching based on encrypted field data, but it is not considered reliable ..be sure that the user running the search has view permissions to the field you are searching. You cant search it if you don’t have view access.

Ill push this forward to be looked into for any chance of improvement sooner than later.

I did try “contains” and “any form field” which is the default but no luck. I am the user that installed it so I have to imagine I have full permissions as I’m able to set everything and view entries by browsing. Just the search doesn’t bring any results. Looking forward to continued improvement!

OK Ive looked over the Gravity forms search functions again and there really isn’t any visible solid or viable way to insert pure search right now without hacking GF core. In light of this current situation, we added a new feature to the settings page in the encryption check section which let you see the encrypted strings for custom input. You can enter what you want to search for and save ..then just copy the encrypted string and search with it on the forms entries page for reliable GF core search functionality. This could be possibly moved to the entries page itself in the future to make it more user friendly, but for now given that it reveals encryption strings allowing for pattern based decryption we’ve left it in the settings page. It’s not completely ideal yet, but for now it allows reliable search when you need it.

Version 2.9.1 * Added “Search Data” option to setting screen to allow for searching entry field data based on stored encrypted strings. ..This allows for stable search of encryoted fields.

..this version should be submitted later today for approval togo live.

Thanks for the effort….the search needs to be very easy, it’s for my client and they would not go through the trouble of copying encryption strings. It’s too much work. For now we have left the name field unencrypted because that seems to be the only way to search by name.

I agree about the search needing to be much easier. Although we’ve released the temporary solution we believe we have determined a way to possibly integrate it much better in a near future version. Once we’ve thoroughly reviewed and tested , if it is viable you should see it before too long. If not we would like to at least make the temporary process less cumbersome

OK, Im happy to report that the next version will include a reliable naitive search of encrypted field data. No extra steps needed. just type in what your looking for and gravity forms regular search will look just like it always does, only with the standard reliability of its search. This functionality is handed out to users or roles in the settings screen because without that unauthorized users could potentially find out what data is based on search criteria and results.

We are looking into other functionality suggestions and possibilities for this version before release as well, but it should be out pretty soon.

Ok We’ll need a little clarification on what you’re doing. Are you trying to use the “decrypted merge tags” feature to have fields that are encrypted output their normal readable values in merge tag output for a confirmation?

Hi, I am using the gravity forms to allow the user to enter information in fields – just like normal, pretty standard actually. What complicates things is that we are sending the data entered in the fields into our system using a redirect for the confirmation. The redirect is appending data to the URL using “Pass Field Data Via Query String”. The data that is passed in the URL needs to be the encrypted version. I cant seem to get it to work at all. When I enable the encryption, the value is passed to the URL as blank. Weird thing is, when I look at the entries, in Gravity Forms, they are not encrypted. All settings in the plugin are Green and reported as OK or passed. So, just not sure if this plugin is capable of doing what i need or not.

..Well let’s take a look at what could be happening here.

1 the data your looking at in entries is likely not showing up as encrypted scrambly looking because you have permission to view it. there currently is no option to view the direct scrambled data like on the settings page, because it wouldn’t serve any clear purpose and eats up screen space for displays. You either get the human readable decrypted data, a masked version of it, or a restricted display. but ..if you put your user name into the user lockout list and then try viewing an entry it will give you the restricted display for either hidden or encrypted data. if that restricted display setting is empty, it will show nothing.

2 the data passed via query string is likely blank because you don’t have anything entered into the encrypted restricted display, and the merge tag filter is on by default. .. the query string data is actually pulled using the merge tag generation .. which is odd, but that’s how they are generated. if you put something into the encrypted restricted display it will likely then get passed to your query string variables because the merge tag filter replaces any encrypted /hidden fields with their respective restricted displays.

3 clarification is needed: are you looking to actually pass the actual scrambled encrypted data into your system via the query string? .. this would look like the encrypted data in the encryption test on the settings page. ..and how would you unencrypt it in your other system? One would think it would be useless without a decryption method on the other side. .. or do you want the UNencrypted and human readable output of the same field to be passed to the query string while the data in your WP database remains encrypted?

Hi again…

Thanks for your quick responses. A++ for support! To answer question 3, yes, I am looking to pass the scrambled, or encrypted values in the URL. We have a web programmer who is hoping to use the key string to unscramble the strings values. Our thinking is that, submitting unscrambled strings in a URL is unsafe. our page and website is behind an SSL and is accessed on an HTTP, maybe this is good enough? Not sure. This is why we were hoping to have the scrambled strings passed to the URL. Maybe this is not common practice?