Closed
Bug 205571
Opened 21 years ago
Closed 21 years ago
Create UI for mail pref mail.server.server*.useSecAuth
Categories
(MailNews Core :: Networking: POP, defect)
MailNews Core
Networking: POP
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.5alpha
People
(Reporter: ch.ey, Assigned: ch.ey)
References
Details
Attachments
(2 files, 1 obsolete file)
4.57 KB,
patch
|
sspitzer
:
superreview-
|
Details | Diff | Splinter Review |
4.37 KB,
patch
|
sspitzer
:
review+
sspitzer
:
superreview+
|
Details | Diff | Splinter Review |
Spin of from bug 205003 on the implementation of a UI for the new introduced pref useSecAuth in Mozilla 1.5.
Assignee | ||
Comment 1•21 years ago
|
||
*** Bug 205641 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 2•21 years ago
|
||
This patch adds the UI for the useSecAuth pref named "Use secure authentification". Additionally it adds the right alert if the user doesn't support secAuth but the user wants to use it and improved strings for POP3_USERNAME_FAILURE and POP3_PASSWORD_FAILURE. useSecAuth is enabled by default. This will produce the same errors by the affected users as seen in bug 205003 and dupes. I'm convinced that the great majority will have no problems so this is ok. But the help page should not only describe the new feature but mention this possible problem too.
Assignee | ||
Comment 3•21 years ago
|
||
Comment on attachment 123497 [details] [diff] [review] patch adding the UI I think it's time to get this in. And I need this for creating the patch to bug 43923 ...
Attachment #123497 -
Flags: review?(bienvenu)
Comment 4•21 years ago
|
||
Comment on attachment 123497 [details] [diff] [review] patch adding the UI r=bienvenu except I think we use "username" or "user name" +4004=Sending of Username did not succeed. this comment perhaps should be - secure authentication failed? +# user required to use secure authentication
Attachment #123497 -
Flags: review?(bienvenu) → review+
Assignee | ||
Comment 5•21 years ago
|
||
> except I think we use "username" or "user name" I took username like in 4014 (also "password" now). > this comment perhaps should be - secure authentication failed? Yeah right, copy/paste ... r=bienvenu as per comment 4
Attachment #123497 -
Attachment is obsolete: true
Assignee | ||
Updated•21 years ago
|
Attachment #124170 -
Flags: superreview?(sspitzer)
Comment 6•21 years ago
|
||
IMHO, from a user point of view, it would be better if Mozilla automatically tried (say from most secure to less secure) all available login methods. Maybe a UI could allow paranoid users to disable unsecure methods?
Comment 7•21 years ago
|
||
I'll bring this to Seth's attention. One of the reasons we have this UI is that secure authentication is simply broken on some servers and having a ui will allow them to disable the attempt. The servers' behaviour is so unfriendly (e.g., just silently dropping the connection) that this pref makes our lives a lot easier.
Comment 8•21 years ago
|
||
this looks like a good start, but I have some comments. 1) + <checkbox iscontrolcontainer="true" wsm_persist="true" id="server.useSecAuth" + label="&useSecAuth.label;" hidable="true" hidefor="nntp" + prefattribute="value" + prefstring="mail.server.%serverkey%.useSecAuth"/> I think we might want hidefor="nntp,movemail" here. 2) <!ENTITY isSecure.label "Use secure connection (SSL)"> +<!ENTITY useSecAuth.label "Use secure authentication"> Is our secure authentication always Cram-MD5? If so, just like we specify SSL, why not do this: "Use secure authentication (Cram-MD5) 3) +4030=Mail server does not support secure authentication.\n Why the newline? 4) we should ask robinf@netscape.com to review the properties changes 5) david, I think we'll need some changes to: a) check the redirector type, to override the default b) check the redirector type, and in am-server.js, hide this new UI
Target Milestone: --- → mozilla1.5alpha
Comment 9•21 years ago
|
||
I'll attach a new patch since I need to test this before I check it in anyway...
Comment 10•21 years ago
|
||
Comment on attachment 124170 [details] [diff] [review] patch v2 discussed with bienvenu and: > 2) Is our secure authentication always Cram-MD5? he tells me it's not aways cram-md5, so ignore this suggestion. > david, I think we'll need some changes to: > a) check the redirector type, to override the default > b) check the redirector type, and in am-server.js, hide this new UI not blocking this, so we'll log a netscape internal bug about this issue. we'll still need a final patch for the movemail / newline issue. i'll sr the final patch.
Attachment #124170 -
Flags: superreview?(sspitzer) → superreview-
Comment 11•21 years ago
|
||
this addresses Seth's comments (I haven't included the mailnews.js changes, which remain the same)
Assignee | ||
Comment 12•21 years ago
|
||
Ok, movemail is new to me. I think the newline had a reason, but I can't remember now. No change to mailnews.js means mailnews defaults to the same behaviour like 1.4 and before: try only unsecure. Do you want this? What's the issue of 5 a/b?
Comment 13•21 years ago
|
||
fix checked in. I think RobinF should make a pass through all our messages and determine one true way to display user name and password.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 14•21 years ago
|
||
Comment on attachment 124840 [details] [diff] [review] patch v3 r/sr=sspitzer for the trunk. thanks david / christian. note, we aren't taking this for 1.4
Attachment #124840 -
Flags: superreview+
Attachment #124840 -
Flags: review+
Comment 15•21 years ago
|
||
> Ok, movemail is new to me. isn't linux only. see http://www.mozilla.org/mailnews/movemail/ > I think the newline had a reason, but I can't remember now. david didn't check it in, so if you remember or discover the reason (like it made the alert UI look better?), please log a new bug. > No change to mailnews.js means mailnews defaults to the same behaviour >like 1.4 and before: try only unsecure. Do you want this? looking at the checkins (And not the final patch, which didn't include the change to mailnews.js, which was checked in), the default for 1.5 alpha is to do secure auth default, but since there is UI, people can disable it. >What's the issue of 5 a/b? imap servers can have a redirector. for example, netscape 7.02, when you have aol or netscape webmail accounts, we key off that redirector type. I was concerned that trying cram-md5 auth would break those, but david doesn't think they will, since the server will not say it supports it. but, for netscape, there is still a UI issue, which is we want to hide this new "use secure authentication" checkbox for certain redirector types. but that's a netscape only bug, which I'll log on myself on a bug database behind the firewall, since it doesn't concern mozilla. of course, mozilla distributors might be using redirector types (like ISPs could be clever and using it), and they might care.
Comment 16•21 years ago
|
||
logged bug #208175 on the redirector issue, as the eventual fix will be to mozilla code.
Blocks: 208175
Comment 17•21 years ago
|
||
OK, I had to turn this off by default in mailnews.js - I'm not sure if this was intended or not, but we always try it for pop, and if it fails, we just don't get new mail, and there's no fallback to other authentication mechanisms. Since few pop servers support secure auth, this seems like the wrong default. I'll leave it to Christian to say what the intended behaviour is.
Comment 18•21 years ago
|
||
from http://bugzilla.mozilla.org/show_bug.cgi?id=205571#c12 christian wrote: "No change to mailnews.js means mailnews defaults to the same behaviour like 1.4 and before: try only unsecure. Do you want this?" based on bienvenu's last checkin, we're going with off by default. from bienvenu last comment, sounds like we *can't* turn it on by default. let's get a bug started on that.
Assignee | ||
Comment 19•21 years ago
|
||
David, you're right since secure is exclusive and not additional. I can't see the use of a bug on this. Ok, letting this pref add the secure mechanisms would probably work. But the user couldn't be sure that the login was really secure or if not plain text was used because of lacking sec auth mechanism on server side.
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•