53069 - cannot log into www.techfed.com web branch

Status: VERIFIED DUPLICATE of bug 54381

(SeaMonkey :: General, defect, P1)

Description

[Viswanath Ramachandran]

Using Seamonkey 2000091805 build, go to www.techfed.com. click on webbranch.
try and log in using your memebr number and pin. status bar shows "signing on
Now" but you nevere actually sign on.

this works in communicator and used to work in seamonkey.

thanks, Vishy

Comment 1

[Viswanath Ramachandran]

nominating for beta3, if not then please assign for rtm. we cannot ship like this.

Comment 2

[lchiang]

I assume this is a secure site?

junruh, can you give this a try?

Comment 3

[Viswanath Ramachandran]

yes it is.

Comment 4

[Doron Rosenberg (IBM)]

reporter - did you install PSM for mozilla/netscape 6?

Comment 5

[Viswanath Ramachandran]

well I installed a build that I got from ftp://sweetlou. and took recommended
install option. I presume that includes security.

Comment 6

[John Unruh]

This appears to be a javascript problem. After clicking on Sign On, I am asked 
to download a file of type application/x-msdownload. This window appeared 
behind the main window.
For Mac and Linux, after clicking on Sign On, I am not asked to save a file, but 
still cannot sign on anyway.

Comment 7

[Brendan Eich [:brendan]]

Why in the world did I get this bug?  It's almost certainly not a JS engine bug.

/be

Comment 8

[lchiang]

jar - can you help me triage to the right person?  I am still trying to get the 
hang of the components and assigning bugs.

Comment 9

[Jim Roskind]

I'm not sure of who to pass this along to.  In some cases, secure sites are very
picky about what SSL browsers they will allow to connect, so it's possible that
the site is actually turning us away (and for that I'm copying Bob Lord).
Another possibility is that this is network code related... and for that
thought, I'm copying Gagan.
Do either of you have suggestions for who should look into this?
Thanks,

Jim

Comment 10

[Asa Dotzler [:asa]]

In the case that we're being actively turned away by the site I'm adding
[e-mail] of the Evangelism component (I know evangelism is mostly
standards support but could probably be expanded).

Comment 11

[Gagan]

Hmmm... I am tempted to suggest that you try it with HTTP/1.1 switched off. You 
can do that with the pref--

user_pref("network.http.version", "1.0");

Comment 12

[John Unruh]

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

Comment 13

[John Unruh]

Adding rtm keyword. The behavior has not changed since my 9/19 comment. "After 
clicking on Sign On, I am asked to download a file of type 
application/x-msdownload. This window appeared behind the main window. 
For Mac and Linux, after clicking on Sign On, I am not asked to save a file, but 
still cannot sign on anyway. I expect to get a warning that the password is 
invalid, but instead I just get "WebBranch is verifying your sign on..."

Comment 14

[Viswanath Ramachandran]

I really think we need to raise this to dogfood+ and rtm need info status.
Who should own this. It makes me believe that form based signin on many HTTPS
sites will not work as expected. That is critical functionality!
thanks, Vishy

Comment 15

[Phil Schwartau]

Setting default QA -

Comment 16

[Bill Law]

Sounds like a dup of bug 54381.  Same "application/x-msdownload" business.  That
bug has a fix that might cover this case also, if their login script URL has a
.dll in it.

Gagan can verify, perhaps.

Comment 17

[Bob Lord]

Some web sites use servers which do not correctly implement SSL.  This problem 
causes the client and server to fail to negotiate the connection.  We're going 
to give junruh some tools which he can use to determine if a site has this 
particular problem.

Still, that's not exactly what we're seeing here.  I can't explain the 
"application/x-msdownload" aspect.  That behavior is not consistent with the 
server-side SSL bug.

Comment 18

[lchiang]

mscott - since you own bug 54381 and you have a patch, perhaps we can check your
system to see if this techfed logging bug is also fixed?

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

This problem is apparently not "TLS intolerance", the problem 
to which Lord alluded above.  I was able to connect to this 
server using a TLS-enabled client that followed the spec.

Comment 20

[Scott MacGregor]

this is a dup of 54381. Marking it as such. 

*** This bug has been marked as a duplicate of 54381 ***

Comment 21

[John Unruh]

Verified dupe.