195996 - unable to login to Schwab account

Status: VERIFIED FIXED

(Core :: Networking: Cookies, defect, P1)

Description

[sairuh (rarely reading bugmail)]

i'm no longer able to login to my Schwab.com account. using a linux (rh7.2)
build from 2003.02.21.05, this worked fine --but it's broken in a 2003.02.24.05
build.

i tested this with both an oldish (non-migrated) profile and a fresh profile,
and encountered the problem in both.

could this be related to bug 195574, or something else?

1. go to the schwab.com login page, https://investing.schwab.com/trading/start
2. enter my userid and passwd; didn't change the start page droplist or its
associated checkbox.
3. click Log In button.

results: get the following response:

"Your session has either timed out or has not been correctly established. Please
sign on again."

it's not a problem with my userid or passwd, as they have different error msgs
for those cases.

Comment 1

[sairuh (rarely reading bugmail)]

also a problem with 2003.02.28.10 bits --will check today's once it's passed
smoketests.

Comment 2

[Darin Fisher]

barrowman mentioned this same problem last night.  possibly cookies related.

waldemar: when you successfully logged into schwab yesterday (after switching to
a new profile), what version of the browser were you using?

sairuh: can you also try a new profile just as a blanket test.  thx!

Comment 3

[Waldemar Horwat]

Is this bug 195574 (see comments 13 and 14 there)?  Do you have the preference
Preferences:Privacy & Security:Master Passwords set to ask about the master
password every time it's needed?

Turning off that preference allows me to log into Schwab and other SSL sites
using a recent trunk Netscape build (I happen to be using 2003022403 today).

Comment 4

[Darin Fisher]

waldemar: nope, it seems to be something different.  sairuh tried a new profile
w/ linux build 2003030308 and it did not work.

Comment 5

[Darin Fisher]

so, i'm a little confused about when this bug started happening.  waldemar told
me that he is able to login to schwab using the 20030224 trunk build on mac osx,
but sairuh reports that that version of the build does not work for her. 
20030224 would have been the first build to include the patch for bug 177698. 
for a while i thought this might be duplicate of bug 195391, but the fix for
that bug landed on the 2nd, so the builds from the 3rd would have included that
patch.

sairuh said she'd send me some cookie logs, so we can look to see what might
have changed with cookie processing.

Comment 6

[Dave Barrowman]

This is the same as my bug.  There is a slight twist though:

- schwab is migrating users from numeric account ids to alphanumeric "names"
 (users have been asked to supply a username to replace their account #)
- if I log in with my numbered account, I get in fine; however, if I log in with
my new, prefered, named account, I get the error message.  

So it appears that they have two separate code paths.

Does not respond to changing user agent string.  I will sit with Darin to reproduce.

Comment 7

[sairuh (rarely reading bugmail)]

yes, i can also login if i use the acct # instead of the userid (after clicking
through the "do it later" pages).

Comment 8

[Darin Fisher]

OK, turns out the bug here is really trivial.  We are incorrectly applying the
constraint that a cookie may not exceed 4k bytes in length.  When signing into
schwab.com, more than 4k worth of cookies, taken together, is sent to the
browser.  The cookie module should limit the length of each individual cookie to
no more than 4k bytes, not all of the cookies taken together.

the check at nsCookies.cpp:1584 is broken since HTTP collapses each individual
Set-Cookie header into one single Set-Cookie header with newline delimiters. 
excessively large cookies need to be rejected at a lower level.

reassigning to dwitte.

Comment 9

[sairuh (rarely reading bugmail)]

->cookies

Comment 10

[[e-mail]]

Attachment: regression fix

this fixes this problem, and also a logging regression (while I'm in there):

a) moves the cookie size check to the correct place; and since we have the
parsed cookie attributes at that point anyway, we might as well check the (name
+ value) length instead of just the raw cookie header length. I think this is
slightly more sensible, since we ignore 'standard' attributes like expiry date,
domain, path etc and check just the cookie data size.

b) fixes a logging regression - after we parse the header, the cookie header
outparam contains the next cookie for processing (if there are multiple
cookies), for recursion purposes. I was passing that into
cookie_SetCookieString for logging, instead of the current cookieheader string,
so we end up logging the wrong header. this fix changes it so we pass in the
current cookie's header.

Comment 11

[Darin Fisher]

Comment on attachment 116399 [details] [diff] [review]
regression fix

sr=darin

Comment 12

[Darin Fisher]

i confirmed that this patch works by setting up a testcase which issues 10
Set-Cookie headers copied from the cookie logs given to me by sairuh.  without
this patch, none of the cookies were being set.  now all 10 are being set correctly.

Comment 13

[[e-mail]]

thanks for the testing guys... and thanks for handing me the fix on a plate 
darin :)

darin, can you check it in?

Comment 14

[[e-mail]]

thx again timeless!

Comment 15

[Jason Bassford]

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

Comment 16

[bmartin]

Has the fix been checked into the trunk or branch?

Sairuh, can you verify that this is fixed and that you can access your Schwab
acct? (I don't have a Schwab acct)

Thanks.

Comment 17

[Dave Barrowman]

WFM on a trunk build from 3/7/2003. (Build ID: 2003030704)

Comment 18

[Darin Fisher]

bmartin: fixed-on-trunk.  this was only a trunk regression.

Comment 19

[sairuh (rarely reading bugmail)]

vrfy'd fixed on linux rh7.2, 2003.03.07.10 comm trunk bits. thanks to darin and dan!