Make 'Editing submissions updates CiviCRM' configurable per webform

This isn't exactly a bug, but isn't exactly the desired/expected behaviour either.

I'd call this another case of "expected behavior depends on your expectations."

And in a lot of cases I think updating a submission and having it update the civicrm record is expected. Certainly it's what I had in mind when I wrote that part of the module. For example:
- Provide event participants a link where they can modify their registration info via updating their submission
- Allow applicants for a job/grant/etc to update their application info

The most robust solution might be to allow this behavior to be configured and disabled on a per-form basis. Let me know if you're interested in sponsoring that feature.

Additions to the documentation would always be welcome too :)

Currently, the way this works, any anonymous user can make changes to any CiviCRM contact record, provided they know enough of the person's contact information to make the module decide it's the same person.

This doesn't cause loss of data, since the changes can be reverted, but it's a pretty major security vulnerability, nonetheless. So, I hope I'm justified in bumping this issue all the way up to the bug category and critical priority, even though this is my first submission to the Drupal issue system. (I checked the issue queue handbook. It seems to fit.)

The problem seems to lie in the fact that the data is transferred to CiviCRM at the point of submission, and not at the point of confirmation. This means the data is taken in at face value whether or not the person submitting it actually has access to the email address that they provide.

At the moment, this shouldn't even be configurable, in my opinion. CiviCRM already has sophisticated functions for merging contact data. This module should only create new contacts, ever, no exceptions. Right now it's trying to do CiviCRM's job, and it's doing it poorly.

Forgive me if I'm missing something obvious here. We're just in the process of adopting CiviCRM at my company, it's my job to have the webform working before the 4th, and I just found out about this problem today. I'd rather not have thousands and thousands of people directed to a webform with a gaping security hole like this, if I can help it.

I hope somebody out there who knows more Drupal than I do sees this soon.

Thanks for reading!

would it be useful to clarify the issues here by comparing them to how civi profiles would behave in the same scenario?

Whoops looks like this issue just got sidetracked. Since we're already going down this road I'll respond, but recommend creating a new issue if there needs to be any follow-up discussion about questions unrelated to updating webform submissions.

Spencer, welcome to the CiviCRM community. Glad to have you here. If you haven't already please have a read of the CiviCRM users guide and the instructions for this module. It's a lot of material to cover and I'm sure you'll have more questions, which you can ask on the CiviCRM StackExchange site.

You are asking some important questions while trying to learn a complex new system. As you learn I'd encourage you to keep an open mind and avoid jumping to conclusions about what Civi or this module "should" do. To address your points:

• I don't think this is a security concern. BTW if it were, we shouldn't be discussing it here. There are special procedures for handling security issues in a more discreet manner.
• This module does exactly the same thing CiviCRM does on all its public forms (e.g. event registration forms, contribution, etc) which is to use the default "Unsupervised" dedupe rule to determine if a contact already exists before saving it.
• You can configure this rule (in the menu go to Contacts > Find and Merge Duplicate Contacts) to be as strict as you want to avoid any false-positive matches.
• You do not need to give anon users access to your webforms if you don't want to.
• Since you are just getting started with Civi I can understand why you are focused on creating new contacts, but after you've been using it for a year or two I think you'll start to appreciate the benefits of multiple tiers of deduping. Setting up the default unsupervised rule well can provide a great first line of defence against having thousands and thousands of dupes to go through later.
• The reason I don't see this as a security concern is because automatic deduping doesn't give people escalated permissions or access to any data from your system. The only "threat" is that you could configure a webform that allows a bothersome person to change the name or address of contacts in your database, which, if you have logging enabled, is easily un-doable. If you are seriously worried that someone would be motivated to be this obnoxious, you can configure your unsupervised dedupe rule to make this sort of thing extremely difficult or impossible.
• But if you want my advice, the threat from this sort of thing (what would you call it? A "dedupe attack?") is infinitesimally lower than the threat from spam-bots. Use mollum or captcha on your webforms, configure sensible dedupe rules, enable logging in CiviCRM, and you'll be fine.

If you have more questions, please feel free to ask on the CiviCRM StackExchange site.

@SpencerCampbell a good place to continue this discussion would be over at #1378900: Allowing for the Matching Rule to be specified per Form or even per Contact

@John.K
Now that I read it again, I realize I misread the original issue. My issue is about webform users updating their information by making new submissions, not about users or administrators updating the submissions themselves directly. Sorry for the confusion!

@colemanw
Wow! I only read your reply just now, and I wish I had read it earlier. I'll take your advice. Thank you. And thank you for your patience with my flailing attempts to make sense of a tool I know very little about. Next time I think I've found a security hole, I'll go through the proper channels.

@SpencerCampbell glad to help :) Good luck with your site launch.

This issue was filed against a branch (7.x-4.x) that is no longer supported. We're sorry we did not get to work through it, but once you upgrade to 7.x-5.x and if the issue persists, please feel free to re-open.