There are situations when your ServiceNow instance is up and operational but your users still cannot log in because they don't see the login page asking for a username and password. This article covers one of such situations where a user accesses a ServiceNow instance and, instead of the login page, the user is redirected to session_timeout.do. This redirection keeps on running in an infinite loop and you never see the login page.
Let's say your instance URL is https://instance.service-now.com and when you access it, you get redirected to https://instance.service-now.com/session_timeout.do infinite loop. This looks something similar to below image.
Troubleshooting the session timeout loop when logging in
When I began investigating this issue, my first attempt was to access the instance using side_door.do or let's say login.do to check if the default login displays. I was relieved to say, yes it does. As a workaround, users can access their instance using a suffix of login.do (https://instance.service-now.com/login.do) and bypass this issue. Now, Let's move further and look into this, ask ourselves what is it that is causing this issue and how to fix it.
Is the loop SSO related?
First I checked if Multi Provider SSO or old SAML plugin is enabled in the instance by verifying below system properties quickly:
Results from Multi Provider SSO: glide.authenticate.multisso.enabled
Results from SAML plugin: glide.authenticate.external
Both of the system properties appeared as false, which confirms this is not SSO related.
What can the transaction logs tell us?
Accessing an instance is also a type of transaction; therefore, I decided to check Transaction Logs where I see multiple transactions with below URLs one after another:
/nav_to_do?uri=welcome.do
/session_timeout.do
Transactions keep on generating as long as your browser is open because of infinite looping. In logs, I can see the related session as well as the node name. I checked the system logs considering Transaction Logs creation timings for keywords navpage.do and session_timeout.do transaction and this is what I see:
2017-07-07 14:25:27 (454) http-23 New transaction 3613CCCEDB73F2004159F37EAF96198D #25515 /navpage.do
2017-07-07 14:25:27 (460) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D #25515 /navpage.do Parameters -------------------------
2017-07-07 14:25:27 (460) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D *** Start #25,515, path: /navpage.do, user: guest
2017-07-07 14:25:27 (479) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D Memory transaction: 2mb total: 275mb free: 52% Allocated: 571mb
2017-07-07 14:25:27 (479) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D *** End #25,515, path: /navpage.do, user: guest, total transaction time: 0:00:00.025, transactio
n processing time: 0:00:00.025, network: 0:00:00.000, chars: 13, uncompressed chars: 13, SQL time: 12 (count: 5), business rule: 0 (count: 0), phase 1 form length: 0, largest
chunk written: 0, request parms size: 40, largest input read: 0
2017-07-07 14:25:27 (547) http-21 New transaction 3613CCCEDB73F2004159F37EAF96198D #25516 /sp/
2017-07-07 14:25:27 (552) Default-thread-55 3613CCCEDB73F2004159F37EAF96198D #25516 /sp/ Parameters -------------------------
id=login
2017-07-07 14:25:27 (554) Default-thread-55 3613CCCEDB73F2004159F37EAF96198D #25516 /sp/ -- total transaction time: 0:00:00.000, transaction processing time: 0:00:00.000, tot
al wait time: 0:00:00.000, session wait: 0:00:00.000, semaphore wait: 0:00:00.000, source: 86.90.145.21, chars: 0, uncompressed chars: 0, SQL time: 1 (count: 3), business rul
e: 0 (count: 0), phase 1 form length: 0, largest chunk written: 0, request parms size: 64, largest input read: 0
2017-07-07 14:25:27 (631) http-28 New transaction 3613CCCEDB73F2004159F37EAF96198D #25517 /session_timeout.do
2017-07-07 14:25:27 (708) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D #25517 /session_timeout.do Parameters -------------------------
2017-07-07 14:25:27 (708) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D *** Start #25,517, path: /session_timeout.do, user: guest
2017-07-07 14:25:27 (721) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D [0:00:00.012] getRealForm
2017-07-07 14:25:27 (726) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D Memory transaction: 4mb total: 281mb free: 51% Allocated: 571mb
2017-07-07 14:25:27 (726) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D *** End #25,517, path: /session_timeout.do, user: guest, total transaction time: 0:00:00.095, transaction processing time: 0:00:00.095, network: 0:00:00.000, chars: 6,023, uncompressed chars: 20,143, SQL time: 4 (count: 11), business rule: 0 (count: 0), phase 1 form length: 52,115, largest chunk written: 9,636, request parms size: 40, largest input read: 0
Log statements 09 to 14 in above logs explains that Service Portal execution is happening immediately after navpage.do which then leads to session_timeout.do.
The id=login is referring to Service Portal Login page which is not public. The private portal page causes the login attempt to time out on a loop. When I enable public is true for the Login page, the issue no longer appears. If setting the page to public does not help, kindly check the following:
- There must be an active record for page $sp in sys_public record list.
- Check system property glide.entry.page.script value and related script includes which should use this login page.
Out of the Box, System property glide.entry.page.script value is new CMSEntryPage().getEntryPage() but you can always replace it based on your business requirements.
Hope this helps!
For more information:
6 ways to set up your Service Portal for redirection SUCCESS!
2 Comments
