+ Start a Discussion
Jim F.ax281Jim F.ax281 

INVALID_SESSION_ID: Invalid Session ID found in SessionHeader: Illegal Session

Hi,

I've got a ASP.NET 2.0 application which acquires a session that is passed to it from SF.

I just started getting this message, and am not sure where to go with it.  The code that is running with it has been functioning for a while without any issues, and it still works some of the time.  Also, even though the API calls are server-side, I've only seen this problem when running IE; Firefox hasn't been a problem so far.  I don't have a setting for "lock sessions to originating IP" - this is the developer version.  Does anybody have any suggestions?

Thanks, Jim
SubaKrishSubaKrish

Hi Jim & SF Support team

We are also facing the same issue. We are AppExchange partners and our application is being affected BIG Time by this error. It happens at random. I use a single sign on process (using API 11.1) and obtain the session id from the call that originates from Salesforce and use that for subsequent calls to SF. SF seems to claim that the session id it provided is invalid within a short period of time.  In the past one week, a huge number of invalid sessions are being reported at random and causing great grief to our product.

Heres a sample of the response from SF, with debug info that I  captured: Infact I just logged in and obtained a new session Id that becomes invalid almost instantaneously.

INVALID_SESSION_ID: Invalid Session ID found in SessionHeader: Illegal Session

Salesforce SessionId: 4c0600D4000000078IP!AQMAQMRi2pwKCIsw4Ri3Y1FQ7HWvapjSy_5O8f0gi3mwJQsRF_vRLVK62s.MNp8OLteiWcJ6q8iDLJLBbWqMVmZknogtl4urSalesforce

URL: https://na2.salesforce.com/services/Soap/u/11.1/4c0600D4000000078IP

Cld you please provide some inputs / resolutions.

Thanks!

Suba

 



Message Edited by SubaKrish on 05-27-2008 11:08 PM

Message Edited by SubaKrish on 05-27-2008 11:10 PM
somasoma

(bump)

 

My applications have begun experiencing this same issue. They've been functioning for over a year and all of a sudden this began occurring. In an attempt to deal with it, I modified the code to catch the invalid id exceptions and relogin anytime a query() is made, but it appears I forgot to wrap calls to create() so the issue has recently popped up again spontaneously in cases where create() is called. It's a good thing, though, because it's more evidence of this issue. Any answers, Salesforce?

RmcnultyRmcnulty
BUMP
somasoma

After consulting with techies at Salesforce, it was determined that this issue was occurring because the same account was being used to access the Salesforce API from outside Salesforce by multiple applications that each application wound up sharing the same session key from Salesforce. These applications weren't necessarily sharing the same application pool nor were they even running on the same machine, so they had different IP addresses, yet they were essentially all using the same session. This was problematic.

 

There was a simple fix for this, but this fix is itself only a bandaid. The fix was to check an option in the Salesforce settings that would restrict sessions to IPs (Settings > Security Controls > Session Settings > "Lock sessions to the IP addresses from which they originated"), but I'm operating in Unlimited Edition and am not sure if this option is available to others. Even so, this doesn't serve as an efficient solution if it is the case that I have more than one application running behind the same IP using the same Salesforce account to access the API.

 

One of the issues is that applications are expected to maintain their own sessions. This means that if we want our applications to efficiently reuse a session at Salesforce without having to issue extraneous login() calls in the face of long periods of running time, we need to implement some sort of internal expiration timer in our applications. For instance, my sessions with the particular account I'm using to access Salesforce are set to two hours in the Salesforce settings, so in the applications I code, I set them to maintain an internal expiration timer that they check everytime they issue a call to Salesforce.  If two hours has elapsed since the login() was issued, the session is voided, another login() is issued, and the timer is reset. That's all perfectly fine, until another application comes into the mix behind the same IP. Now the session's expiration isn't able to be correctly managed by each application independently. They're expected to actively share a common core now, otherwise one application is going to think the session is still active when it isn't. It will issue a query and be hit with the INVALID_SESSION_ID exception. And you see, even if a second application issued a login(), as long as it was using the same credentials, it would still be joined into a session already activated by the first application. Hmm..

 

This issue can be fixed, in part, if during a login() attempt, Salesforce would return the expected expiration time. If there already is such a thing, I haven't seen it noted in documentation, but this would help to some extent.

RmcnultyRmcnulty
I have always been using the restrict sessions to IPs.
WasulaWasula
So is it safe to assume that someone running a Flex application and Connect for Microsoft Outlook might experience this problem frequently?