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 - Forced to log in twice when there is no prior session for the client
Summary: Forced to log in twice when there is no prior session for the client
Alias: None
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Web Site
Version: rhn500
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: John Sanda
QA Contact: Red Hat Satellite QA List
Depends On:
TreeView+ depends on / blocked
Reported: 2007-02-01 19:57 UTC by Máirín Duffy
Modified: 2007-04-18 17:59 UTC (History)
4 users (show)

Fixed In Version: wsd231
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-03-15 18:34:26 UTC
Target Upstream Version:

Attachments (Terms of Use)
more failed login headers (deleted)
2007-02-19 20:29 UTC, John T. Rose
no flags Details
removal of rh_sso coerced login failure headers (deleted)
2007-02-20 17:12 UTC, John T. Rose
no flags Details
Failed login headers beginning with POST (deleted)
2007-02-21 23:42 UTC, John T. Rose
no flags Details

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

Note You need to log in before you can comment on or make changes to this bug.