Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 226866

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 SiteAssignee: John Sanda <jsanda>
Status: CLOSED CURRENTRELEASE QA Contact: Red Hat Satellite QA List <satellite-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: rhn500CC: inode0, mhicks, rhn-bugs, vgaikwad
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: wsd231 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-03-15 18:34:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
more failed login headers
removal of rh_sso coerced login failure headers
Failed login headers beginning with POST none

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, 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 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

After the failed attempt I see the following URL in my browser

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.


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
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,;jsessionid=sfFcL0hZ2Gam7Bem7HtbdPkBa4bPoRnbXO2.www02?<password>&<username>&

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

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).