0

I have a SOAP apex class which exposes some webservice methods to be calls from my applications backend. This code has some DateTime methods that return the values based on context user's timezone settings. Now how can I know which user's context this code is executing in or if I want to change the behavior how can i change the context user for thee webservice methods ?

3

Ideally, you should only ever use GMT methods. Your application should convert all times to GMT, and your Apex Code should only use GMT. This removes all ambiguity, and helps make sure that you're getting the right information back regardless of the time zone settings. The context it runs as depends on the currently logged in user, which you can determine via the UserInfo methods (there's one for the time zone, if you're interested).

| improve this answer | |
  • Yes.. if I am not wrong getSessionId from UserInfo class is used to set the Sessionheader for a SOAP call. And this is what determines the login user's context for that SOAP call to resolve time related API calls. – Yogesh D May 10 '18 at 18:38
  • 1
    @y.dixit Yes, if that's the session Id you use, that'll be the time zone used. – sfdcfox May 10 '18 at 18:47
2

The context user is the account under which the remote application authenticated prior to calling the web service. This is often, but not always, an "Integration" user, that's not used in the UI and may be API only.

REST services can be exposed to the unauthenticated web over a Force.com Site, but even in that case there's a context user (the site guest user).

Note that this is distinct from the question of whether or not the context user's permissions and sharing rules are being applied - there's (almost) always a context user even in system mode code.

You can obtain details of the current context user via the UserInfo class. If you need to run under a different context user, you'd need to change the authentication behavior of the remote calling application, but your code generally should not be dependent on the context time zone.

| improve this answer | |
  • That makes sense. In my application wihch is making the SOAP request I get the sessionId and add it as session header in the SOAP headers. I think this is what determines the current user context for that SOAP call. – Yogesh D May 10 '18 at 18:31
  • 1
    That is correct. The session id is linked to a specific authenticated user session. – David Reed May 10 '18 at 18:38
1

It always runs in System Context. This is from the documentation:

Invoking a custom webservice method always uses system context. Consequently, the current user's credentials are not used, and any user who has access to these methods can use their full power, regardless of permissions, field-level security, or sharing rules. Developers who expose methods with the webservice keyword should therefore take care that they are not inadvertently exposing any sensitive data.

Additionally it mentions further on how to address this scenario:

Apex class methods that are exposed through the API with the webservice keyword don't enforce object permissions and field-level security by default. We recommend that you make use of the appropriate object or field describe result methods to check the current user’s access level on the objects and fields that the webservice method is accessing.

Remember, you will always need a User mapped to a Profile to be able to call the webservices, so you can utilize UserInfo apis to make the decisions in your webservice methods.

| improve this answer | |
  • I know that the code will run in the system context but if you are using DateTime methods for example something like this Datetime dt = Datetime.NOW(); dt.hour(); // this will return the current hour wrt the user's context that the code is running in. – Yogesh D May 10 '18 at 16:23
  • So what exactly is your question? Are you saying this returns the current user datetime based on their time zone? Or it does not? And that you want it to return the current user's time? Based on what I understand this will return the current user's time. And as long as you have that information, you can always take any branching logic out of that. – Jayant Das May 10 '18 at 16:28
  • It doesn't return current user's time it returns time wrt the user in whose context the code is executing. So what I am experiencing is it returns the time wrt one particular user's timezone setting. i wanted to understand how that works ? – Yogesh D May 10 '18 at 16:31
  • That is what would be the expected behavior. When you say "current user", the context user which is running the webservice is basically the current user for that webservice scope. – Jayant Das May 10 '18 at 16:33
  • And how is the user scope set for running the webservice. I mean because the web service is called from outside salesforce using WSDL how is the calling user set for each call ? – Yogesh D May 10 '18 at 16:41
0

Answers posted by sfdcfox, David and Jayant helped me explore more about the issue and understand better. I think answer to my question was, whenever you do a SOAP call all the code runs in the system context but if your code has any part which does timezone related thing (like DatTime.hour() that is resolved wrt current user's context) then it will use current logged in user's context. Now because it is a SOAP call the logged in user is no different than the user whose username password was used to get the sessionId for that SOAP call. This session id is added as SessionHeader to the SOAP headers which decides the user context. I hope this answer is not wrong and my understanding about the functionality is correct, if not I will be happy to pull it down from the post.

PS: answering to my own question because I did not find this information anywhere in the documents or or any post. I have formed this answer by collecting information from multiple answers and my understanding.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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