+ Start a Discussion
tannershamrocktannershamrock 

New API Broke ALL Applications and many s-controls: Invalid Session ID

I am not very pleased with this rollout of API 12.  This subsequently broke all of our integration applications using Java and the API, all of our Cast Iron orchestrations, and many of our s-controls.

I thought there was supposed to be reverse compatibility?

We are getting Invalid Session ID errors on everything and it is costing us a TON of money to fix these problems.

Is anyone else having these problems throughout the board?  Any suggestions on how to deal with this on a large scale?
SuperfellSuperfell
Sorry your having trouble, there were changes to how session lifetime is managed, however it would never be shorter than it used to be, so its not really clear from your post what's tripping things up. Did you log a case with support ?
pmorellipmorelli
is there any update, can we get a few more details on your particular issue?
morleymorley
Howdy,

we are experiencing exactly the same problem in our sandbox.

It was working fine for a very long time... then not working at all, there have been no changes to our code.

We can obtain a connection successfully, login and get a session id ... but when we try to use the session id in any subsequent transactions we receive the INVALID_SESSION_ID error message.

this problem seems to be common as there is another post with the same issue.
http://community.salesforce.com/sforce/board/message?board.id=NET_development&message.id=5766

Any help would be greatly appreciated... as previsouly stated.... this is extremley frustrating to have your applications suddenly stop working without receiving any details of the changes from SalesForce.


regards,
Adrian
pmorellipmorelli
Sorry to hear you're having problems. Please post as much information to help us fix this, or alternatively, file a case with support and post the number here so we can follow up.
SuperfellSuperfell
Do you have "Lock sessions to IP" enabled ?
morleymorley
Simon, we have tested our problem with the 'sessions locked to IP' option on and off and they both yeild the same results.

All of the details are.....

We currently have a java application that talks to salesforce using webservices.

We are able to log into salesforce and obtain a session id.... and until some time last week.... we were able to reuse this session id.

Now, when we try to use this session id to execute a subsequent web service call we receive the error "INVALID_SESSION_ID: Illegal Session ID found in SessionHeader: Illegal Session".

The subsequent calls are executed almost immediately after obtaining the session id... so the session has not exceeded the timeout as set in salesforce.

I'm more then happy to provide any further information anyone would like
just let me know what you would like to know.

thanks,
Adrian
SuperfellSuperfell
Have you logged a support case? if not, what's the username (just the username, don't need passwords or anything else) of the login that runs into this, and is this in production or sandbox ?
morleymorley
Hi Simon,

no we haven't logged a support case. The username is webapp@pctfiler.com and we are only receiving the error in the sandbox.

cheers,
Adrian
pmorellipmorelli
thanks for the info, we'll pass it along to the dev working on this issue.
pmorellipmorelli
could you confirm if you're still having this issue? We released a fix to our session id code saturday, and all old sessions should have cleared out by now...

thx.
morleymorley
Thanks Guys, it all appears to be working again now.

cheers,
Adrian
labaulabau
We are having a similar problem.  We are using a Java-based integration program, and it was working fine until the new API release.  The error message we get is: "UNKNOWN_EXCEPTION:  size of unauthenticated request is too large"  We logged a support case on Monday but haven't heard anything.  Does anyone have any hints on how to do a fix on our side?
SuperfellSuperfell
Sounds like you're sending a post login call (query, update, etc) to the www.salesforce.com endpoint instead of the endpoint returned by the login call. Can you get a complete capture of your request and the response (including the HTTP heaaders)
labaulabau

Hey Simon,

You can see an example of one of the faulty xml requests at:

http://www.rebuildresources.com/badrequest.xml

Thanks,
Josh

labaulabau
I actually just found the root of the problem - it was as you suggested.  The destination URL was getting screwed up.  Thanks for the tip!