This module encrypt en decrypt submission data and in the progress of that it checks if you may decrypt data.
But Webform already checks if you have access to the data, so why does the module check the access again?

Like field_encrypt we only want to save the data encrypted into the database to ensure unwanted access if your database got in the wrong hands.

CommentFileSizeAuthor
#14 webform_encrypt_1.3-remove_access_handling-2433939-14.patch2.91 KBpaulvandenburg
#9 2433939-9.patch5.48 KBspadxiii
#1 webform_encrypt_should-2433939-1.patch6.09 KBtessa bakker

Comments

tessa bakker’s picture

tessa bakker
she/they
Primary language Dutch
commented
StatusFileSize
new webform_encrypt_should-2433939-1.patch6.09 KB

Here is the patch, many thanks to MrHaroldA for pointing me in the right direction.

mrharolda’s picture

mrharolda commented
Status: Needs review » Reviewed & tested by the community

Looking good!

I do think that this shouldn't be committed to the 1.x branch as some sites may depend on this (weird) global permission. I'll leave this issue open until FatGuyLaughing and I decide on the maintainership of this module ...

heddn’s picture

heddn
Primary language English
Location Illinois
commented

Yet another reason to create new versions. See #1788042-15: Compatibility with Webform 4.x

tessa bakker’s picture

tessa bakker
she/they
Primary language Dutch
commented

Any progress on the 2.x branch? :)

mrharolda’s picture

mrharolda commented

@Tessa: nope ;)

But I just created a roll-up release (1.1) for all commits in the repository, dating back to 2012 ...

alexfarr’s picture

alexfarr commented

hi,

We have a use case where we want to let sub_editors see a submission but not the encrypted data and only let full_editors have access. This is pretty crucial for us. Could we keep the additional access check in please?

Also i have noticed that using the submission_load hook to decode the submission does cause all webform submission data to be decrypted even if it is not used whenever a submission is loaded, for example on the results listing page. This is starting to causing us some performance issues as we scale up. The original form alter process is more scalable in that respect but does not cover all use cases, what are your thoughts on this?

P.S. Thanks for bringing this module back to life!

A

mrharolda’s picture

mrharolda commented

Could we keep the additional access check in please?

Probably not. Implementing your own "pseudo secure" permission per webform field is quite easy. The current implementation acts way too late; it'm more in the theming layer than in the decryption layer, so it's also prone to error and disclosure anyway.

alexfarr’s picture

alexfarr commented

@MrHaroldA
Hi, i did miss a key point in my post as i made a poor assumption.

I had forked this module some time ago to use on my production sites (https://www.drupal.org/sandbox/alexfarr/2514726), which now seems to be following a very similar line to your changes. I have the access check in the submission_load hook, which keeps this away from the theming layer. I have found it useful to allow users to view webform submissions without disclosing the encrypted values. But as you say this can be done in a separate module by implementing your own submission_load() hook, but the values would have already been decrypted at this point giving more opportunities for disclosure. I would prefer not to have decrypted the values in the first place.

I'm happy either way, but think its worth considering and i plan to make the switch back to this official module asap.

Cheers
A

spadxiii’s picture

spadxiii commented
StatusFileSize
new 2433939-9.patch5.48 KB

Just a re-roll of #1 against the current 7.x branch.

dharmesh.sojitra’s picture

dharmesh.sojitra commented

I have tested and #9 is working as charm.

Thank You

th_tushar’s picture

th_tushar commented
Priority: Major » Normal
Status: Reviewed & tested by the community » Closed (won't fix)

The user access is required to keep additional security while decryption of data.

th_tushar’s picture

th_tushar commented
tessa bakker’s picture

tessa bakker
she/they
Primary language Dutch
commented
Status: Closed (won't fix) » Needs review

@th_tushar .. are you serious? Showing encrypted data because you don't have the access to unencrypt is like, showing you database, because you can't read it... Isn't it better to handle access in this way?

1. Access to webform submission, no > access = false
2. Access to field inside webform submission, no > access = false
3. field data == encrypted { unencrypt data }

No 3. is where this module is needed, No 1. is Webform itself, No 2 is custom code or any other module.

paulvandenburg’s picture

paulvandenburg commented
StatusFileSize
new webform_encrypt_1.3-remove_access_handling-2433939-14.patch2.91 KB

Added patch for webform encrypt version 1.3

lexsoft00’s picture

lexsoft00 commented

I agree with @Tessa Bakker, webform is already handling access, the #14 patch works for me.

For those who are not using this patch if you don't give permission to anonymous users in webform_encrypt permissions the email values sent are encrypted and shown as:

Submitted values are:
First Name: [Value Encrypted]
Last Name: [Value Encrypted]
Email: [Value Encrypted]
Message: [Value Encrypted]

paulvandenburg’s picture

paulvandenburg commented
Status: Needs review » Reviewed & tested by the community

I'll mark this RTBC then.
It has been running fine on over 20 production sites over here for quite some time.

nicrodgers’s picture

nicrodgers
Primary language English
Location Monmouthshire, UK
commented
Status: Reviewed & tested by the community » Closed (outdated)

Drupal 7 and the 7.x release are no longer supported, closing as outdated. If this is still an issue in 8.x-2.x please re-open.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.