Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

I'm trying to clarify VF controller context versus Sites Guest User permissions on Contact record.

From everything I've read, a VF controller using "without sharing" operates in the system context. Does this mean a VF page on a Force.com Site essentially has full CRUD permissions on the Contact object, for example?

If so, why does the Guest User profile allow only Read/Create permissions (through Public Access Settings) on the Contact record? It seems like the only reason I need to set Read permissions for Guest User is if I am referencing an object's fields on the page using inputField. Otherwise, selects and DML in the controller are in system context and thus ignore the profile's object permissions. Is that correct?

share|improve this question
add comment

2 Answers

The only effect that "with sharing" has is to enforce object sharing rules; that is, if you use "with sharing" and query an object that has private record visibility, any Apex SOQL will only return results for objects shared to them; if you do not use "with sharing", the Apex SOQL will return results for all objects.

As VNE_Hess stated, the user's license restrictions are always enforced no matter what; you can't directly get around them when the code is executing as that user.

It's also worth mentioning that although Apex never enforces field-level and CRUD security, most of the standard VisualForce rendering components do enforce FLS/CRUD, so even though your system-context Apex was able to retrieve (and modify, etc) a field that the user doesn't have profile visibility to, if you pass it to VF via say an inputfield component, the user won't see it.

The Sites Guest User is a special profile that is heavily restricted from making updates to core CRM objects. From memory I think it's read-create only to the core objects except for Articles. Salesforce imposes this restriction AFAICT to require customers to upgrade to more expensive Partner or Customer Portal licenses to get this level of access.

If you're developing AppExchange apps that deal with the standard objects, it's very important to understand that to pass security review, your Apex code must manually enforce FLS and CRUD at every step of the way. This is a HUGE pain in the rear if your app does a lot of these updates, and results in very error-prone code because the ESAPI toolkit that Salesforce provides has a much more error-prone API than the core SOQL/DML interface.

Salesforce would save its app developer community literally thousands of hours of work per year by implementing a "with FLSAndCrud" type keyword, but architecturally that seems unlikely any time soon.

share|improve this answer
    
This is how I interpreted it as well. Would you say that it is acceptable to perform the CRUD actions in Apex as long as you don't ever wish to distribute it over the AppExchange (i.e., aren't concerned about the security review)? That is, it doesn't violate the user licensing terms? There was an answer to a similar question that made some other points. –  Peter Knolle Jan 8 '13 at 13:03
    
I think you're asking if it's allowed to create Apex code that doesn't manually enforce FLS and CRUD for every operation, if you're not distributing via AppExchange? The answer is definitely yes, and pretty much every installation of SFDC I've ever seen with custom code does this since a large amount of the time FLS / CRUD permissions are not relevant to what a piece of code must do - i.e. if the customer is creating an operation that they know all users need, enforcing CRUD/FLS is overkill. –  jkraybill Jan 18 '13 at 3:16
add comment

Removing the keywords "With Sharing" only steps over the field permissions and sharing restrictions that a user may face when editing or viewing a record. It does not allow a page to operate above or beyond the (non sharing) features exposed by the User License.

So the Guest User license is operating to allow only Read/Create on the Contact record, not the sharing features.

share|improve this answer
    
"With Sharing" does not enforce field-level security, btw; it only enforces record sharing. This is a massive pain for big apps that need to pass security review, since there is no equivalent "with FLS" keyword to auto-enforce CRUD and FLS. The programmer bears ALL the burden for this, even though it's a requirement of every AppExchange app that they must enforce it. This page has more info: wiki.developerforce.com/page/Enforcing_CRUD_and_FLS and the SFDC-provided ESAPI classes provide some utility classes for making it slightly easier. –  jkraybill Jan 8 '13 at 5:19
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.