Wednesday, April 30, 2014

Custom Button connection.js: INVALID_SESSION_ID

After deploying a custom button from a sandbox to Production, I noticed that the button stopped working. Puzzled, I opened the Web Console in Firefox to find the following error message: INVALID_SESSION_ID.

I was not doing anything special with sforce.connection.sessionId in my code. All the button does is {!REQUIRESCRIPT('/soap/ajax/30.0/connection.js')} and move on to query and update the database. The same code was working fine in my sandbox still, so I figured the next best thing would be to actually look at sessionId to see what's wrong.

At first glance, sessionId looked like a perfectly fine mess of characters that are reasonable for a Session ID value.

00DG0000000krVL!ARQAQP3vNkwdt8OU3WVIjlAwQvWtGcFcIjWq.0jb7A5wYNljj6Oog50.wDma4uUiB.PeDMqx1mLwkMyGj78gyMGLRLGTxic1

Then, I compared sessionId to the sid cookie, and I noticed that the two values were very different.

00DG0000000krVL!ARQAQLWR697R.eqoAy4178kYPxh2kJGv6BOpv_wsHc6KBjY6UPY01.Rfncn6WAMS2klSm.gLvDOWicNKujfE4smTPBLJvyS5

Refreshing the page in my browser did nothing for the problem. The same two values consistently appeared, and the INVALID_SESSION_ID error consistently broke my code.

Finally, the fix was implemented in the form of additional JavaScript in a static resource. This resource, added using REQUIRESCRIPT() after connection.js, simply maps the cookies in the current document and then stores the sid value in sforce.connection.sessionId. The addition of this step resolved the INVALID_SESSION_ID error as far as I could tell.

Has anyone else ever encountered this issue, in Spring '14 or earlier? I feel like I've stumbled upon a bug, because as far as I know connection.js used in a custom button should not need this kind of "initialization".

3 comments:

  1. Marty,

    Curious to know! Did you try using the Merge Field: {!API.Session_ID} ?

    ReplyDelete
  2. Are you or anybody else experiencing this issue in Winter 15?

    ReplyDelete
    Replies
    1. Hello, @Peace_By_Arms, I have not encountered this in Winter '15. Have you tried the suggestion in Deepak's comment to use {!API.Session_ID}?

      Delete