Are you using "Secure" with your cookies?  We somewhat recently changed things so that secure cookies can't be overwritten by insecure ones.

If that doesn't look to be the issue, could you please create an about:net-internals log of this happening?  https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details has instructions.  In this case, you'll need to enable cookie logging in the capture tab on the left.

To avoid leaking real cookies:
1)  Run Chrome with a fresh profile (Running it with --user-data-dir will do the trick, or you can temporarily install Chrome Canary, which will use its own profile.  Using incognito mode is not sufficient).  Alternatively, you can just delete all your cookies and restart Chrome, but obviously, you lose all your cookies in that case.
2) Don't try to log in with a non-test account.

Hi,

We only using secure with our cookies.


I am attaching the net-internal debug as reqested. Please review and let us know

Thanks'
Pavan

Deleted: net-internals-log.json.zip 2.7 MB

net-internals-log.json.zip 2.7 MB Download

There are 3200 URL requests in that file, making it a bit hard to figure out just what I should be looking for.  Which URLs should I be looking at requests for?

Please look at the URL "https://hi.service-now.com"

This is the URL that looses the JSESSIONID forcing a logout

Thanks
Pavan

I'm not seeing anything that looks wrong - a JSESSIONID of 9C99B5856F730E6800F6E8B0CE7EAC90 is set on that URL, and it's not changed until request 785463, where the server sets it to C576720897E08DE7C7450DB2A7E06F47, and it's set as expected on subsequent requests,  The request that actually set it to 9C99B5856F730E6800F6E8B0CE7EAC90 does not appear in the log.  What am I missing?

Note that some requests that were started after the request that ultimately updated the cookie used the old cookie, but that's because they were send out before we received the new cookie value.  I assume that's not the issue you're running into?

Hi,

JSESSIONID is not supposed to change as the user has not manually logged out of the application (https://hi.service-now.com). Since the JSESSIONID is changing the user is being redirected to a different node in the application cluster and the user is being forced to login again
In Firefox JSESSIONID for the same user actions does not change.In version of Chrome 53.0 and lower JESSIONID for the same user actions on (https://hi.service-now.com) did not change.

Can you please elaborate more on the request that is changing the JSESSIONID. Is this due to any changes in chrome > 53.0. Is there a new feature in later versions of chrome which our application has to handle internally?

Users started experiencing the issue after their chrome versions got upgraded. No related changes were made to out application (https://hi.service-now.com)

Thanks

I can't say why your server chooses to change the ID, I have no visibility into its code, and can't provide any support for it, or explain why its behavior may have changed.  Here are the request/response headers where it's changed.  You can see we send the old ID, and it tells us to use a new one:

t=172869 [st=  5]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=0]
t=172869 [st=  5]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                         --> GET /amb_session_setup.do HTTP/1.1
                             Host: hi.service-now.com
                             Connection: keep-alive
                             X-UserToken: 20b73120dba1ba000e3dfb651f9619b6006bafda2a8b6a70ff3100307336e203ecbb4c7e
                             User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
                             Content-type: application/json;charset=UTF-8
                             Accept: */*
                             DNT: 1
                             Referer: https://hi.service-now.com/incident.do?sys_id=e780b80fdb5572c0852c7a9e0f961930&sysparm_view=&sysparm_domain=null&sysparm_domain_scope=null&sysparm_record_row=3&sysparm_record_rows=4&sysparm_record_list=active%3dtrue%5eassigned_to%3djavascript%3ags.getUserID()%5eu_last_commRELATIVELE%40dayofweek%40ago%404%5eu_problem_managerISEMPTY%5estate!%3d3%5eORDERBYu_last_comm
                             Accept-Encoding: gzip, deflate, sdch, br
                             Accept-Language: en-US,en;q=0.8,vi;q=0.6
                             Cookie: glide_user_activity="U0N2MjpKNHdmb0FPdGNtdGZoQWp0dmJOTW1PSGszWDEvWEpHaQ=="; glide_user_route=glide.41fc3b3c3c0f13a062012e8c19c77289; JSESSIONID=9C99B5856F730E6800F6E8B0CE7EAC90; glide_session_store=ECB73120DBA1BA000E3DFB651F9619B5; BIGipServerpool_hi=2692751882.33086.0000; BAYEUX_BROWSER=f3b4a0l7ejpp5kiwj08ezqdw1c50
t=172869 [st=  5]     -HTTP_TRANSACTION_SEND_REQUEST
t=172869 [st=  5]     +HTTP_TRANSACTION_READ_HEADERS  [dt=199]
t=172869 [st=  5]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=199]
t=173068 [st=204]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                         --> HTTP/1.1 401 Unauthorized
                             Set-Cookie: JSESSIONID=C576720897E08DE7C7450DB2A7E06F47;Secure; Path=/; HttpOnly
                             WWW-Authenticate: none
                             X-TRANSACTION-TIME-MS: 6
                             X-TRANSACTION-TIME: 0:00:00.006
                             Transfer-Encoding: chunked
                             Date: Mon, 13 Mar 2017 18:00:29 GMT
                             Server: ServiceNow
                             Strict-Transport-Security: max-age=15768000; includeSubDomains;
                             Connection: close
t=173068 [st=204]     -HTTP_TRANSACTION_READ_HEADERS

Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot