unable to login to Schwab account

VERIFIED FIXED

Status

()

Core
Networking: Cookies
P1
critical
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: sairuh (rarely reading bugmail), Assigned: dwitte@gmail.com)

Tracking

({regression})

Trunk
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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.

Updated

16 years ago
Priority: -- → P2
QA Contact: junruh → bmartin
Version: unspecified → 2.4
(Reporter)

Comment 1

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

Comment 2

16 years ago
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

16 years ago
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

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

Comment 5

16 years ago
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

16 years ago
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.
(Reporter)

Comment 7

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

Comment 8

16 years ago
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.
Assignee: ssaux → dwitte
Flags: blocking1.4a?
Priority: P2 → P1
(Reporter)

Comment 9

16 years ago
->cookies
Component: Client Library → Cookies
Product: PSM → Browser
Version: 2.4 → 1.0 Branch
(Reporter)

Updated

16 years ago
Version: 1.0 Branch → Trunk
(Assignee)

Comment 10

16 years ago
Created attachment 116399 [details] [diff] [review]
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.
(Assignee)

Updated

16 years ago
Attachment #116399 - Flags: superreview?(darin)
Attachment #116399 - Flags: review?(danm)

Comment 11

16 years ago
Comment on attachment 116399 [details] [diff] [review]
regression fix

sr=darin
Attachment #116399 - Flags: superreview?(darin) → superreview+

Comment 12

16 years ago
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.

Updated

16 years ago
Attachment #116399 - Flags: review?(danm) → review+
(Assignee)

Comment 13

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

darin, can you check it in?
(Assignee)

Comment 14

16 years ago
thx again timeless!
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 15

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

Comment 16

16 years ago
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

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

Comment 18

16 years ago
bmartin: fixed-on-trunk.  this was only a trunk regression.
(Reporter)

Comment 19

16 years ago
vrfy'd fixed on linux rh7.2, 2003.03.07.10 comm trunk bits. thanks to darin and dan!
Status: RESOLVED → VERIFIED

Updated

16 years ago
Flags: blocking1.4a?
You need to log in before you can comment on or make changes to this bug.