+ Start a Discussion
MikeWareMikeWare 

APEX Security Context

Things looked great at the APEX day demo yesterday.  My first concern, though, was over the security context in which code executes. I asked about this and was told that the code runs at adminstrator level.

This is something that seriously needs to be changed.  Of course it's the developer's responsibility to manage code to avoid undesirable results.  However, this is going to be extremely difficult.

If write some code that displays query results (or modifies data?!), but a user is normally not allowed to view or  those records, unwanted information will be displayed.  How would you even write code that would exclude those results? (sorry, there may be functions to do this, I'm just getting started writing code).  And if you did, you'd have to make everything conditional or have multiple controls or triggers.  I'm just trying to picture how even an advanced user would manage something like that - and your goal is to make "everyone" a developer?

Not good.  It's highly critical to have an option for functions to run at the user level.  In fact, that should be the default.  I hope that this is something that will be addressed soon.
mtbclimbermtbclimber
Thanks for attending the event yesterday and again for providing the feedback (keep it coming).


MikeWare wrote:

If write some code that displays query results (or modifies data?!), but a user is normally not allowed to view or  those records, unwanted information will be displayed.  How would you even write code that would exclude those results?

There is not currently a mechanism to do this.  Do you think it would be better to require context declaration at the statement level or method level?



MikeWare wrote:
.. and your goal is to make "everyone" a developer?


Certainly we would love to see many more people be a "developer" but even developers will not have the rights of a developer in every organization.



MikeWare wrote:

Not good.  It's highly critical to have an option for functions to run at the user level.  In fact, that should be the default.  I hope that this is something that will be addressed soon.


Do you think all Apex Code should run as the user by default, including triggers?

Thanks,
MikeWareMikeWare
>>Do you think it would be better to require context declaration at the statement level or method level?

More experienced developers can probably answer that a lot better than I can.  I'm going to get in over my head real quick.  I understand what I'm trying to avoid more than how to implement it.  I think maybe a method - something that would enable adminstrator level access with scoping behavior similar to variables. 

So, by default everything would run at user level but within, for instance, a function, you could invoke administrator level access.  Just like a variable it would persist within the scope of the function and then be released on exit if not already released within the function.  I don't know if that makes any sense.


>>Do you think all Apex Code should run as the user by default, including triggers?

Yes.  I could live with it the other way around but it seems like a nightmare to audit.
Park Walker (TAGL)Park Walker (TAGL)
I may be off the mark here, but it's my understanding that Apex Code cannot display anything: it's a data manipulation language, used to build data manipulation code which is triggered by CRUD operations. You can create and manipulate objects, but short of retrieving some data and stuffing it into a field in another object it seems pretty difficult to get around the built in security.

On the other hand, I do want the code to run at an administrative level so that I can test values and make updates to fields that all users may not have access to. Image trying to write code that only made an update if the correct type of user was logged in. Now imagine trying to debug it.

Park
michaelforcemichaelforce

I was actually afraid of the opposite...  imagine if (for example) you wanted to be able to show a sales guy where he stands in the company rankings for the month.  You know... inspire some friendly competition :smileytongue:, on an s-control perhaps in a dashboard.  Well... you'd need to be able to query all the org's opps with admin rights, and then do some math and show the rep the result.

If you were forced to run code in the context of the user, this would be undoable.

In other words... running code with admin rights is highly desirable in many situations, it would be a shame if it DIDN'T work this way.  Having the option to choose one or the other is a 'nice to have'... but out of the two, admin level is definitely the way to go.

Always ThinkinAlways Thinkin
Well, I'm confused now. In reading the Guide, I ran across this topic that states:


"All active permissions for the context user are upheld when modifying sObject field values in Apex"


which implies to me that: if the context user who triggers the code cannot change the value of a field manually, then Apex won't do it either.

Am I misreading the quote?

I've been counting on Apex to free me from the shackles of coding business logic in AJAX and coping with overlapping and conflicting sets of permissions.
mtbclimbermtbclimber
That is a misleading statement from the documentation. What it is meant to state is that there are fields which even at system level are not update-able like created date, lastmodified date, etc. We'll get the documentation updated to be more clear.

Thanks,
gbalakrigbalakri

Any new update as part of the new release for making the code run under the logged in user. I realize there is a new method called runAs. Is this one limited to test methods

Girish

NaniNani

Hi,

 

I'm new to SF and my first assignment is to write Apex code for some requirements.

The scenario is complex but I'll try to simplify it like this:

Person X creates an Opportunity and changes the Owner to Y. But, X would still like to view the Opportunity. We know that whenever the Owner of a record is changed then all the sharing rules are deleted. So, I'm trying to write an Apex code in 'After Update' trigger of Opportunity to create a record in Opportunity_Share object with Parent Id = Opty Id and UserOrGroupId = X Id. But, I'm getting INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY error.

 

Because X is no more the owner of the record, I guess this error is shooting up.

 

Is there a way I can run the code as Admin which makes the Opty accessable all the time irrespective of who is modifying the Opty?

 

Thanks,

Nani.

sfdcfoxsfdcfox
Having Apex Code run as "Administrator" allows all sorts of nifty updates that would not otherwise be possible. If you require your code/triggers to respect a user's security permissions, use "with sharing" and place the logic of your trigger into that class. Any code that uses "with sharing" will respect record editability (but not field level security). In this way, you can keep users from updating or querying records that they should not be accessing. Normally, triggers are used to update data that the user should not be viewing/editing (necessarily) anyways, so there is normally no harm in running at a System level for most triggers.
NaniNani

Hi,

Thank you for the reply.

 

I moved the logic from trigger to a class with 'with sharing'. But, I still get the error.

I understand that its good to respect user level security but as per the requirement the user wants to give the ownership to another user but still want to have read only access to the record in order to follow up on the record status.

Moving the logic to a class is not running the logic in admin mode.

 

Any suggestions on how to run the code as admin is greatly appreciated.

 

- Nani.

NaniNani

Hi,

 

I could make it work by changing the class from 'with sharing' to 'global'.

Thank a ton.

 

- Nani.

vladicavladica

Hi, I new to salesforce and I hope that there is an easy solution for my problem.

 

I developing app for my company, we have a lot of users with different privileges (on object and fields). On visualforce page I have to show all information available to user (don't ask). 

 

I using :

 

Map<String, Schema.SObjectType> globalSchemaDesc = Schema.getGlobalDescribe();

 to read schema for all object and iterating  through object names :

 

Set<String> objNames = globalSchemaDesc.keySet();

for(String key : objNames){

Schema.Describesobjectresult descObject =
globalSchemaDesc.get(key).getDescribe();
Boolean isAccessable = descObject.isAccessible();

}

 I can read if object is available to user.

This seems to work.

 

But,

now I need check accessibility  for each field for each object.

I'm using this code sample to do this:

 

Map<String, Schema.SObjectField> fields = descObject.fields.getMap();

Set<String> fldNames = fields.keySet();

for(String key : fldNames){
Schema.Describefieldresult field = fields.get(key).getDescribe();

Boolean isAccessable = field.isAccessible();

}

and I get this error:

"System.Exception: <namespace>:Too many fields describes: 11"

So,

my first question is: Is this the right approach?

second question is:  How to resolve this issue.

 

 I found this post:http://community.salesforce.com/sforce/board/message?message.uid=127681

 

Any help would be great.

 

Message Edited by vladica on 11-25-2009 03:34 AM
Message Edited by vladica on 11-25-2009 03:40 AM