6

Please help me understand if apex code really runs in a system mode or is there a technical glitch, in our scenario, we are using multiple license types based on end user need, we have almost 3k 'Full Salesforce License' & 1K 'Force.com App Subscription' license.

Our Opportunity object is fully customized and not using commonly used sales features like "Sales Quota", "Forecasting", "Opportunity Product" etc. both, Opportunity detail and edit page are visualforce pages.

We did a POC and found that user with 'Force.com App Subscription' license can also read & update Opportunity object via apex, infact we went one step ahead and tested that user with 'Chatter Free' license also have the capability to read and update Opportunity.

If this is true why would anyone with this scenario will spend dollars every year maintaining 3k users with 'Full Salesforce License' when I can achieve everything with little bit more customization than we have today and converting all users to either 'Force.com App Subscription' or 'Chatter Free' license

Improve this question

2 Answers 2

Reset to default
9

Apex Code has two modes of operation: "sharing" and "without sharing" modes. While in sharing mode, the user's permissions will have an effect on what they're allowed to do. When using "without sharing," there's virtually no limitation as to what the code can do, including modifying records on an object the user can't even access, etc, as you've found with your POC.

What's stopping you from doing your own custom platform using Chatter Free license is that you're violating the Master Service Agreement and/or related agreements. You could be charged for full licenses retroactively, and failure to pay is breach of contract that will result in a lawsuit for damages, plus the loss of data that could result.

There are few technical limits in place that prevent some abuses, such as creating a custom user object, custom session object, etc, and proxying a sharing model through a single Sites user, either. The agreements even spell out that there are known abuses that are possible, and that they monitor such abuses.

While you might get away with abusing a few licenses (and I'm not in any way condoning the behavior, as the risk isn't worth the payoff), it's likely salesforce.com would find your account with 3,000+ free users that should be full licenses, and they will make you pay for them or forcefully terminate your account.

Improve this answer
5
  • Thanks @sfdcfox for your answer, it makes sense. However normally as a developer/consultant before providing any solution we makes design descision on basis of technicality that what is allowed in Apex or platform and not necessarly client or consultant know about MSA. I feel, there should be restriction by Platform itself. SOAP and API does inforce it but not Apex.
    – Jitendra Zaa
    Commented Jun 8, 2015 at 18:15
  • 1
    @JitendraZaa The problem lies at a lower level, I think. There's only one Apex Code engine, and it has to support all types of users. They probably could update their library to include these checks, but the cost is probably disproportionate to the amount of abuse they notice (i.e. they'd rather release new features and keep the platform faster, instead of bloating the core unnecessarily).
    – sfdcfox ♦
    Commented Jun 8, 2015 at 18:24
  • Thanks so much @sfdcfox, understood it. At least this question will help me as a consultant to get my clients into confidence that we should not try to use platform capability in other way.
    – Jitendra Zaa
    Commented Jun 8, 2015 at 18:26
  • I have documeneted my findings in this blog post, hoping will help someone in future and important summary from @sfdcfox on MSA - jitendrazaa.com/blog/salesforce/…
    – Jitendra Zaa
    Commented Jun 8, 2015 at 20:27
  • Your blog post has some inaccuracies. You should correct them.
    – sfdcfox ♦
    Commented Jun 8, 2015 at 21:00
3

There are system wide profile permissions (such as "customize application"), CRUD/FLS permissions (such as ability to update a particular sObjectType), and record access permissions (such as the ability to see a record created by someone underneath you in a hierarchy).

The system wide profile permissions are always enforced. Your chatter free user would not be able to modify a custom setting, for example, because they don't have the customize application permission.

The CRUD/FLS permissions are not enforced automatically, you need to enforce them by performing the appropriate CRUD/FLS checks in apex or in the visualforce page.

The record permissions are only enforced if you explicitly run your class 'with sharing' (default or keyword omitted means the class is run without sharing in most cases).

So yes, Apex runs in system mode, and the ability to update Opportunity is a CRUD permission, not a system-wide profile permission, so if your class does not enforce CRUD then you can update it.

FYI, when using the SOAP/REST API, everything is enforced. It's only in Apex code that you can ignore CRUD/FLS and record access perms.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .