Closed
Bug 57537
Opened 24 years ago
Closed 23 years ago
Can't log into WellsFargo (browser sniffing)
Categories
(Tech Evangelism Graveyard :: English US, defect, P3)
Tech Evangelism Graveyard
English US
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: pierre, Assigned: arun)
References
()
Details
(Keywords: ecommerce, Whiteboard: [BANK][USERAGENT][DENY][PROPRIETARY-DOM])
- Go to http://www.wellsfargo.com
- Click "Sign On" (in the top right corner)
==> You get a page saying " YOU MUST UPGRADE YOUR BROWSER"
Their list of approved browsers is:
http://www.wellsfargo.com/per/services/browser/chart/
Assigned to ekrock because that can't be fixed without some serious talking with
them (and testing on their side too, I guess).
Comment 1•24 years ago
|
||
Same problem with 2000-10-20-09 trunk on Linux. According to their list of
supported browsers, they simply don't support mozilla. Platform->All, OS->All.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Comment 3•24 years ago
|
||
As I indicated in Bug 57904, it happens with other sites as well. I gave
another example in that bug. Mozilla should be capable of telling a site it is
ns4 since it is the future version of ns. Perhaps an enhancement to be able to
give a specified site a specified browser string.
Comment 4•24 years ago
|
||
> Mozilla should be capable of telling a site it is ns4 since it is the future
> version of ns.
No. This would be a disastrous mistake because it would mislead client sniffing
code into delivering/executing code that is Nav4-specific. Even in pages that
had been upgraded to support the W3C DOM, a misleading UA string would cause
JavaScript code in web pages to think it was running on Nav4 and then try to
execute Nav4-only code forks with things like document.layers[], leading to
errors. Server-side sniffers would similarly dish out pages optimized for Nav4
rather than pages optimized for W3C standards supported in Gecko. You can go
here to read more about client DOM differences and the implications for client
sniffing:
http://sites.netscape.net/ekrock/standards.html
http://developer.netscape.com/viewsource/krock_v5.html
http://developer.netscape.com/docs/examples/javascript/browser_type.html
> Perhaps an enhancement to be able to give a specified site a specified
> browser string.
No, this would be an administrative albatross and a fatally doomed approach.
Suppose we tweaked the product to spoof Wells Fargo and then they upgraded their
content--then what?
The simple, correct solution to this problem is for web sites to update their
accepted UA lists to include Mozilla/N6.
Isn't this a DUP of another bug in which this was already reported?
--> Blake for evangelism.
Assignee: ekrock → blakeross
Comment 5•24 years ago
|
||
It would not be so "disasterous" to send a browser string that tells the site
moz is ns4 even if it doesn't support every littke ns4 feature. The worst that
would happen is it wouldn't work and the user can't use moz/ns6. There is a
chance it will work for some sites which would at least give moz/ns6 a fighting
chance.
I think it is a fatal mistake for moz/ns6 not to support ALL web sites supported
by ns4. At least mozilla should have a "ns4 mode" which could be enabled on a
per-site basis if there are some ns4 features that are not compatible with
standards. In this mode, moz/ns6 would tell the site it is ns4 and then support
all the extentions, behavior, etc supported by ns4.
I think you under-estimate how many sites require ns4 and the huge undertaking
to get all these sites to support pure moz/ns6.
If my suggestions are not implemented, we will be stuck with ns4 for a very long
time and moz/ns6 will rot on the shelves.
In any case, it is obvious now that moz/ns6 is not ready for prime time, since
implementing all ns4 features with a "ns4 mode" is probably not a small task.
Unless I see something positive in this bug, I will erase mozilla from my system
and give up. There are just too many web sites (most banks, I bet and possibly
many other web sites conducting serious business) that require ns4, making
moz/ns6 useless.
Comment 6•24 years ago
|
||
What? Your logic is nonsensicle here.
>The worst that would happen is it wouldn't work and the user can't use moz/ns6.
Hmm. Not being able to use the browser doesn't seem too good to me. How about
you?
Comment 7•24 years ago
|
||
Exactly my point. That's why I stressed moz/ns6 must be able to support all ns4
functionality or it is useless (by default or with a setting on a per-site
basis). That is what my second paragraph is all about.
Some sites will work now with mozilla just fooling the site to believing it is
ns4 because some (if not most) probably only care if you are running IE or ns in
order to use MS specific features or not (like ActiveX controls, VB scripts,
etc).
Reporter | ||
Comment 8•24 years ago
|
||
Moz should not present itself as Nav4, no browser ever did that. IE5 doesn't say
"I'm IE4", IE4 doesn't say "I'm IE3" and IE3 doesn't say "I'm Netscape 1.0".
There wouldn't have been any progress on the Web in the past 7 years.
These sites will upgrade their code. They knew when they wrote it that it would
become obsolete.
Comment 9•24 years ago
|
||
You are nit picking. OK then, mozilla should say it is ns6 and it should
support everything ns4 did. Most (if not all) sites only care that the browser
is ns and >= 4 and they (correctly) expect ns6 to work.
If mozilla doesn't do that, then I cannot use mozilla for any serious work.
If ns6 does this and moz doesn't, then they will be different browsers and
mozilla is useless.
Comment 10•24 years ago
|
||
With all due respect, I think you are basing your position on misinformed
ideas. Mozilla will not and will never deliberately disguise itself as
Netscape 6, because Mozilla is an open-source browser, whereas Netscape is a
vendor based off Mozilla source code. Mozilla is Mozilla, not Netscape, and to
say otherwise would be to undo years of struggling to get that point across to
the public.
We already have a quirks mode to help ease the transition between the current,
non-standard and largely propietary state of the web and the strict, standard
web that Gecko will hopefully someday bring about. The point, as Pierre says,
is that if we are so lenient in parsing that we accept and support everything,
there will be no incentive for webmasters to update their sites to W3C specs.
Considering standards are at the heart of Mozilla and its parsing and layout
engines, I don't quite think this is `nit-picking' as you put it.
You say that `If ns6 does this and moz doesn't, then they will be different
browsers and mozilla is useless.' That's great! Mozilla and Netscape ARE
different browsers. They might look similar now, but Mozilla will continue to
be driven by the open-source community, while Netscape will continue to be
diverge as necessary to comply with Netscape's interests as a company. I fail
to understand your point that `mozilla is useless' if it isn't Netscape, but
since you provide no explanation or anything to back that up, I won't bother
responding to it.
In reality, if every browser complied to the standards to the extent that
Mozilla 1.0 and Netscape 6.0 will, these Javascript browser-sniffing hacks
would no longer be necessary, because everyone would support the same thing.
That is, of course, in an ideal world. Someone needs to take a risk and let
themselves fail these browser-sniffing hacks in the name of standards. That's
what we're doing.
I am sorry you feel that Mozilla cannot be used your serious work unless it
identifies itself as Netscape. Feel free to use Internet Explorer, the browser
which, after NS 6.0 and MZ 1.0 are on the market, will basically be the browser
still forcing the JavaScript-sniffing hacks which are causing you problems.
Status: NEW → ASSIGNED
Comment 11•24 years ago
|
||
(Of course, the Javascript-sniffing hacks will probably be around for awhile
for backwards compatibility. But the point remains.)
Comment 12•24 years ago
|
||
and this is still a problem with Netscape6 [candidate] bits: 1000.30.09/8-n6
commercial branch bits.
Comment 13•24 years ago
|
||
59593 is a simple dup of this bug, bug owners should
decide which to keep.
Comment 14•24 years ago
|
||
*** Bug 59593 has been marked as a duplicate of this bug. ***
Comment 15•24 years ago
|
||
mcaffe: I marked the new bug as a dup of this one because this one has
more comments.
Comment 16•24 years ago
|
||
-> evangelism@telocity.com for my evangelism bugs.
removing the now-depreciated evangelism-related keywords.
setting platform to All.
Assignee: blakeross → evangelism
Status: ASSIGNED → NEW
Comment 17•24 years ago
|
||
*** Bug 52643 has been marked as a duplicate of this bug. ***
Comment 18•24 years ago
|
||
This if from wellsfargo.com's faq:
Q: How soon can I use a new browser to bank online?
A: Under normal circumstances, Wells Fargo will support the final version of a
new browser approximately two weeks after the final release date
So how is it that Netscape 6.0 which has been out for a couple months now isn't
supported?
Comment 19•24 years ago
|
||
The problem here is wellsfargo doesn't want to support Netscape 6/Mozilla
because they don't like that the password manager can not be turned off. They
don't believe that is secure enough for them.
Depends on: 63961
Comment 20•24 years ago
|
||
*** Bug 66842 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
Just tried to log in and got this wonderful message:
Attention Netscape 6.0 users: At this time we do not support Netscape 6.0
because it does not meet our strict security guidelines. We are working hard to
change this situation and hope to support it soon. Until a solution is found we
suggest using an earlier version of Netscape or Internet Explorer.
Are they really working hard on this? Has anyone recieved any communication
from them trying to resolve the problem?
re: jelwell's comment on the wallet/password manager... IE has the same thing
right? They just let you turn it off? To me "Never remember passwords for this
site" seems like an acceptable policy. Especially when you consider that most
people's pins for the online banking were set on the phone and are completely
numeric.
Comment 22•24 years ago
|
||
See bug 63961 for an update on this. The necessary modification was recently
made to the password manager and that was the crux of that bug report. The crux
of this bug report is that Wells Fargo is still rejecting the browser (in spite
of the fact that it now has the modification they wanted) and that has to be
addressed as an evangelism issue.
Comment 23•24 years ago
|
||
Adding Arun Ranganathan, who is handling Wells Fargo on the Evangelism side.
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 24•23 years ago
|
||
I've assigned this one to me: I've got correspondence going with Wells Fargo and
in general have this one under control. Updates soon to follow.
Assignee: evangelism → aruner
Status: ASSIGNED → NEW
Assignee | ||
Comment 25•23 years ago
|
||
Note that there are two issues here. One of them is the sniffing of the
user-agent string. The other is the wallet/password manager issue. The
user-agent string affair seems to have been taken care of. The latter issue
remains.
The good news: The bank in question approves of an IE like feature to suppress
Password Manager. This looks like this:
<INPUT TYPE="PASSWORD" AUTOCOMPLETE="OFF">
The 'AUTOCOMPLETE' attribute goes with either the FORM element or any element
contained within the FORM element like the INPUT element. Password Manager was
the chief bugaboo -- certain banks did not like the implications of using it in
a shared environment. So, morse landed code that now works with
AUTOCOMPLETE="OFF" -- a feature that matches what online banking institutions
are used to in terms of suppressing autocompletion.
The bad news: This fix has made it into the latest Moz' builds, but older Moz'
based browsers such as N6 still have this problem.
The chief consolation: There are workaround for N6 and older Moz' browsers
(before Morse landed his code) that suppress Password Manager. Though these are
hacks, they've been suggested, and we await the response.
Status: NEW → ASSIGNED
Banks can detect different versions of Mozilla and Mozilla-based product by sniffing the Gecko date token.
If the bank in question used one-time pad authentication like Finnish banks, this would be a non-issue.
Assignee | ||
Comment 27•23 years ago
|
||
I'm hoping to have this resolved by the 0.9.2 time frame, if not sooner. I'm in
correspondence with folks at Wells Fargo, and I'm hoping that this will be taken
care of.
Comment 28•23 years ago
|
||
http://www.wellsfargo.com/dhtml_menu.js doesn't properly detect Mozilla/uses layers.
Whiteboard: [BANK][USERAGENT][DENY][PROPRIETARY-DOM]
Assignee | ||
Comment 29•23 years ago
|
||
OK, get this:
Using 0615 Mozilla build, you can get into Wells Fargo. No problems. Using the
commercial build, Netscape 6.1 PR1, you can NOT get into online banking at Wells
Fargo. Here's the rub:
Netscape 6.1 b identifies itself to the world as follows --
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1
Wells Fargo detects Netscape 6.1 beta as "Netscape 0.9.2". Some highly
erroneous user-agent sniffing at work.
Comment 30•23 years ago
|
||
*** Bug 92031 has been marked as a duplicate of this bug. ***
Comment 31•23 years ago
|
||
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
details.
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified
Comment 32•23 years ago
|
||
I can log into Wellsie fine with ns6.1/w2k at this url:
https://banking.wellsfargo.com/
Comment 33•23 years ago
|
||
Someone please test with the following:
nscp comm nightly: mac/linux/win
nscp 6.1: mac/linux/win
mozilla nightly: mac/linux/win
I want ot make sure that this works on all of the above before we close
this out.
Zach
Comment 34•23 years ago
|
||
WFM Win32 trunk 2001081003 on Win32 (in other words "Mozilla nightly: win")
Reporter | ||
Comment 35•23 years ago
|
||
Please test with http://www.wellsfargo.com, not with 'banking.wellsfargo'. Going
directly to 'banking.wellsfargo' bypasses the browser sniffing code. Users don't
do that.
Comment 36•23 years ago
|
||
The above WFM was tested from www.wellsfargo.com all the way to my account
history. Everything worked fine.
Comment 37•23 years ago
|
||
Linux Mozilla 2001080921 (nightly):
1. load www.wellsfargo.com
2. click on "Wells Fargo Online|Sign On"
3. type in ssn and password
4. click account summary
works for me.
Comment 38•23 years ago
|
||
I just tried with Mozilla 2001091203. Went to wellsfargo.com clicked on Online
banking. I entered my username and password and it came back with an error:
"Your browser is set to refuse cookies. In order to sign on, you will need to
reset the option in your browser to accept cookies. Then, refresh your screen,
re-enter your SSN and password and select a button to begin banking."
I checked and double checked the cookies setting in Preferences and it is set to
"Enable all Cookies"
Comment 39•23 years ago
|
||
Arun's latest symptoms are probably being caused by bug 99286. Get a later
build and try that again.
Comment 40•23 years ago
|
||
Oops, I meant ejohnson, not arun, in my comment above.
Reporter | ||
Comment 41•23 years ago
|
||
Arun wrote yesterday:
----
Many of you bank with Wells Fargo. The good news is they've updated
their site, and they even validate their CSS :-) . Can anyone spot the
workaround using CSS to thwart the form fill problem? :-)
You can bank with Wells Fargo without going through any "back door"
mechanism. I'm considering us unblocked from Wells Fargo. If there's
any further weirdness with Wells Fargo, send mail to me and I'll worry
some more... They made fairly large use of proprietary DOM so there
may be left-overs.
----
Assignee | ||
Comment 42•23 years ago
|
||
Marking FIXED. Reopen if anything strange happens.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 43•23 years ago
|
||
Bug 102888 is another Wellsfargo.com bug. Dupe of this bug?
Comment 44•23 years ago
|
||
mass-reassign of all bank bugs to the banks component. You may filter
for this change by searching for the string 'ilovetriagebecauseitisfun'
Component: US General → US Banks
QA Contact: zach → bclary
Comment 46•22 years ago
|
||
Added to the mozilla financial shames page,
http://blue-labs.org/financial-shames.php
Comment 48•19 years ago
|
||
*** Bug 290647 has been marked as a duplicate of this bug. ***
Updated•9 years ago
|
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•