It's all about the answers!

Ask a question

What causes both the RQM and the RTC webUI to repeatedly prompt for a login which does not accept any credentials


long TRUONG (3654104140) | asked Sep 13 '13, 7:51 p.m.

There seems to be some issue with timeout with IE8 browser when using RQM (also RTC, not sure about RRC) where any new action would bring up a "bogus" login prompt repeatedly which would not accept any credentials, bona fide or bogus or blank, nor would it issue any error messages. 

 

·         This would seem to require closing all browsers and restart before you can get a real login prompt.

·         This happen infrequently, but the frequencies have been increasing. So far we cannot make it repeatable at will yet.

·         This seemed to happen with some pause in usage but independent of length of idleness, and there are times that the idle was infinitesimal.

·         We have found later that when this happens, the dashboard home would show This Server is offline or unreachable for all tools (ccm, qm, rm) similar to https://jazz.net/forum/questions/114895/personal-dashboards-shows-this-server-is-offline-or-unreachable

·         We also found that at the bottom of the dashboard home, “LifeCycle Project Admin” and “Jazz Team Server Home” are not greyed out like the rest.

·         If you click on “Jazz Team Server Home” your session may restart at the JTS home, it is more hits than misses, and you will avoid the pain of having to close out all browsers.

·         Also if we replace the server fully qualified name, in the URL, with the short name or its IP address, we may restart the app without having to close all browsers. The short name seem to be more effective than the IP address, but it;s still a hit and miss workaround.

·         One of our tester have the issue happened on the RQM most often around 11:00 AM.


Comments
long TRUONG commented Oct 24 '13, 9:47 a.m.

 Still working with IBM on  [PMR 37034,7TD,000] : CLM: Server connection lost at random: The issue is with all 3 tools (RTC, RQM, RRC) and JTS.


long TRUONG commented Oct 24 '13, 9:52 a.m.

And it happened with all 3 browsers IE8, Firefox 23, Chrome. 


long TRUONG commented Nov 06 '13, 5:27 p.m.

WAS option "Web inbound security attribute propagation" was unchecked, supposed to clear the issue with our “single login”, but issues continued to be observed. 

3 answers



permanent link
Antoinette Iacobo (650612) | answered Sep 16 '13, 11:31 a.m.
 Hi Long,

Do any of your users use other browsers besides IE8 (say Firefox or Chrome)?  Noting which browsers and version cause the behavior and which don't will help narrow down the issue. 

What is the public URI of this CLM deployment? Is it the short name?  The public URI is what users should consistently be putting in the browser to login.  I would follow the configuration check list in that link, have users clear their browser cache, clear the server cache and then have everyone consistently use that. Then recheck if the behavior appears. 



permanent link
Erica Tran (1.4k6) | answered Oct 25 '13, 7:50 p.m.
JAZZ DEVELOPER
Hi Long,

The behavior sounds like the issue mentioned in the following technote.  But this has a specific error that will appear in the log.  So if you don't see the error in the log, it something else.

Unable to authenticate with CLM application when LDAP referral parameter is set to true
http://www-01.ibm.com/support/docview.wss?uid=swg21645492




Comments
long TRUONG commented Oct 25 '13, 8:04 p.m.

 We are using WAS here Erica, not Tomcat. And if you follow up with Chris  Fleischer  [PMR 37034,7TD,000] you will see that this has taken over a month and he has pored over logs and logs. His clearing of cookies help to restart without having to close any instance of the browser


permanent link
long TRUONG (3654104140) | answered Nov 15 '13, 10:14 a.m.
edited Nov 15 '13, 10:15 a.m.
 This is the right answer but I won't be able to pick it as the answer, since it is my own answer to my own question.
Scope: this is an issue on all the Jazz tools including the WAS console where the tools are installed on, as it is related to WAS session management security, which is brand new to WAS 8.0.0.0, the version we use.
The cause and the fix: The security integration of the newly available session management on WAS 8.0.0.0 did not like our single sign-on. Hence, the feature, enabled by default at installation, has to be turned off (unchecked). A restart of the WAS is required to make this effective.

Your answer


Register or to post your answer.