24679 - Problems logging on to Etrade

Status: VERIFIED DUPLICATE of bug 40449

(Core :: Security, defect, P3)

Description

[Tom Everingham]

Overview Description:  Cannot log in without getting a warning about
 using a cached login page.  When you select the supplied link to 
'Logout' you can then access the etrade site.  This happens only 
during the first attempt at logging in.  

Steps to Reproduce:
1.) Go to etrade site
2.) Login with user name / password 
3.)

Actual Results:  Get message that you can not log in from cached page.   

Expected Results:  I shouldn't get this message and should be able to 
access etrade.  

Build Date & Platform Bug Found:
2000012108 NT

Additional Builds and Platforms Tested On:
seems to work on linux, can't test the mac presently
Additional Information:

Comment 1

[Tom Everingham]

re-assigning QA contact to myself.

Comment 2

[Doug Turner (:dougt)]

setting milestone optimistically.

Comment 3

[Doug Turner (:dougt)]

adding beta1 keyword and setting m14 checkpoint.

Comment 4

[leger]

Putting on PDT+ radar for beta1.

Comment 5

[Doug Turner (:dougt)]

I have see this but is hard to reproduce.  are you using single signon?  

Comment 6

[Tom Everingham]

yeah, I was using single sign on.  Haven't been able to reproduce this
with it disabled.

Comment 7

[Doug Turner (:dougt)]

From what I can gather:

There are three cookies being set on the client.  The first is for the form 
element.  The second is a cookie that describes the session:

<set-cookie> <gx_session_id_User_login_session=62c49d0e026ce2d8>

This gets set on both commercial mozilla or netscape 4.7.  The next cookie is 

<set-cookie> <etcustomer=XXXXXXXXXXXXXXXXXXXXXX; secure>

(there is real data in this, but I do not know how secure it is so I X'ed 
it out)  This however, is only set when a successful login happens.  When 
running 4.7, I get this cookie set every time.  If I run with mozilla, I only 
get this cookie set on the second attempt.  What happens instead is the 
gx_session_id_User_login_session is reset to another value and the etcustomer 
cookie is never set!

Now, here is why I think it is a site problem.  If I change my user agent 
string to what 4.7 is:

Mozilla/4.7 [en] (WinNT; U)

I can log in without any problems!


I have sent an email to seamonkey-internal and cartman-dev for contact 
information at etrade.  

Comment 8

[Doug Turner (:dougt)]

valeski, just mentioned that it might be the user agent string that we are 
sending without a security level.  testing.

Comment 9

[Doug Turner (:dougt)]

I tried:

Mozilla/5.0m13 (Windows; U; NT4.0; en-US)

(notice the 'U').  This did not work.

Comment 10

[Doug Turner (:dougt)]

I tried:

Mozilla/5.0m13 (Windows; U; NT4.0; en-US)

(notice the 'U').  This did not work.

Comment 11

[Gagan]

*** Bug 22974 has been marked as a duplicate of this bug. ***

Comment 12

[Doug Turner (:dougt)]

if I remove the milestone from the user agent I can log on sucessfully the 
first time.  

Comment 13

[Judson Valeski]

grabbing this one. I have a fix (to remove the milestone as part of the version 
string).

Comment 14

[ekrock's old account (dead)]

Hang on, folks; we may not necessarily want to strip this out of the builds so 
fast; here's some detail to help make the call.

Christine Begle is on the verge of publishing the formal mozilla user agent 
string proposal for public review. That proposal includes, immediately after the 
initial 5.xyz major/minor version (where xyz is zero-filled integers, e.g.
001), the option of appending an initial-alphabetic-char suffix such as "m13" or 
"b1". Such suffixes were put in the proposal to enable the designation of 
pre-release milestone or beta builds (but could be used for any purpose). 

This "suffix feature" of the user agent proposal has been put in on the 
assumption that it should not cause many client sniffers trouble, because: 
1) such suffixes have been used in the past, e.g. by Nav4.x betas 
2) most client sniffers use something like parseInt or parseFloat to get as much 
of the leading numbers as they care about; such sniffers won't be harmed by an 
initial-alpha suffix.  I don't recall any particular concerns about 
sniffer-compatibility being raised for the suffix proposal during the
thread on netlib. Even to a sniffer-compatibility fascist like myself, it seemed 
relatively safe at the time.

This assumption that suffixes will be sniffer-safe may or may not be correct. I 
*suspect* that etrade is a rare counterexample. There are only three possible 
things we can do to settle the question: 
1) put the suffix in our daily builds and test 
2) put the suffix in the M14 or M15 milestone and see if wide usage causes 
problems 
3) post cbegle's draft proposal for public review (this should happen any day 
now) 

If these suffixes are going to raise general hell, we *definitely* want to find 
out about it ASAP. Even if we don't want to jeopardize M14/beta1 with suffixes, 
we definitely want the suffix in as part of dailies and M15 if we're going to 
keep it as part of our formal userAgent string proposal.

In the meantime I will do the following: 
1) fix the sample text in the existing userAgent-notification template to be 
up-to-date and compliant with our proposal 
2) create a new notification template ("Update your client sniffer to be suffix 
friendly ...") to handle cases such as etrade's where the suffix turns out to 
cause a problem 

If the milestone suffix turns out to raise hell on many sites, then obviously 
we'll rev the userAgent proposal to come up with a solution.

Because we've discovered with etrade that this expected-to-be-harmless change 
can break at least one site, we may wish take the following approach:
a) take the suffix out for m14 and beta1 (to avoid jeopardizing the perception 
of beta)
b) put it in the dailies and in M15 to evaluate how widespread the problem is
c) decide based on feedback to dailies and M15 whether to keep suffixes as part 
of our proposal

Moral of the story: we can't be too conservative on backward compatibility when 
it comes to userAgent strings. 

Adding cbegle to the cc:.

Comment 15

[ekrock's old account (dead)]

Per jar's decision, acting for the PDT, valeski, please go ahead and remove the 
m13 string from Netscape's branded product. Netscape will decide whether it 
needs to differentiate its beta builds from its final product in the useragent 
string, and if so, we will do so in some way that avoids violating the mozilla 
useragent string specification and also avoids breaking major web sites.  I am 
opening a thread on n.p.m.netlib as in light of the etrade problem the 
mozilla.org community may choose to re-evaluate this part of the proposed 
specification.

Comment 16

[Judson Valeski]

just pulled it, if you want to test w/ a string after the app version, set this 
pref.

pref("general.milestone", "");

Comment 17

[Warren Harris]

Can we make that pref be useragent.milestone or perhaps useragent.minorversion?

Comment 18

[Jim Roskind]

The pref is a hack till we get a better handle on the agent string format.  IMO,
we shouldn't waste much time with this more than temporary pref.

Thanks,

Jim (PDT+ addict) Roskind

Comment 19

[leger]

Bulk moving all Browser Security bugs to new Security: General component.  The 
previous Security component for Browser will be deleted.

Comment 20

[Tom Everingham]

verified:
Commercial build WinNT 2000022108

Comment 21

[chriss]

I'm still seeing this bug as of today's commercial build. When I try to logon to
Etrade I get the same cach error bug. If I attempt to logout per etrade's link, 
I still can't log in.

This bug is intermittent however - I have on occassion been able to log in to 
etrade. But the majority of the time, including today, I can't log in.

Reopening bug.

Comment 22

[Judson Valeski]

over to doug per his request

Comment 23

[Doug Turner (:dougt)]

chriss,

Are you using a migrated profile?  Can you reproduce this?  If you can, please 
open up the Cookie Manage and tell me what cookie you have from the 
trading.etrade.com domain.  

A sure-fire workaround is to delete any cookies from this domain, and try again.  
Etrade has a three cookies it uses for a logon.  If any do not get set, or are 
wrong, you will not be able to log in.  

Comment 24

[Judson Valeski]

I verified that this is *not* a user agent string problem.

Comment 25

[Jim Roskind]

What is the status of this bug?  The last comment was last friday...
Are we going to have to release note access to etrade? :-(
Please update the status whiteboard with info, or suggest other folks that we
can get involved to get you some help.
Thanks,
Jim

Comment 26

[Doug Turner (:dougt)]

It looks like it is some timing issue.  If I stay a while on the login page 
(more than 10-30 seconds), I will not be allowed to log on.  On the other hand, 
if I login under a few seconds, it get on.  

still looking.

Comment 27

[Doug Turner (:dougt)]

I added code to http to print out all the requests/responses.  
I ran the same procedure twice, but differed on how long I 
would wait on the login page (if you wait too long, you can 
on log in).  On the "long delay" run, the responses are out 
of order.  I am not sure if this is related.  Here is that 
printout:

RESPONSE order for the sucessful login:

-----RESPONSE: <content-type> <image/gif>
-----RESPONSE: <pragma> <no-cache>
-----RESPONSE: <cache-control> <private, no-cache>
-----RESPONSE: <content-length> <43>
-----RESPONSE: <server> <Netscape-Enterprise/3.6 SP2>
-----RESPONSE: <date> <Thu, 09 Mar 2000 02:10:14 GMT>
-----RESPONSE: <requeststartsec> <952567814>
-----RESPONSE: <requeststartusec> <881319>
-----RESPONSE: <content-type> <image/gif>
-----RESPONSE: <connection> <close>

Here is the unsuccessful RESPONSE:

-----RESPONSE: <server> <Netscape-Enterprise/3.6 SP2>
-----RESPONSE: <date> <Thu, 09 Mar 2000 02:12:16 GMT>
-----RESPONSE: <requeststartsec> <952567937>
-----RESPONSE: <requeststartusec> <155468>
-----RESPONSE: <content-type> <image/gif>
-----RESPONSE: <connection> <close>
-----RESPONSE: <content-type> <image/gif>
-----RESPONSE: <pragma> <no-cache>
-----RESPONSE: <cache-control> <private, no-cache>
-----RESPONSE: <content-length> <43>

Note that the close is premature.  Also, I am unfamilar
with the http "requeststartsec".  Could we have a time
interval bug, (eg. minutes ?= seconds)

Also another interesting piece of data is that on a 
unsuccessful login, the *wrong* cookie is being set.
I am not sure how this could happpen on the client.

Successful RESPONSE (cookie change for my security):

-----RESPONSE: <set-cookie> <etcustomer=XXXXXXXXXXXXXXXXXXXXXX; secure>

Unsuccessful RESPONSE:

-----RESPONSE: <set-cookie> <gx_session_id_User_login_session=65bd28732cd5cd1a>

Comment 28

[Warren Harris]

You might want Gagan to own this one.

Comment 29

[Stephen P. Morse]

Doug, I see that you are using my added code to display the headers.  I wrote 
that at a time when the traceplus sniffer was not working with mozilla.  But 
mozilla has changed and it once again can be sniffed.  So try using traceplus 
and see what it has to say in the two cases.

Comment 30

[Doug Turner (:dougt)]

steve, I could not get traceplus to work with cartman.  When I send() to 
a traceplus(cartman), it never receives.

Comment 31

[Jim Roskind]

IMO, this should be release noted, as it seems like there is a work-around (and
it is unclear what the problem is).
Am I correct that you can *consistently* log in, so long as you don't "wait too
long" on the login page?  (Long defined to be "submit user name and password in
about 10-30 seconds).

Comment 32

[Doug Turner (:dougt)]

jar, you are correct: if you idle to long on the login page, you can not login. 

Gagan mentioned that this problem *might* be related to:

http://bugzilla.mozilla.org/show_bug.cgi?id=29610

Release noting this would be okay with me.  The last dozen trades that I have 
made have been using the netscape build.

Comment 33

[Jim Roskind]

This sounds like it could become a release note.
I'm removing the PDT+, to get a re-eval.

Comment 34

[leger]

Putting on PDT- radar for beta1.

Comment 35

[eford]

I have a similar problem, I try to login, it says I have to log out, I do, then
I can log in again.  I encounter it every time I start mozilla and go to
ETrade's home page.  I'm having the problem with the linux version, but it won't
let me change the OS field.

Comment 36

[Doug Turner (:dougt)]

per warren's comment a while ago, over to gagan.

Comment 37

[Warren Harris]

Moving to M15

Comment 38

[Warren Harris]

Moving to M17 which is now considered part of beta2.

Comment 39

[Judson Valeski]

I just logged in fine using the beta on winnt

Comment 40

[Eric Pollmann]

*** Bug 33367 has been marked as a duplicate of this bug. ***

Comment 41

[ruslan]

don't think it's our problem but we can take a look

Comment 42

[Eric Pollmann]

*** Bug 36860 has been marked as a duplicate of this bug. ***

Comment 43

[leger]

Putting on [NEED INFO].  ekrock, can you help us get an etrade contact to help 
us with this?

Comment 44

[ekrock's old account (dead)]

Jan, what kind of help do you want? A QA analyst? A sysadmin to provide info 
about their server? Please specify and then ask Dawn to try to track down a 
contact.

Comment 45

[ekrock's old account (dead)]

Clearing old [PDT-] from beta1 to trigger re-evaluation. Per clarification in 
seamonkey leads today, this qualifies as a nsbeta2 bug as it's a major service 
site.

Comment 46

[ruslan]

Please not that the browser is usable with E*Trade. You can always log in/log 
out. It would just display the status as "Logged in" and you'll have to log out 
and log in back. This sometimes happens with NS4 as well and it's most likely 
some tedious cookie parsing/syntax problem.

Comment 47

[Michael La Guardia]

putting on nsbeta2- radar.

Comment 48

[chris hofmann]

is the current build still usable on e-trade for most people.
Its not for me.  I saw the "your loading from cache..." message
first time, and then couldn't get http://www.etrade.com to load;
just got a never ending progress bar...  stopped the page load
after 439 seconds with no response...

Comment 49

[ruslan]

I can load it with the build which is 2 days old. It's definitely not the 
original problem

Comment 50

[ruslan]

Ok. Just been looking at the other bug while using eTrade - it seems like it 
only does this when the cache is being used and is not empty. We send 
if-modified-since on the page which is not cacheable and that how the thing 
determines that we're not doing the clean log in. Over to neeti

Comment 51

[chris hofmann]

taking the nsbeta2- off.  some good sized subset of the beta2 users not
being able to get on etrade would be bad.  I'd think we would
take a good low risk fix for this if one shows up on the table.

Comment 52

[leger]

Putting on [nsbeta2+] radar.

Comment 53

[leger]

Putting on 7/28 ETA...gagan to work with neeti on this.

Comment 54

[Gagan]

hey! this is a dup of bug 40449

*** This bug has been marked as a duplicate of 40449 ***

Comment 55

[Tom Everingham]

verif. Dupe