New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 9 users

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Oct 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 0
Type: Bug-Regression

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
link

Issue 101274: Login to Barrons Online fails (at least in Chrome 16.0 dev.)

Reported by mbeinh...@gmail.com, Oct 22 2011

Issue description

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 .....
 
BarronsLogin.jpg
97.6 KB View Download

Comment 1 by ahendrickson@chromium.org, Oct 24 2011

Labels: -Area-Undefined Area-Internals Internals-Network-Auth

Comment 2 by cbentzel@chromium.org, Oct 24 2011

Labels: -Internals-Network-Auth Feature-Passwords
This is forms-based authentication rather than HTTP authentication.

Comment 3 by isherman@chromium.org, Oct 24 2011

Cc: kirstenyee@chromium.org jtan@chromium.org
Labels: -Pri-2 Pri-1 Mstone-16 ReleaseBlock-Stable
Owner: isherman@chromium.org
Status: Assigned
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?

Comment 4 by Deleted ...@, 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?

Comment 5 by isherman@chromium.org, 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 :)

Comment 6 by kirstenyee@chromium.org, Oct 24 2011

Cc: karen@chromium.org

Comment 7 by kareng@google.com, Oct 25 2011

Cc: isherman@chromium.org
Labels: Regression
Owner: anan...@chromium.org
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.

Comment 8 by kareng@google.com, Oct 25 2011

anantha we needs eyes on this ASAP. I am getting info that says this is maybe not working on M15 either.

Comment 9 by anan...@chromium.org, Oct 25 2011

Owner: karen@chromium.org
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.

Comment 10 by kareng@google.com, Oct 25 2011

Labels: -Pri-1 -Mstone-16 Pri-0 Mstone-15
Owner: isherman@chromium.org

Comment 12 by bugdroid1@chromium.org, Oct 26 2011

Project Member
Labels: merge-merged-874_102
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
------------------------------------------------------------------------

Comment 13 by isherman@chromium.org, Oct 26 2011

Cc: agl@chromium.org wtc@chromium.org lafo...@chromium.org
Owner: wtc@chromium.org
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

Comment 15 by bugdroid1@chromium.org, Oct 26 2011

Project Member
Labels: merge-merged-874
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
------------------------------------------------------------------------

Comment 17 by laforge@google.com, Oct 26 2011

What do we need to do to fix 16?

Comment 18 by wtc@chromium.org, Oct 26 2011

Status: Started
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.

Comment 19 by kareng@google.com, Oct 26 2011

Labels: -Mstone-15 Mstone-16
fixed for 15, moving to 16.

Comment 20 by isherman@chromium.org, Oct 26 2011

Status: Fixed
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.

Comment 21 by jnshost...@gmail.com, 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.

Comment 22 by jnshost...@gmail.com, 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?

Comment 23 by leecook...@gmail.com, 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.

Comment 24 by mbeinh...@gmail.com, 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.

Comment 25 by anigbr...@gmail.com, Nov 8 2011

Affects wsj.com following cache purge on Chrome Dev-m 17.*. Works OK with IE8/9.

Comment 26 by thomasfi...@gmail.com, Nov 9 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

Comment 27 by isherman@chromium.org, Nov 9 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.

Comment 28 by bugdroid1@chromium.org, Oct 13 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 29 by bugdroid1@chromium.org, Mar 9 2013

Project Member
Labels: -Type-Regression -Area-Internals -Feature-Passwords -Mstone-16 Type-Bug-Regression Cr-Internals Cr-UI-Browser-Passwords M-16

Comment 30 by bugdroid1@chromium.org, Mar 13 2013

Project Member
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment