Securing DFFS' settings/configuration list

[imthenachoman]

Hello.

First, I wanted to say great job with DFFS. Talk about one heck of a powerful tool.

I have an conundrum I need help solving. I have a need to secure the DFFS list so users cannot see the settings/configuration. Since DFFS is pure JavaScript I cannot think of a good way.

DFFS saves all of its settings/configurations in a list. In order for any user to be able to use a list that is configured with DFFS, they must have, at minimum, read access to the list items in the DFFS list that contains the settings/configurations for it.

• You cannot remove read permission from the DFFS list because the user needs it for DFFS to be able to read it.
• You can “hide” the list view web part using targeted audience settings but this is a rather weak control as any user with programming knowledge can use REST/SOAP to retrieve the data from the site/list.
• You can hide the entire list from the browser but you can still pull data from it using SOAP/REST.
• You could disable API access to the list but then DFFS would break since it uses JavaScript to make API calls.

The only solutions I think might work require coding changes to DFFS and I don’t even know if it would work. I was thinking the DFFS list could be locked down and then a workflow could be created that runs as a specific ID that has read access to the DFFS list. JavaScript can be used to execute the workflow and “return” the required data from the list. The JavaScript would execute as the current user who does not have read access to the DFFS list but the workflow would run as a user that does. In theory this would work but I haven’t tested it nor do I know if its possible for a workflow to “return” data when invoked via JavaScript.

Any other ideas/thoughts?

How can we secure the DFFS list so users cannot read data from it while still using lists that are configured with DFFS.

[Alexander Bautz]

Thanks for the beer!

If you want to make the list harder to access you can hide it from all site contents in the Misc tab in DFFS backend. It’s not possible to use a workflow like you described, and in JavaScript you cannot impersonate another user so the users need read access to use DFFS.

If you restrict the regular users so they only have read access to the configuration list, I believe you should be OK because the contents of the configuration doesn’t contain any list data from the forms filled in with DFFS – it’s only the field names and configuration for tabs, rules and Custom JS etc. used to build the form and nothing that can reveal the actual contents of the list items in the DFFS enabled lists.

Let me know if you have any further questions.

Best regards,
Alexander

[imthenachoman]

If a workflow is set to use an impersonation step to run as another user than if a workflow is initiated via JavaScript, wouldn’t the workflow’s impersonation step still work?

The issue is that there is a requirement to hide the configuration/settings from the user. I know there is nothing dangerous/risky but that is the requirement we have.

I’m thinking that as long as we rely on a JavaScript solution like DFFS then there is nothing we can do. Might have to just get an exception…

[Alexander Bautz]

Yes, you can trigger an impersonated workflow by JavaScript, but unfortunately there is no way you can return the results of this workflow to the end user in the browser. This is because the workflow runs in the server side on a timer job – maybe once a minute, but the end user needs the config to load in the instance they load the form – thin means that workflow is out of the question.

I cannot really see why this requirement would apply to DFFS as no compromising data is served from the configuration list. It would be another matter if the actual form contents was saved in this “blob” and was accessible in the list.

Just to clarify in case your super needs it: In case you for example set item level security on a list item in your DFFS enabled list, there is no way to get access to the form contents trough the configuration list.

Best regards,
Alexander

[imthenachoman]

Thank you!

And yes, I know there is no compromising information but we have a requirement that application users cannot see application configuration information. JavaScript applications are in this grey area.

I thought I’d check with you to get your perspective on this. I appreciate your help sir.

[Jon Whisman]

Nacho,

Not sure if this would help, but would using an obfuscator on your JS code help the matter to scramble the code a bit more and secure it further?

Like so?

http://www.javascriptobfuscator.com/Javascript-Obfuscator.aspx

[imthenachoman]

@Jon

Unfortunately no. Obfuscation is not, unfortunately, enough of a control to meet the requirement. :/

[Alexander Bautz]

Because all users must have read access here, the best I can think of is to hide the configuration list (hidden from all site content) by using the controls in the Misc tab in the DFFS backend configuration.

This will however not prevent anyone who knows the name of the list form typing in the address, so you would also need to edit the AllItems.aspx list view to remove all items – for example by setting a filter like “ID is equal to 0”.

This way only uses who use custom code to query the list will be able to see its contents.

Alexander

[imthenachoman]

Thanks Alexander! We’re also looking at other ways to accomplish this. I’ll report back my findings if we have anything worth reporting.

[Author]

Posts