Alternatives to using page action for user preferences

Question

Sometimes you have to load user preferences stored in a Hierarchy custom setting when a Visualforce page loads. If the preferences exist, then retrieve them, otherwise create them and insert them.

Something like

if(My_Preferences__c.getValues(UserInfo.getUserId()) != null){

prefs = My_Preferences__c.getValues(UserInfo.getUserId());

}else{

prefs = new My_Preferences__c(SetupOwnerId = UserInfo.getUserId());
insert prefs;

}

The only problem is, you cannot perform DML in the constructor. Whenever this issue comes up on discussion boards, the answer is always the same, use the action="your preferences method" parameter in the apex:page section. I even remember a guy who worked at Salesforce saying to do this.

And yet, whenever you put an action in the apex:page, the Security Scanner always flags it as a Critical item, and surprise surprise, clients aren't too hot about critical items.

I do remember trying to call the method via an apex:actionfunction in a $(document).ready(function() { });) call but this caused the page components to rerender unnecessarily and caused "flashing". Besides, I only need to insert the user preferences the first time they click on the page.

Has anyone encountered this problem before, and if so, how did they solve it?

Answer 1

This isn't a direct answer to your question, but it may help.

With hierarchical settings, if you're program is defaulting the value for the user if they don't already have one you're losing the awesome power of hierarchical settings which is you can set the defaults at the Org and Profile level so that you don't need to populate the setting for every Jane and Bob.

Assuming you're making a managed package, why not create an installer script that takes care of setting the Org default for the custom setting? That, or just alter your code to interpret nulls as the default setting as Daniel suggested.

Answer 2

You could make a strong case that there isn't a significant security risk inserting a custom setting for a user if you aren't taking query string parameters to populate it.

Alternatively, could you delay the insertion of the users custom setting until you have a value other than the default?

I usually wrap custom settings in a class with a property per field. If the user doesn't have an instance of the custom setting the getter will return a default value. The setter will create the setting as required and set the value.

Answer 3

I have not ran into that particular problem, but one thing you could do is create a Remote Action method in your controller that you can call in you $(document).ready() function to handle the custom settings. This way you don't have to mess with VF re-renders.

Just return the data you need and stick it into the DOM with jQuery.

Answer 4

The security risk is flagged because of the potential for cross site request forgery — i.e. someone could call the URL with dubious parameters and your code then uses values from them when modifying the database.

I encountered the same thing submitting a managed package fore security review, but I knew that what was being inserted was safe and after talking to the security guys they agreed it was just a false positive. Yes I was reading the parameters, but they had nothing to do with what I was inserting into the databae, but the security scanner isn't smart enough to account for that.

Your best course of action is to talk to your client and explain that the tool is known for false positives (afterall it's always better to err on the side of caution) and explain why the flag is an instance of this. Of course, if your code is potentially exploitable, it should probably be changed.