Feature service security concern

[MattCashen1]

I had a question/concern regarding the feature services you use for a Quick Report app. I understand the need for these services to be made public. That allows the public editing rights to add their features to them. However, if you were wanting to implement an app like this for your organization (as my organization is considering doing), then there needs to be more security in place. As it is set up you are supposed to give editors the ability to add, update, and delete features. That means that were a user able to find the location of this feature service online they could potentially delete or change every feature. They wouldn't even need an arcgis online account to do this. That is problematic. If you set it to were the editors can only add features then even as the host of the feature service you still aren't able to delete these features. It seems like as the host of the feature service you should have some kind of 'master' control over the feature service. That way users can have the ability to add features and publicly access the feature service, but they wouldn't be able to tamper with the data. I just wanted to know if there is any way to set this up or if there any plans to implement a structure like this. Thanks!

[MarikaVertzonis · Accepted solution]

Adding the ability to use secured feature services in Quick Report is underway and should be available in the next beta release.

Signing in to AppStudio and its apps with different types of log in's, is also an area that is getting some improvement over the coming beta releases.

[MattCashen1]

Thank you! I look forward to seeing those changes implemented

[ChadKopplin]

I am wondering if you have thought of using versioning?  Then each group or each individual would have their version, but they would not be able to change the main database, which is controlled by the person with the rights to implement the changes to that database. 

[HannahFerrier]

That sounds like like a great idea.

My first instinct would be to set up a secondary, secured feature service into which records from the public feature service are QA'ed/QC'ed and then copied.

Both data security and the quality of data collected by the general public are very valid concerns. This setup would address both, and would also allow you to empty the features out of the public feature service periodically (daily, weekly, etc) which would also minimize your exposure.

Just my opinion

Hannah