|Summary:||Forced to log in twice when there is no prior session for the client|
|Product:||Red Hat Network||Reporter:||Máirín Duffy <duffy>|
|Component:||RHN/Web Site||Assignee:||John Sanda <jsanda>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Red Hat Satellite QA List <satellite-qa-list>|
|Version:||rhn500||CC:||inode0, mhicks, rhn-bugs, vgaikwad|
|Fixed In Version:||wsd231||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-03-15 18:34:26 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Máirín Duffy 2007-02-01 19:57:42 UTC
Description of problem: "The first time I try to login to RHN using the corporate account it always fails without comment quickly returning me to the login screen. This happens from multiple networks and with both seamonkey and firefox. The second time I login always works fine and subsequent relogins during the day also work fine." "This behavior also began with the last RHN update [mo note: this text is from 20-Nov] but I didn't report it right away thinking I may have mistyped my credentials. I've done it often enough with enough care now that I'm sure something other than me is causing the problem." Version-Release number of selected component (if applicable): 4.15 was released 7 Nov 2006 4.16 was released 28 Nov 2006 It seems this issue started with the 4.15 release, but is still present in 4.16.
Comment 4 John Sanda 2007-02-12 14:34:42 UTC
Immediately after login when a user is sent to YourRhn.do, there are a number of queries that run. Some of these queries may not scale well for customers such as Iowa State due to the volume of systems that they have. With all of the queries that I have seen, we do not not limit or page the result set before it is sent back from the database. I suspect this to be the case as well for the queries on YourRhn.do. There needs to be some further analysis to determine which if any of these queries is in fact creating a bottleneck. I'm not sure if this work will make it into the 5.0 release. I will find out and update the bug report.
Comment 5 John Sanda 2007-02-14 15:18:08 UTC
After some discussion and clarification, I found that the issue he is not performance related as described in comment #1. I was informed from the customer that the problems only seems to manifest itself during the first login attempt of the day. Customer agreed not to log in this morning so that I could make the first login attempt to try and reproduce the bug. I logged in at 7:15 am without any problems. Need to further investigate potential client-side issues.
Comment 6 John T. Rose 2007-02-14 15:57:54 UTC
Testing again this morning after your login worked, mine failed again. Here is more bad news about this. The URL I try to login at is https://www.redhat.com/wapps/sso/rhn/login.html?redirect=https%3A%2F%2Frhn.redhat.com%2Frhn%2FYourRhn.do After the failed attempt I see the following URL in my browser https://www.redhat.com/wapps/sso/rhn/login.html?XXXXXXXXXX&YYYYYYYYYY&https://rhn.redhat.com/rhn/YourRhn.do&Log%20In&login-flow where the XXXXXXXXXX is my password and the YYYYYYYYYY is my account name. I can confirm from this that I am indeed correctly typing my password but I would prefer it not be exposed in plaintext in the URL in my browser. John
Comment 10 John Sanda 2007-02-20 17:58:58 UTC
I have been able to consistently reproduce the reported behavior with the following steps: 1) Go to https://rhn.redhat.com 2) Clear your browser cookies 3) Enter your username/password and submit the login form This bring me immediately back to the login page and URL in the address looks like, https://www.redhat.com/wapps/sso/rhn/login.html;jsessionid=sfFcL0hZ2Gam7Bem7HtbdPkBa4bPoRnbXO2.www02?<password>&<username>&https://rhn.redhat.com/rhn/YourRhn.do&Log%20In&login-flow where <username> and <password> are the username and password I entered into the login form. I have reproduced this in webdev as well as in prod with multiple usernames. Note that the steps described deviate slightly from those taken by the customer to produce the bug. The customer's browser preferences are set to only retain cookies for the duration of the current browser session. And the behavior encountered by the customer occurs during first login of the day, after closing out his browser the night before.
Comment 12 John T. Rose 2007-02-21 23:42:56 UTC
Created attachment 148548 [details] Failed login headers beginning with POST I don't know if this one is helpful but I'm hoping. It did not occur in the normal way this happens to me exactly, but does begin with the POST (which I think was desired?).
Comment 13 Máirín Duffy 2007-02-28 18:59:59 UTC
this is related to sso bug 229385. as a quick update, a fix for this bug is currently aligned to the rhn 5.01 release; the fix for related bug 229385 is currently aligned to the wsd 231 release (~time of rhel 5's release).