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.
Priority: -- → P2
QA Contact: junruh → bmartin
Version: unspecified → 2.4
also a problem with 2003.02.28.10 bits --will check today's once it's passed smoketests.
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!
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).
waldemar: nope, it seems to be something different. sairuh tried a new profile w/ linux build 2003030308 and it did not work.
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.
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.
yes, i can also login if i use the acct # instead of the userid (after clicking through the "do it later" pages).
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
Priority: P2 → P1
Component: Client Library → Cookies
Product: PSM → Browser
Version: 2.4 → 1.0 Branch
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.
Comment on attachment 116399 [details] [diff] [review] regression fix sr=darin
Attachment #116399 - Flags: superreview?(darin) → superreview+
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.
thanks for the testing guys... and thanks for handing me the fix on a plate darin :) darin, can you check it in?
thx again timeless!
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
*** Bug 196324 has been marked as a duplicate of this bug. ***
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.
WFM on a trunk build from 3/7/2003. (Build ID: 2003030704)
bmartin: fixed-on-trunk. this was only a trunk regression.
vrfy'd fixed on linux rh7.2, 2003.03.07.10 comm trunk bits. thanks to darin and dan!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.