Hi, folks! Fred Bauder wrote: Sorry, but I don't understand what you mean. Are you for including those closed-shop features into the main brach or against it? Bye! Matthias "not being a native speaker" Jordan

On Tue, Aug 05, 2003 at 05:47:03AM -0600, Fred Bauder wrote: Yeah, but what he proposes is so radically unwiki that he should probably just fork.

On Wed, 6 Aug 2003, Richard Grevers wrote: I should point out that you _don't_ need to enter via the same URL for HTTP authentication -- going to any page in the protected zone without sending the auth info will prompt a password request. And most browsers will happily store your username/ password and automatically send it, if your machines/user accounts are considered secure enough. If you just want to restrict editing, not viewing, then obviously that won't do, but if you want to restrict viewing, that's exactly what it was designed for. -- brion vibber (brion @ pobox.com)

On Wed, 6 Aug 2003, Richard Grevers wrote: Well, I've never seen that happen. Here, I've put a couple other pages into one of my Safari bug test pages at work. Try: http://www.scec.org/safaribugdemo/somefile.html with username "username" and password "password", then click on the other links. Safari 1.0: works fine IE 5.2/Mac: works fine Mozilla Firebird 0.61: works fine Mozilla 1.4: works fine Netscape 4.77: works fine lynx 2.8.4rel.1: works fine Konqueror 3.1.1: works fine Amaya 7.1: works fine IE 5.0/Win: works fine Having told each browser to store the password, quit and come back to same page: Safari 1.0: works transparently IE 5.2/Mac: remembers the values, but brings up filled-out dialog box on first visit back, you have to hit OK. After that links to other pages are transparent. Mozilla Firebird 0.61: same -- filled-out dialog on first page, then transparent Mozilla 1.4: same -- filled-out dialog on first page, then transparent Opera 6.02: similar; you have to hit "get from keychain" to fill out the dialog box, hit ok; other pages then transparent IE 5.0/Win: I was unable to get this to save passwords, but it may be disabled elsewhere in the configuration. The following don't seem to allow saving passwords, so you have to type it in once for each browser session: Netscape 4.77 lynx 2.8.4rel.1 Konqueror 3.1.1 Try revisiting at the index page (http://www.scec.org/safaribugdemo/) instead of a named page: Same behavior as the named page: Safari 1.0 IE 5.2/Mac* Mozilla Firebird 0.61 Mozilla 1.4 Not quite the same: Opera 6.02: 'get from keychain' comes up with the wrong user/password pair. It's unclear what it would do if I didn't have a stored password for another section of the site. * Another note on IE 5.2/Mac: it doesn't seem to be able to distinguish between different realms on the same server. If you save a username/password pair for one realm, it offers the same pair when visiting a separate password-protected part of the server. If you then save that pair, it offers up the new pair the next time you visit either realm. So, you can apparently only store one set per server with this browser. -- brion vibber (brion @ pobox.com)

Hi, folks! I wrote: ... which I was afraid it could be a too optimistic figure. It turned out I had to change the user account creation slightly for a better handling. I introduced a new button "by eMail" directly next to "create new account" that lets a logged in user create an account and immediately send the password to the supplied eMail address. To implement this, I had to rearrange some code for not having any duplicate code in SpecialUserlogin.php. But, hey, the diff is still only 150 lines in size. :-) Bye! Matthias

Jimmy Wales wrote: Then there is the other tactic: If you think that something will take a week, promise it in three days. If you think it will take 70 lines of code promise 35. Of course, no matter what you do, your credibility will be in question. ;-) In the same class of laws of human nature, if you need a quorum for a meeting at 8:00 p.m. announce the starting time for that meeting as a half-hour earlier.. :-) Ec

On Tue, Aug 05, 2003 at 05:06:09AM -0700, Jimmy Wales wrote: As far as I understood, he wants per-article entry of who is allowed to read an article, what is going to need one database query on every view, and slow down things a lot.

On Tue, Aug 05, 2003 at 02:37:35PM +0200, Matthias Jordan wrote: Wouldn't a simple basic authentication for the server also serve your purpose? Regards, JeLuF

Hi, folks! Jens Frank wrote: [...] You mean .htaccess style authentication? Basically, yes, but the .htaccess scheme has some disadvantages: it requires two layers of authentication for the user (which is quite annoying) and requires authentication credentials to be maintained at two different places (which is also quite annoying). Especially if the community that is employing the Wiki is non-technophile (to say the least). Bye! Matthias

On Tue, 5 Aug 2003, Matthias Jordan wrote: We've already got one: every page has a "cur_restrictions" field, and every user has a "user_rights" field. Right now it's not extensively used and is partially hard-coded such that only the "sysop" value is meaningful on pages, but it would be simple to extend it to be similar to UNIX 'groups'... any user whose user_rights field overlaps with the cur_restrictions field of a page would be able to edit that page. This wouldn't be relevant to Wikipedia, but we already load those fields along with the page and user data and check them, just not very thoroughly. There would be zero database cost to using them. Projects which might want to restrict editing of certain pages to members of specific groups could easily do so. -- brion vibber (brion @ pobox.com)