Currently it can immediately send the file to you as an notification email file attachment and then auto delete the file from the server for security. This leaves no need for encryption and allows the file to be sent in a notification as normally readable. This setup works well for most installations because it both handles storage security concerns, and keeps the website tidy from form file upload bloat.

We’re are looking at possible file encryption for future versions, but theres no definite roadmap for it at this point. However it is seriously being considered. If it makes the docket for development I’ll post additionally with details then.

ok thanks for the reply. I think i can do without it for a while but perhaps when i need it, we can work $omething out. I will still buy this plugin. Its been needed a long time. Thanks.

No problem. We do see the value in the idea, and intend to look into potentially adding this functionality asap but its a particularly busy holiday season right now. Hopefully soon after when things die down it can be given a fair shake.

i just installed this and i have a couple questions…

1. Any suggestion in the number of characters for server key and password. Im guessing the longer/more complex the better or is there a optimal length you recommend.

2. Also, any possibility you can add User ROLES to the permission access instead of username? I hope to use this with Gravity view where members of a particular group will have access and then Gravity View will further restrict access to a single user.

We recommend just using the auto generated website key, Its uniquely generated from your specific Wordpress installations config and isn’t some default that everybody has on install, Its the right length and complexity and very private and unique so its good to go right out of the gate. Using the default also will regenerate the same website key if your site crashes or something and you didn’t write it down.. assuming you recover the same install and don’t reinstall Wordpress that is. I wouldn’t change it unless you have to.

For the password you can use any permitted character length you want. It gets converted behind the scenes to a reasonably long and scrambled up pass key no matter if you just use 1 charachter or 32. the actual length and complexity of the functioning pass key is always the same. however, out of good practise you might want to use something at least 8-16 charachters long in a unpredictable sequence. .. or just use the full 32 I think it takes offhand ..ASCII chars only

..User Role Permission is likely coming but potential implementation is still being thought through. There’s many different permission layers already and it has to be able to weave into them at a reasonable point likely giving higher priority to more specific permissions.

We certainly wouldn’t remove the username functionality, but roles would be added in addition.

Current thought is that role based permission would likely be only globally applied through settings page underneath user level permission so that specific user permission would override roles allowing you to set say only a certain role for access, but also this other user over here who isn’t of that role.

..Any input as to how that might be applied differently or better?

i dont know. in the end, my use case probably wouldnt work with Username permissions. I would probably just have to allow all (which would sorta reduce the effectiveness of encryption) and narrow down the view using Gravity View. Let me try to explain what i want to accomplish.

There is a medical practice that has x number of providers and receptionists. I am creating on online form for client registration that asks numerous medical history questions. One of the fields is a PROVIDER name field which is dynamically populated using a function that queries all roles that equal PROVIDER. My desire is that when a PROVIDER logs in, they can see a list (using GRAVITY VIEW – which i havent bought yet) of ONLY the CLIENTS that are assigned to them from the PROVIDER field. Gravity View supposedly has the capability to configure allowable views based on a username if the field is included in the VIEW. I figure i can instruct GRAVITY VIEW to only display certain fields of interest to the allowed PROVIDER. Also, the RECEPTIONIST role would have access to only certain fields that were relevant for them. So, my thought was, if the field (or even the entire form – as you suggest – i suppose) was protected by a user role, the Gravity View permission would further narrow down what entries would be displayed. Does that make sense??

Do you have (or plan to have) a site/forum for this and other types of discussion. I imagine the popularity of this capability is going to explode when more users find out about it. This comment section is gonna get tough to follow… just my .02c

Thanks for your time on this.

It sounds like you would benefit from using role permissions on individual fields instead of globally applying them. That way you could just give permission to certain roles per individual fields. It could certainly be added in that way instead. Once we look further into it ..if its implemented we will try to make it as flexible and powerful as possible to work alongside the existing permissions. It sounds like just using individual field permissions might be the way to go.

Hopefully you can squeeze the Role Based permissions in soon.. Thanks. Happy Holiday.

..Its been implemented for next update already It’s individual field based and subject to being overridden by individual user permission blocking so you can exclude certain users of a role. Basically you can now add usernames or the slug for a role in the access list in the form editor. Hopefully it will stay i this config for release as its relatively easy to implement for the end user. But it needs to be tested and kicked around to make sure everything makes sense and functions smoothly still as well as other feature(s) added before update.

you’re amazing! i will try to get a test form going this week and provide as much feedback as possible.

Ok, ver 2.9 is submitted and should be approved for release soon. We’ll still look at file encryption asap but it will likely be a little longer development time for that if its something that can be implemented well.

2.9 is now available with ability to place a role’s slug into the fields user/role view permission setting. due to the way that setting works once you enter anything into it it excludes all other users unless they are listed in there either as an individual username, or have a role that is listed. The “user access list” still overrides the fields local permissions for access, and user lockout list still overrides to deny permissions globally.

Thanks for the update 2.9 with user roles. It seems to work well in my limited tests so far. I have also used Gravity View to display some entries and your plugin is working with that. I have not used the enhanced permissions capability of Gravity View yet but i will forward information to you when i get to it. I have a screenshot of a GUI modification suggestion if you are interested. Perhaps you have a general e-mail box i can send to. You should have access to my email address from my purchase. thanks again.

Currently the only way to do that is to turn off the merge tag filter..(use the bypass option) and trigger notifications or resend them with a user that has All view permissions for the form fields. The original idea was that sending sensitive data via email wasn’t a great idea so tools are all to block it from doing so, but there’s nothing in place to allow it if a user wants to.

...and we’ll, that’s not ok.

There should be an option, so there will be.. We will try to sneak it into version 2.5 which is coming out within apx a week. That version already has custom masking which allows for ADMIN defined preview masks (see plugin details page under features, or changelog at bottom of details page here on codecanyon) and using those you could just reveal the whole thing if you wanted anyway.

Will have to give it some additional thought as to how to best implement it but it really is a sensible feature to have.

Stay tuned for ver 2.5

Yes, you can still export Excel sheets as normal but it has to be done by a user that has access to all the fields you wish to export. If you don’t have access, you cant just export and Excel with stuff you don’t have access to, but if you have access, you can export anything you have access to. Basically if you put your user name in the user access list, you can get ALL fields data for whatever with one exception, ..if your using user owned fields and you didn’t submit the entry .. even as admin you wont have access. That’s the way they are designed. It’s for users own purposes and not really supposed to be admin accessed.

Of course the admin can always decrypt the entries and then re-encrypt them with user based ownership again, but if your giving the original user exclusivity.. .. should probably honor that ethically if it’s explicitly stated anywhere.

In regards to the Decryption Error , is it returning the original submitted data in the “decrypted data” section?

Thanks for your quick response. We currently only have one login (the admin) whose username I’ve placed in the following fields in the plugin’s settings: “Limit User View Permission Lists” and the “User Access List”. Additionally, I’ve placed the username in the individual permissions lists of the encrypted fields.

Unfortunately, when I view the list of form submissions (logged in as the admin), encrypted fields appear to be blank, and exporting the data to an excel sheet produces encrypted characters for the affected fields.

Additionally, the resulting email notification produces blank fields or encrypted characters for affected fields. Is there a way around that?

In regards to the Decryption Error, it is not returning the submitted data in the Decrypted Data test field. It just says “DECRYPTION ERROR! REVIEW SYSTEM CHECK ABOVE.”

Thanks again for all of your help!

first things first, try disabling other plugins or any custom code you have running that does anything with gravity forms entries or otherwise to see if there is a potential plugin conflict. If it runs fine after you disable a certain plugin or code, that would be the issue.

can you email me here: https://codecanyon.net/user/pluginowl with a temp login to check your plugin settings? Id love to get this resolved for you.

Your permissions are fine, but you dont need the admin name in the field view permissions. just put “lockdown” in the user lockout list and the admin name in the User access List.

Your system is just not actually decrypting data it would seem but we cant really tell whats going on without seeing it in action. Have you tried submitting any test form entries and checking if you can read the form data back through entry view?

please also check to be sure your 32 charachter long (if autogenerated) website key is being displayed by the website key option and your password is also being displayed. BOTH of these should ONLY use normal ASCII charachters. no weird charachters.

..another note, please look at the screenshots for this plugin and confirm that the “stored data” field in the encryption test on your site looks like the one in the picture of the encryption test. should be 2nd screenshot. if that doesn’t appear the same the data is not being properly encrypted, and therefore cannot be properly decrypted either. if you can screenshot your system check or just reply with what the information is it may be helpful as well.

Also please check your permissions on ALL this plugin’s files on your server , there’s only a few. Should be:

folders = 755 files = 644

Thanks for your response. I’ve sent you an email. I just received your last message a moment ago, so I’ll check that out as well. Thank you!

To follow up on your last message, the Stored Data field matches the screenshot, so that’s good. Confirmed file/folder permissions as well.

Problem solved. You had the encryption password override key active. When that’s on you can only view encrypted data that was encrypted with an old encryption password, but it does not use it to encrypt. It’s view only. Useful if you absolutely had to change the encryption password at some point. The current main encryption password ALWAYS does the encryption in combination with the website key. That way if your viewing data from an old key with the override and someone submits a form it doesn’t go under the override while you had it active. If you want to change the main encryption key to encrypt under, you can. But it shouldn’t ever need to be changed unless youve had some sort of login or database breach. Although given the new password option on the settings page , it could still be secure even after a login breach.

I deleted the override password and All your test entries are now properly being decrypted under the main password they are encrypted under. The encryption test works fine now too.

As for the encryption test, nice find. I’ll change it to use the override if it’s active in ver 2.5 coming out within a week or so as of now I’m guessing.

Don’t forget to delete my temp user !

Thanks for the purchase and glad we could help!

Gravity Forms Encrypted Fields is the only plugin out there that can do what it does. Currently it cannot display shortened field data in either form entry display or merge tag results, but it would be fairly easy to implement for the next version.

However, there is a security concern with allowing that sort of display as it could be turned on for fields that would simply give away their data if you shortened say ‘yes’ to only show the last 3 or 4 chars. That said, proper setup is in the hands of the ADMIN (just use input mask on field requiring field to be of certain length and char types so output mask functions all the time for given field) so the current thought is that this feature will likely find its way into ver 2.5 in some form.

The current thought is that the likely implementation will be the introduction of an ADMIN setting for output mask option which lets the ADMIN user specify how many beginning and/or end characters are displayed (in All views including merge tags) for a given forms encrypted/hidden fields(s). This could also be more user friendly and just done as a field advanced setting, but that would give any form editors power to just essentially decrypt and display whatever , so it should likely be kept to ADMIN settings page.

We do realize that most sites only have one ADMIN /user able to edit forms, but do you have any other input as to how this could be implemented without compromising security of data for sites that have multiple forms editors?

Thank you for the quick and detailed response. I fully agree that this should be an ADMIN only setting and of course the admin needs to take full responsibility for the security side of this. In most cases I think your proposed implementation would be a suitable solution and it would certainly suit our needs in this respect.

Ok

We’ll give it some more thought and try to implement it in the best way possible, but it will be a nice addition. Thanks for the input. Ver 2.3 should be submitted on Monday and if 2.whatever adds just this i would think it shouldn’t be past the week to submit it as well.

Yes. It was written with php5.6+ in mind and has been tested and NOT reported ANY errors running in php7.

That said, 5.5 and 5.4 will also likely run just fine now as well but are NOT supported since they are at end of life per PHP, and future functionality changes to this plugin may possibly only target 5.6+

Excellent. Waiting on a project approval but will purchase after. P.S. Are you in any way related to Owl Carousel?

Never heard of them, but owl check them out.

Is this plugin compatible with the User Registration Add-on for Gravity Forms? I’d like to do this… bit.ly/2ffZtJN

Yes. It is compatible as far as it will not interfere with the operation of that Add-on if used properly. However, They should not be used on the same fields within a form. Put simply, user registration fields should NOT be encrypted. It would be fine to collect some encrypted data from some fields on a form and register a user with other fields on a form, but because of the way that the add-on works and what it does you would really NOT want to encrypt user profile meta. That user registration data is placed directly into the WordPress user meta in the database and needs to be unencrypted so that WordPress core and other plugins and functions can access it as readable and do all the fancy stuff they do without needing to decrypt the information to do it. WordPress doesn’t pull the user meta through the gravity forms interface and so its just stays as encrypted data. The User Registration Add-on itself doesn’t pull through the gravity forms API to prepopulate the update form either, but also pulls directly through the standard WordPress user related functions, so if you encrypt the data, you’ll just keep getting encrypted data back for the user unless you view the registration form submission data through the Gravity Forms entry view interface. And that would make the users profile unable to be used for anything normal.

My end goal is to create custom fields for the user profile that aren’t used for Wordpress default functionality in any way. Just as a storage location associated with the user. These would be details like: Twitter Username [encrypted], Twitter password: [encrypted]

The wordpress site in question, the users would be shielded from the wp-admin dashboard at all times. They’d only see the data for those custom fields through Gravity forms on the front end of the website.

So I guess what I need is a way to encrypt only certain fields from the user’s profile.

If it helps, I can give you access to my staging site that I’ve been building up so you can see the use-case first hand.

sure if you’d like you can just send me an email with temp login info through my profile contact.

If you are saving the data through gravity forms to the actual wordpress user profile using the User registration add-on, how are you pulling it back through gravity forms? That data goes into the user-meta table. The user registration add-on then uses the Wordpress core way of retrieving user info to populate any user info forms in gravity forms for them though, so its not being pulled back through gravity forms entry view code to get decrypted. Although I assume that if you are using something like “gravity view” or custom code work to pull entry details for users own submissions and display it on the front end of your site I would think this would be much more possible.

Sent. Is it more clear what my goal is now?

Sorry, We have not received any e-mail as of yet.

on the right sidebar.

That’s where I submitted it. Then a little while later after I did the WP user “PluginOwl” logged in, and changed user settings. Hmm

Thank you for the purchase and we’re glad you are enjoying the plugin.

Regarding the user registration, if you are attempting to register users they have are NOT logged in while submitting the registration so a few things could be happening here. The decryption requires a logged in user and checks field permissions for that user, so if the registration plugin fires right after form submission and attempts to pull encrypted fields by that user to complete registration, that user is either not logged in yet or has no field permissions to what they just submitted. So any attempt to proccess that data through API by that users forms actions will return encrypted value or restricted display. I’d have to look at the plugin but if it pulls data outside the gravity forms API it would also not get decrypted value.

In terms of registering a user you may want to look at simply programmatically deleting the submission immediately after it’s submitted. User registration would happen first, then the submission is deleted.

You can always collect additional user info through different fields NOT used by the user registration plugin too. Those would be encryptable.

The beautiful thing about the plugin is that you can always not use encryption on fields that other plugins are trying to use in some way that causes permission or validation errors. So Yes, it’s compatible … but the user registration fields may need to stay unencrypted. You can always use hide field values though if your preventing some front end or admin display. Ver 2.0 (should be out soon after uploading is back up on codecanyon) has conditional/beta capability for decryption outside of ADMIN area as long as the plugin doing so pulls using API etc. Same would apply for payment fields or product type fields in a payment form. Card data isn’t saved anyway though.

Regarding the capitalization filter, if it’s firing after the data encryption it’s changing the encrypted day which is likely rendering it useless and unable to be decrypted. I’ll take a look at seeing if the encryption can be the last thing to run in that save data filter. In general you don’t want to change or alter encrypted data in any way because it can’t be decrypted properly then. You can likely use any hook which fires earlier than the save one to alter it before that stage though. I’ll take a look into this soon as well. For now I’d recommend not using it until we see what’s going on. Feel free to paste the code here so we can take a look to see how we can help.

UPDATE: ver. 2.3 simply changes priority’s for the hook actions being performed with the encryption, so hopefully your capitalization function, and other custom changing of submitted data may work just fine once the update is out. It looks to make the encryption the LAST possible thing before the data is saved to the DB letting the data be changed first as you are doing before its finally encrypted.

That’s great, thank you very much!

No problem! In the meantime you can try just changing your current functions execution priority.

Try changing the % sign number in your function to 9 from whatever it is now, its likely 10 or higher now. Then run a couple test form submissions with encryption. Hopefully that should do it.

add_filter(‘gform_save_field_value’, ‘your_function’, %, ?);

I took your suggestion in changing the priority of the filter, like so (not sure how to properly paste code here):

add_filter( ‘gform_save_field_value_20’, ‘uppercase_text’, 9, 3 );

function uppercase_text( $value, $entry, $field ) { }

if ( $field->get_input_type() == 'name' ) {
    $value = ucwords(strtolower( $value ));
}
if ( $field->get_input_type() == 'address' ) {
    $value = ucwords(strtolower( $value ));
}
return $value;

However, the filter still capitalizes the value only after it has been encrypted, as viewed in the database. Any thoughts on how you would otherwise change a value prior to encryption and saving to the DB?

Currently there’s no functionality like this built in. We have been looking at ways to give certain users access to certain encrypted information in the future, but It is important that if implemented it would maintain backwards compatibility.

Ver. 1.7.2 should be approved in the next week or so which adds an optional admin option page password, and a couple tweaks.

After giving this some more thought I certainly CAN think of a not too difficult way offhand that this might be implemented to only give the original owner explicit access to the content when they are logged in. However It would have to be taken into consideration whether or not the admin / super-admin or other global access users should be able to view the content too, or if permission is solely given to the user that created the content. It could potentially do both with a setting to designate per field. However admins always win in the end since they can always just emulate or change passwords and log in as any user they wish.

It would be interesting to hear your thoughts on how exactly this would work.

We’ll take a look at possibly implementing it in a basic form though either way.

As for working with other plugins, its always going to come down to user permissions. If ALL users have permission to view than any action with the data from any properly hooked in Gravity Forms admin plugin or interface should return the decrypted data. Plugins that directly access the database without going through the Gravity Forms API wont fire the necessary encryption/decryption functions and checks. But if there are user restrictions the data returned will always be subject to the users permission level.

Ok,

Version 2.0 of the plugin now includes the following (and should be available before too long as of this reply):

• Added ‘User Owned Field’ advanced field option to allow only the logged in user submitting or updating the data to be able to view it as readable. -This overrides all other non-admin user permissions.
• Added conditional option to allow front end display of encrypted/hidden data for users with permission
• Added option to save settings when deleting plugin to install updated version
• Added option to save admin options page password regardless of deleting other settings to prevent password bypass when uninstalling and reinstalling plugin.

The ‘User Owned Field’ option is another individual field option and lets you basically give access only to the original creator of the content if they were logged in, otherwise it acts like a normal encrypted field. Using this together with the conditional front end display option should allow only any logged in users to see their own submitted data as readable on the front end or in admin as long as the plugin or code pulling and saving the data uses the gravity forms API to save and get field data. This would really have to be tested with whatever setup you may have, but the features should be useful for other people wanting to display front end data, or for users who have admin gravity forms results access and should only see their own entered field data for any given field.

Just WOW! That was fast! Awesome!! And your update sounds great!! I’ ll be happy and proud to be your first buyer (in just a few minutes ). This way your plugin should be very useful to me and other people who would like to secure their Wordpress user data! I have never ever seen a feature suggestion getting realized that fast.

Thank you very much! I recommend you to contact the gravity forms developers to get your plugin listed on the official gravity forms site. Your work and effort deserves to be recognized.

I don’t know when I get to test your plugin but have to buy it right now because you realized my suggestions that fast and it sounds like your plugin is just what I need.

Keep up the great work.

Best regards and also thank you for keeping me updated.

simon88