| Issue 101274: | Login to Barrons Online fails (at least in Chrome 16.0 dev.) | |
| 9 people starred this issue and may be notified of changes. | Back to list |
Sign in to add a comment
|
Chrome Version : 16.0.912.4 (Official Build 106469) dev URLs (if applicable) : https://commerce.barrons.com/auth/login OR login fields on http://online.barrons.com/home-page. Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 5: OK Firefox 7.x: OK What steps will reproduce the problem? 1. Enter username and password in attempt to log in on either web page. What is the expected result? Successfully log in and get report that "Your User Name and Password have been Saved" What happens instead? Returns to page: https://commerce.barrons.com/auth/login. and prompts for login again. Please provide any additional information below. Attach a screenshot if possible. I phoned Barrons help:800-544-9422. I eventually was told that it was a problem with the "latest version of Chrome" and was "a known bug." However, I did not find it under "Open issues" here. Back to Firefox 7 .....
Comment
1
by
ahendric...@chromium.org,
Oct 24, 2011
Labels: -Area-Undefined Area-Internals Internals-Network-Auth
,
Oct 24, 2011
This is forms-based authentication rather than HTTP authentication.
Labels: -Internals-Network-Auth Feature-Passwords
,
Oct 24, 2011
Thank you for the reprot. Kirsten, Julia, do either of you have time to follow up with Barron's to get a clearer picture of what the underlying issue here is?
Status: Assigned
Owner: isherman@chromium.org Cc: kirsten...@chromium.org j...@chromium.org Labels: -Pri-2 Pri-1 Mstone-16 ReleaseBlock-Stable
,
Oct 24, 2011
Hi Ilya, Normally Karen handles 3P compat issues, but I can help out if Karen is not able to tackle this immediately. Karen - Do you prefer to reach out to Barron's or should we? Ilya - Do you mind being copied as well in case there is any eng expertise required?
,
Oct 24, 2011
Thanks, Kirsten. Did you mean to cc Karen on this bug? I don't think I see her email on the cc list. Definitely feel free to copy me on the communication :)
,
Oct 24, 2011
(No comment was entered for this change.)
Cc: ka...@chromium.org
,
Oct 24, 2011
barrons online is US: 1-800-544-0422 anantha, this works in M14 so its a regression, can we get someone from QA to buy a sub if we need to so we can create a reduction? ilya can then take a look.
Owner: anan...@chromium.org
Cc: isherman@chromium.org Labels: Regression
,
Oct 25, 2011
anantha we needs eyes on this ASAP. I am getting info that says this is maybe not working on M15 either.
,
Oct 25, 2011
Just tested on Windows and found that we are able to login into barrons with M14, but not with M15. Ping me if you need login info.
Owner: ka...@chromium.org
,
Oct 25, 2011
(No comment was entered for this change.)
Owner: isherman@chromium.org
Labels: -Pri-1 -Mstone-16 Pri-0 Mstone-15
,
Oct 25, 2011
Regression range: http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=97269:97275 I'm guessing this was caused by http://src.chromium.org/viewvc/chrome?view=rev&revision=97269
Labels: -Type-Bug -Regression Type-Regression
,
Oct 25, 2011
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=107267
------------------------------------------------------------------------
r107267 | wtc@chromium.org | Tue Oct 25 18:10:44 PDT 2011
Changed paths:
M http://src.chromium.org/viewvc/chrome/branches/874_102/src/net/third_party/nss/ssl/ssl3con.c?r1=107267&r2=107266&pathrev=107267
Revert 104483 - Merge 104119 to 874 (manual merge)
We need to disable 1/n-1 record splitting on the 874_102 branch
for the Chrome Stable channel.
net: disable 1/n-1 record splitting when False Start is disabled.
Brocade SSL terminators are intolerant to 1/n-1 record splitting as well. For
the sake of getting M15 out the door, this patch uses the False Start blacklist
in order to switch off 1/n-1 record splitting too. This is deeply unfortunate
but will be reverted on trunk as soon as it can be merged to M15.
TBR=agl@chromium.org,isherman@chromium.org
BUG=101274
Review URL: http://codereview.chromium.org/8391030
------------------------------------------------------------------------
Labels: merge-merged-874_102
,
Oct 25, 2011
Status: wtc is reverting the CBC changes for M15. We're going to need to figure out what we want to do for M16. The ideal solution is to get Barron's to fix their servers, if possible. Here's some background on the reason for the CBC change -- which is intended to prevent a security exploit -- for those who are interested: http://www.imperialviolet.org/2011/09/23/chromeandbeast.html
Owner: wtc@chromium.org
Cc: a...@chromium.org lafo...@chromium.org wtc@chromium.org
,
Oct 25, 2011
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=107269
------------------------------------------------------------------------
r107269 | wtc@chromium.org | Tue Oct 25 18:21:42 PDT 2011
Changed paths:
D http://src.chromium.org/viewvc/chrome/branches/874_102/src/net/third_party/nss/patches/cbcrandomiv.patch?r1=107269&r2=107268&pathrev=107269
M http://src.chromium.org/viewvc/chrome/branches/874_102/src/net/third_party/nss/README.chromium?r1=107269&r2=107268&pathrev=107269
M http://src.chromium.org/viewvc/chrome/branches/874_102/src/net/socket/ssl_client_socket_unittest.cc?r1=107269&r2=107268&pathrev=107269
M http://src.chromium.org/viewvc/chrome/branches/874_102/src/net/third_party/nss/ssl/ssl3con.c?r1=107269&r2=107268&pathrev=107269
M http://src.chromium.org/viewvc/chrome/branches/874_102/src/net/third_party/nss/patches/applypatches.sh?r1=107269&r2=107268&pathrev=107269
Revert 97269 - Send only one byte of data in the first CBC encrypted
aplication data record.
We need to disable 1/n-1 record splitting on the 874_102 branch for
the Chrome Stable channel.
This randomizes the IV in a backward compatible manner.
TBR=agl@chromium.org,isherman@chromium.org
BUG=101274
Review URL: http://codereview.chromium.org/8393035
------------------------------------------------------------------------
,
Oct 25, 2011
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=107271
------------------------------------------------------------------------
r107271 | wtc@chromium.org | Tue Oct 25 18:30:58 PDT 2011
Changed paths:
M http://src.chromium.org/viewvc/chrome/branches/874/src/net/third_party/nss/ssl/ssl3con.c?r1=107271&r2=107270&pathrev=107271
Revert 104483 - Merge 104119 to 874 (manual merge)
We need to disable 1/n-1 record splitting on the 874 branch
for the Chrome Stable channel.
net: disable 1/n-1 record splitting when False Start is disabled.
Brocade SSL terminators are intolerant to 1/n-1 record splitting as well. For
the sake of getting M15 out the door, this patch uses the False Start blacklist
in order to switch off 1/n-1 record splitting too. This is deeply unfortunate
but will be reverted on trunk as soon as it can be merged to M15.
TBR=agl@chromium.org,isherman@chromium.org
BUG=101274
Review URL: http://codereview.chromium.org/8394027
------------------------------------------------------------------------
Labels: merge-merged-874
,
Oct 25, 2011
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=107273
------------------------------------------------------------------------
r107273 | wtc@chromium.org | Tue Oct 25 18:35:18 PDT 2011
Changed paths:
M http://src.chromium.org/viewvc/chrome/branches/874/src/net/third_party/nss/ssl/ssl3con.c?r1=107273&r2=107272&pathrev=107273
M http://src.chromium.org/viewvc/chrome/branches/874/src/net/socket/ssl_client_socket_unittest.cc?r1=107273&r2=107272&pathrev=107273
M http://src.chromium.org/viewvc/chrome/branches/874/src/net/third_party/nss/patches/applypatches.sh?r1=107273&r2=107272&pathrev=107273
D http://src.chromium.org/viewvc/chrome/branches/874/src/net/third_party/nss/patches/cbcrandomiv.patch?r1=107273&r2=107272&pathrev=107273
M http://src.chromium.org/viewvc/chrome/branches/874/src/net/third_party/nss/README.chromium?r1=107273&r2=107272&pathrev=107273
Revert 97269 - Send only one byte of data in the first CBC encrypted
aplication data record.
We need to disable 1/n-1 record splitting on the 874 branch for
the Chrome Stable channel.
This randomizes the IV in a backward compatible manner.
TBR=agl@chromium.org,isherman@chromium.org
BUG=101274
Review URL: http://codereview.chromium.org/8395034
------------------------------------------------------------------------
,
Oct 26, 2011
What do we need to do to fix 16?
,
Oct 26, 2011
laforge: for Chrome 16, we should help the affected websites track down the problem and fix their code. We should not disable 1/n-1 SSL record splitting on the Chrome 16 branch.
Status: Started
,
Oct 26, 2011
fixed for 15, moving to 16.
Labels: -Mstone-15 Mstone-16
,
Oct 26, 2011
Barron's has updated their site, and secure sign-in is now working with 1/n-1 SSL record splitting -- tested on 16.0.912.4 (Official Build 106469) dev.
Status: Fixed
,
Oct 27, 2011
This was also happening elsewhere with thier WAF inline (Apache Proxy) and with a client having installed Chrome beta version 15.0.874.102 beta-m but as soon as it was updated to 15.0.874.106 the problem is not reproducable. Hope this helps in your diagnostics.
,
Oct 27, 2011
"Barron's has updated their site, and secure sign-in is now working with 1/n-1 SSL record splitting -- tested on 16.0.912.4 (Official Build 106469) dev." What did Barron's update, exactly?
,
Oct 27, 2011
Barron's and WSJ implemented a reverse proxy strategy mentioned in the bug report for cherokee here: http://code.google.com/p/cherokee/issues/detail?id=1284 This works in both the updated 15...106 and the unpatched 15...102 and dev channel version 16. Other sites using older web server code may still have a problem, though.
,
Oct 27, 2011
Thanks to all of you for your prompt attention to this bug. It may be worth noting that the WSJ and Barron's use essentially the same interface and, apparently, involve the same subscription office at Dow-Jones. Yet this bug was peculiar to Barron's and not to the WSJ.
,
Nov 8, 2011
Affects wsj.com following cache purge on Chrome Dev-m 17.*. Works OK with IE8/9.
,
Nov 8, 2011
This issue looks to be the cause of my inability to log into https://www.halifax-online.co.uk/personal/logon/login.jsp . Upon trying to log in, I'm returned to https://www.halifax-online.co.uk/personal/logon/login.jsp with the message "We're sorry, but the details you entered aren't in the right format. Please check them and try again." Chromium version: 17.0.928.0 (Developer Build 108431 Linux) Ubuntu 11.10 I am able to log in fine when using: * Firefox 7.0.1 (on Linux), or * Opera 11.52 (on Linux) * Android 2.2's browser
,
Nov 8, 2011
Everyone, please note that this bug is specific to Barrons.com, and is closed as fixed. If you are having issues logging into other websites, please file separate bugs. Also, if the cause is the 1/n-1 SSL record splitting described here, the bug is actually with the website you are trying to log into. In that case, please contact the website owners and ask them to update their website. |
||||||||||
| ► Sign in to add a comment | |||||||||||
