should be easy to get working again.
what is this feature?
Yes. I have the same question. Seth, can you describe more detail? Thanks.
in 4.x, it was feature that if you had on (for a given server) would ask you for username / password at all times. (to set it, you'd set the properties for a newsgroup server.) this is not a beta2 stopper. I've never used it, and no one seems to care that it is missing. but I am sure there is a good reason for it. if we do add it, we'd have to make sure it plays nice with single sign on.
Status: NEW → ASSIGNED
Target Milestone: --- → M20
Oh! More clear now. Thanks for the explanation!!
not going to make it for 6.0, moving to m30.
Summary: pushed auth is not working → pushed auth is not implemented
Target Milestone: M20 → M30
this bug tracks the back end work and the UI work for pushed auth. the ui has two parts: 1) a check box & text in the account manager, for the server panel 2) a check box & text in the account wizard jglick: can you post links to the revised ui here?
Summary: pushed auth is not implemented → UI & back end: pushed auth is not implemented
Wizard http://gooey/client/5.0/specs/mail/accountSetup/accountSetup.html#News Dialog #3 Account Settings http://gooey/client/5.0/specs/mail/accountSetup/accountSetup.html#AccountSetting s Dialog: "Account - News - Server"
moving to future milestone.
Target Milestone: M30 → Future
possible release note item
Keywords: relnote2, relnote3 → relnote
QA Contact: huang → stephend
Mass moving all NEWS bugs from esther to myself.
I do need this and in another bug it was taked about being able to set different username / passwor for different groups. This is a great feature as newserwer can be configered to give access to different groups for different users. Whats needed is one 'settings' popup is needed for every group. It is to contain two sets of raidobutton: When to send user name / password to server: <> Send login info only when prompted. (default) <> Always send login info. Use user name / password for: <> News server <> Unique for this group. <> Login group [group 1] Last option enables an input field where you can enter a name (key). All Newsgroups with the same 'key' use the same user name / password (you are prompted only ones). Then, when a password is needed, the usual mozilla popup comes with the usual 'keep this password' chekbox. To get a list of groups that is protected by a login, one have to use the same login when ascing for the list. So, in the subscribe dialog, a buton labeled 'subscribe to newsgroups needing login' is needed that always prompts for username / password and then fetch the list using that usernam and password. All groups subscribed from such list can automagicly be in the same 'Login group' (as they all use the same username / password). /Lars
The decision to move this bug to FUTURE actually means that many (vary many?) mozilla users won't be / aren't able to access their ISPs news server at all! One of my ISPs for instance sports a server (news.ip-plus.net) that responds: "You have no permission to talk here. Goodbye.", actually it's an alert: "A News (NNTP) error occurred: You have no permission to talk here. Goodbye." That doesn't look nice in Mozilla. The user doesn't care wether it's push or whatever authentication, he just knows he has to enter his id and a password (sent to him by his ISP) to logon. This way he can't even subscribe or get a group listing! So, I don't even know if I have to authenticate with the server only once or each time:-( The way Communicator does it is no more than a mere workaround: by setting the option it simply continues to send your login information each and every time and therefore possibly exposing it unnecessarily. >Then, when a password is needed, the usual mozilla >popup comes with the usual 'remember this password' >checkbox. --Lars unity of interface: "The same interface for the same task, regardless of how the service is implemented on the other end." --Jamie Zawinsky, 18-May-98 Please reconsider this bug Seth. Having said this I believe bug 35832 is a dup of this one. I'm seeing this on a Mac / MacOS: platform + os ALL. I also think this bug is very hard to find, would you reconsider the summary aswell? Please make your users happy and target this one for 1.0 :-) I don't think we're talking about a feature here. By the way: as I tried to subscribe/get listing again (to copy the news server's reponse) mozilla crashed away beneath me... (not trying to reproduce yet) boo
CRASH: Go to news.ip-plus.net try to subscribe / get listing. Dismiss subscription window. Subscribe / get listing again: Mozillas windows are gone faster than you can say: "maximum warp". Platform: MacOs 9.1 / G3 Yosemite Build:2001021502
boo - you may want to file the crash part as a separate bug report. Do you have Talkback enabled to generate a stack trace?
Some servers allow you to talk to them without logging in, but will silently hide all the "private" groups unless you log in. With Netscape 4, one could get to those "private" groups by setting "Always ask for login/password" server option, but in Mozilla there seems to be absolutely no way to access those groups. I would imagine that this is something that can be implemented reasonably quickly (especially considering that some code is already there - search for HAVE_PUSH_AUTH_AND_EXTENSIONS in nsNNTPProtocol.cpp - http://lxr.mozilla.org/mozilla/source/mailnews/news/src/nsNNTPProtocol.cpp#105 ), is it possible to have some target milestone set up for this? After all there are 7 votes for it...
Works in Netscape 4.x => 4xp keyword. Please implement it for moz 1.0 => mozilla1.0 keyword.
Keywords: 4xp, mozilla1.0
The comments made by Aleksey Nogin 2001-04-19 20:55 are exactly my problem. I'm sure a lot of companies (including mine) have a private hierarchy (user/pass protected) as well as public groups on their news servers, and unless this is implemented they're not going to be happy.
I wrote a small patch that enables pushed authentication in back-end. In order to turn pushed authentication on, compile Mozilla with this patch and insert the following into your prefs.js: user_pref("mail.server.serverNN.always_authenticate", true); where NN is an appropriate number.
OS: Linux → All
Hardware: PC → All
Is http://gooey/client/5.0/specs/mail/accountSetup/accountSetup.html (mentioned in comments by email@example.com 2000-06-05 10:44) available to non-Netscape people? Where?
Aleksey, no. That's a URL only available to Netscape employees (a local URL). However, you can find (I think) all the specs on: www.mozilla.org/mailnews/specs
As a relatively unexperiences contributor, I have several questions: 1) Do people here think that my patch is a step in the right direction? 2) If yes, is there somebody here willing to do the UI part, or should I try to figure it out myself (I have no idea how UI in Mozilla works)? 3) If somebody is willing to help with UI, should I try to get my patch in separately or should I wait for UI? 4) If nobody have time to help with UI, can somebody with access to netscape.com network, put the relevant parts of http://gooey/client/5.0/specs/mail/accountSetup/accountSetup.html in a place where I could see them (e.g. attach them to this bug or e-mail them to me)? Thanks!
Here is the Mozilla url for the spec: http://www.mozilla.org/mailnews/specs/accounts/
http://www.mozilla.org/mailnews/specs/accounts/ does not give any UI for changing pushed auth setting. From jglick's comment I got an impression that http://gooey/client/5.0/specs/mail/accountSetup/accountSetup.html was updated, but http://www.mozilla.org/mailnews/specs/accounts/ does not seem to have those updates...
> 1) Do people here think that my patch is a step in the right direction? yes, this looks good. I'll need to review and test. > 2) If yes, is there somebody here willing to do the UI part, or should I try > to figure it out myself (I have no idea how UI in Mozilla works)? before you (or someone else) hacks up a UI, we need to update the spec. > 3) If somebody is willing to help with UI, should I try to get my patch in > separately or should I wait for UI? yes, your patch can go in before we have ui. making it a hidden pref (no UI) is acceptable. > http://gooey/client/5.0/specs/mail/accountSetup/accountSetup.html don't worry about that document. I've seen it, and it doesn't have any UI for "pushed auth" yet. here's what we should do: 1) I'll review and test your patch, and help you drive it into the tree. (target 0.9.3) 2) jglick helps us (for the UI) by updating the spec. I'm not sure where the UI for this will live yet. when the back end part lands, we can create a new bug on the UI. for now, this bug can do for both.
Whiteboard: relnote-user → relnote-user (potential fix in hand)
Target Milestone: Future → mozilla0.9.3
I've been running Mozilla with this patch for couple of weeks now. Have not noticed any problems or adverce effects. Can somebody review this patch? Thanks!
Keywords: mozilla1.0 → mozilla0.9.3
Whiteboard: relnote-user (potential fix in hand) → relnote-user (potential fix in hand, needs r and sr)
Whiteboard: relnote-user (potential fix in hand, needs r and sr) → relnote-user (potential fix for back-end in hand, needs reviews)
moving to 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
ok, this patch is good. I've done some additional cleanup and defined a default for this new pref in mailnews.js r/sr=sspitzer I'll attach the final patch and land it. I'll go spin up new bugs for the UI element, and the 4.x migration element.
18 years ago
Summary: UI & back end: pushed auth is not implemented → back end: pushed auth is not implemented
http://bugzilla.mozilla.org/show_bug.cgi?id=94439 for the UI http://bugzilla.mozilla.org/show_bug.cgi?id=94440 for the migration issue. marking fixed. Aleksey, thanks for the patch (or for patiently waiting for me to get to it).
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
*** Bug 35832 has been marked as a duplicate of this bug. ***
*** Bug 95896 has been marked as a duplicate of this bug. ***
Adding this pref in prefs.js: user_pref("mail.server.server3.always_authenticate", true); to this server: user_pref("mail.server.server3.hostname", "news.mozilla.org"); causes the model to change to authentication, even for servers that don't require it. (In this case, you can enter whatever you want, since news.mozilla.org doesn't have any select groups that are shown only to auth users) Mac OS 9.1 - 2001-09-04-08 Windows 2K - 2001-09-03-03 RedHat 7.1 - 2001-08-31-08 This verification was for the *back-end* model only (as the bug was intended for). For UI specific issues, please see bug 94439 and bug 94440. Thanks, Aleskey!
Status: RESOLVED → VERIFIED
*** Bug 101238 has been marked as a duplicate of this bug. ***
*** Bug 110988 has been marked as a duplicate of this bug. ***
*** Bug 120960 has been marked as a duplicate of this bug. ***
*** Bug 124180 has been marked as a duplicate of this bug. ***
*** Bug 152608 has been marked as a duplicate of this bug. ***
*** Bug 170127 has been marked as a duplicate of this bug. ***
*** Bug 171971 has been marked as a duplicate of this bug. ***
firstname.lastname@example.org 2002-10-01 12:52 >> How can I configure moz news to provide an account id and password? >> When I create a news account, I give email, server, and account >> (display) name, but the wizard never asks for account id and >> password. Thus, when I attempt to subscribe, I never even see the >> newsgroup in which I'm interested. email@example.com 2002-10-01 13:12 > please see the info at > http://bugzilla.mozilla.org/show_bug.cgi?id=39862#c34 for how to > enable this per-server through prefs.js. Currently, we don't have > any UI for this, but there is a patch sitting in bug 94439. Umm, maybe I'm a bit thick, but I'm having trouble with this: http://bugzilla.mozilla.org/show_bug.cgi?id=39862#c34 > Adding this pref in prefs.js: > user_pref("mail.server.server3.always_authenticate", true); > to this server: > user_pref("mail.server.server3.hostname", "news.mozilla.org"); > causes the model to change to authentication My questions are: * how to find the appropriate prefs.js? I have a bunch of old profiles, so I suspect I'll find bunches of prefs.js on my many attached disks, which I'm not thrilled to search for, anyway. Is there UI to access prefs.js, or to tell me which one is currently active? * is the choice of N in "serverN" purely arbitrary?
firstname.lastname@example.org (Stephen Donner) 10/01/2002 04:45 PM > Find the string that corresponds with the server you need to enable > 'push authentication' for: > (the key here is the serverX variable). > user_pref("mail.server.server3.hostname", "news.mozilla.org"); > then, simply add in this line to your pref.js: > user_pref("mail.server.server3.always_authenticate", true); > I would just use your OS's search feature and find by date last > modified/accessed, that would bring up the current prefs.js file. > note that Mozilla has to be shut down completely when you edit > pref.js, otherwise the file won't be overwritten. OK, so for the benefit of the thick, the procedure to follow is: * Completely shut down Mozilla. Remember to not only close all windows, but to kill any mozilla processes. (E.g. in Windows, if you have Mozilla running in your taskbar, make it Exit Mozilla.) * Find your current profile directory. If you don't know what that is, use your favorite search feature to search for files named "prefs.js", and look for one recently modified or accessed. * For self-preservation, backup the file. * Open the file in your favorite editor. Search for the name of the server for which you wish to force authentication. E.g. if the name is "news.foo.bar.org", you should see a line like user_pref("mail.server.server2.hostname", "news.foo.bar.org"); * NOTE THE NUMBER: in this case, "2". Copy the following line user_pref("mail.server.serverN.always_authenticate", true); into your editor, and change "N" to match the number. E.g. in the above case, the line to copy would be user_pref("mail.server.server2.always_authenticate", true); * Save and close the file. Restart Mozilla. Access the relevant account and attempt to interact (subscribe to newsgroups or read a particular newsgroup). You should now receive dialogs for ID and password. Worked for me! Now, improve the usability :-)
note, I've landed neil's front end patch, so there is UI for this pref now. (no need to hack prefs.js anymore)
*** Bug 175068 has been marked as a duplicate of this bug. ***
*** Bug 181563 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.