apex class with sharing without sharing   Leave a comment

Apex generally runs in system context; that is, the current user’s permissions, field-level security, and sharing rules aren’t taken into account during code execution.
Note

The only exceptions to this rule are Apex code that is executed with theexecuteAnonymouscall.executeAnonymousalways executes using the full permissions of the current user. For more information onexecuteAnonymous, see Anonymous Blocks.

Because these rules aren’t enforced, developers who use Apex must take care that they don’t inadvertently expose sensitive data that would normally be hidden from users by user permissions, field-level security, or organization-wide defaults. They should be particularly careful with Web services, which can be restricted by permissions, but execute in system context once they are initiated.

Most of the time, system context provides the correct behavior for system-level operations such as triggers and Web services that need access to all data in an organization. However, you can also specify that particular Apex classes should enforce the sharing rules that apply to the current user. (For more information on sharing rules, see the Salesforce.com online help.)
Note

A user’s permissions and field-level security are always ignored to ensure that Apex code can view all fields and objects in an organization. If particular fields or objects are hidden for a user, the code would fail to compile at runtime.

Use thewith sharingkeywords when declaring a class to enforce the sharing rules that apply to the current user. For example:

public with sharing class sharingClass {

// Code here 

}

Use thewithout sharingkeywords when declaring a class to ensure that the sharing rules for the current user are not enforced. For example:

public without sharing class noSharing {

// Code here 

}

If a class is not declared as either with or without sharing, the current sharing rules remain in effect. This means that if the class is called by a class that has sharing enforced, then sharing is enforced for the called class.

Both inner classes and outer classes can be declared aswith sharing. The sharing setting applies to all code contained in the class, including initialization code, constructors, and methods. Classes inherit this setting from a parent class when one class extends or implements another, but inner classes do not inherit the sharing setting from their container class.

For example:

public with sharing class CWith {
  // All code in this class operates with enforced sharing rules. 

  Account a = [SELECT . . . ];

  public static void m() { . . . }

  static {
    . . .
  }

  {
    . . .
  }

  public c() {
    . . .
  } 
}

public without sharing class CWithout {
  // All code in this class ignores sharing rules and operates  

  // as if the context user has the Modify All Data permission. 

  Account a = [SELECT . . . ];
  . . .

  public static void m() {  
     . . . 

    // This call into CWith operates with enforced sharing rules 

    // for the context user. When the call finishes, the code execution  

    // returns to without sharing mode. 

    CWith.m();
  }

  public class CInner {
    // All code in this class executes with the same sharing context 

    // as the code that calls it.  

    // Inner classes are separate from outer classes. 

    . . .

    // Again, this call into CWith operates with enforced sharing rules 

    // for the context user, regardless of the class that initially called this inner class. 

    // When the call finishes, the code execution returns to the sharing mode that was used to call this inner class. 

    CWith.m();
  }

  public class CInnerWithOut exends CWithout {
    // All code in this class ignores sharing rules because 

    // this class extends a parent class that ignores sharing rules. 

  }
}

Warning

There is no guarantee that a class declared aswith sharingdoesn’t call code that operates aswithout sharing. Class-level security is always still necessary. In addition, all SOQL or SOSL queries that use PriceBook2 ignore thewith sharingkeyword. All PriceBook records are returned, regardless of the applied sharing rules.
Enforcing the current user’s sharing rules can impact:

  • SOQL and SOSL queries. A query may return fewer rows than it would operating in system context.
  • DML operations. An operation may fail because the current user doesn’t have the correct permissions. For example, if the user specifies a foreign key value that exists in the organization, but which the current user does not have access to.

http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_classes_keywords_sharing.htm

Posted 2011年11月26日 by gw8310 in salesforce

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s

%d 博主赞过: