function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
peushupeushu 

Session Expiration

How long does a session last after it goes idle? If some activity is performed periodically within this session time out limit, can the session last indefinitely?

thanks,

Peush

 

DevAngelDevAngel
A session never goes "idle".  Sessions are active until they go "stale".  A session will go stale after 120 (edited 6/19/03) minutes of inactivity.  If you attempt to make an API call using the session_id of a stale session you will receive an invalid user fault.  You simple need to re-login using the same username and password.

Message Edited by DevAngel on 06-19-2003 10:34 AM
peushupeushu
If I keep making calls, say every 30 minutes, using that session ID, will it ever go stale?
DevAngelDevAngel

No Peush, it will not go stale as long as there is activity in a 90 minute period.  Is there some other concern that you have about the session?

(see reply to orginal post)

Message Edited by DevAngel on 06-19-2003 10:38 AM
peushupeushu

Dave,

I'm not sure if this is related to session expiration, but every two hours I get an exception saying "session ID required in cookie for non-login request". The thing is that I set the session ID after login and continue to use that - I haven't looked through my code enough to see if there is something in there that is causing this, but I would be pretty surprised if after 2 hours, for some reason, the requests stopped including the session ID. Logging in again seems to fix this problem (for the next 2 hours at least). I will probably get a better idea once I look at the fault code - I do remember another instance where the fault message was different from the fault code. Actually, that was when I wasn't including the session ID in the request, the fault code was as in the documentation however the message was "request is too large".

thanks,

Peush

 
DevAngelDevAngel
Hi Peush,
 
Sessions expire after 2 hours (120 mins).  There may be certain activities that do not reset this session timeout.  The API functions slightly differently than salesforce.com.  salesforce.com will refresh the user's cookie automatically by actually replacing it.  The 2 hour period of inactivity is still applicable.  To have an analog in the API, we would need to send a session id back with every call, and we don't.
 
Currently, the best practice is to re-login if you get the session missing or invalid fault code, and then retry the request.  The alternative of logging in prior to each request is more burdensome on all the resources involved and is not recommended.
KarlKarl

Dave,

Do you have a code sample for detecting the INVALID_SESSION_ID fault in Visual Basic.NET ?  I'm guessing you'd have to catch an exception and examine the contents of the message, but it seems like it would be very difficult to test this out, what with having to wait for two hours to get the fault.
zakzak
I find it easier to note the date/time when i made the login call, and check that its less than 90 minutes before making additional API calls, if it is, just call login again to get a new sessionId. This seems much easier than waiting until you get the exception and trying to handle it.

Cheers
Simon
KarlKarl
True, this could work.  However, if the timeout value ever changes in the API then we'll have to re-write code, or at the least, update a configuration file that contains the timeout value.  That could get tedious with lots of apps in production.
DevAngelDevAngel
I'll have something for you in 2 hours. 
DevAngelDevAngel

Hi Karl,

The file is a zip file but I had to rename it to post it here.  After downloading, rename it to zip.  This is a simple winform that logs in and has a proxy object declared at the class level.  After logging in the app goes into an endless loop that sleeps for 5 seconds on each iteration.  When it awakens it makes a getUserInfo call and then goes back to sleep.  There is an error handler in the app that checks to see if there is an invalid session id exception raised and, if found, simply logs in again and continues.

If is not an invalid session id exception, the handler does something else.  In this case it just writes the error to the output window and bails out of the loop.  Exception handling is going to be specific to each application and I chose the simplest use case. 

I think the important part of this is how to obtain the exception code from the fault.  The way .Net generates the proxy ignores the faults that are defined in the wsdl and also the ExceptionCode enum object that is defined.  You can look at the wsdl to obtain the possible values for the exception code and use those values in your error handling.  Yes, there is the possiblility that the values may change from release to release, but this penalty is incurred by .Net.  You would need to get a fresh wsdl to see any changes and additions or subtractions from the enum in any case. 

Hope this helps.

Cheers.

 
CodeTalkerCodeTalker
Hello,

I wanted to ask you more about sessions as you seem to know a lot about it.

We are trying to develop a composite app. The user would log into SF and then connect to our servers through a custom tab. Initially we can get the session id and use it until it expires. As an example, our process generates leads by downloading accts from SF. Let's say the process takes 2 hrs to analyze the accts to produce leads. During that time no calls are made to SF from our servers.

Is there a way to refresh the session before it ends?

We shouldn't have access to the user's SF username and password to automatically log in again. We also don't want to make unnecessary calls to keep the session alive. Is there some call to either refresh the session? Or is there a way to get the time remaining so that periodically we could perform some call to get an updated session id?

Thank you for your time!


DevAngel wrote:
Hi Peush,
 
Sessions expire after 2 hours (120 mins).  There may be certain activities that do not reset this session timeout.  The API functions slightly differently than salesforce.com.  salesforce.com will refresh the user's cookie automatically by actually replacing it.  The 2 hour period of inactivity is still applicable.  To have an analog in the API, we would need to send a session id back with every call, and we don't.
 
Currently, the best practice is to re-login if you get the session missing or invalid fault code, and then retry the request.  The alternative of logging in prior to each request is more burdensome on all the resources involved and is not recommended.