Hi, folks.
I know it's a bold move but I want to propose a whitelist mode for article viewing. This is a feature that is most useful for Wikis with a closed user base. My implementation takes only few lines in Article.php and a new global config variable. Default action is - as usual - that everybody on this planet (or more precisely: in this net) can view everything. If the feature is turned on, only logged in users are able to view articles.
If nobody objects, I'll commit it into the unstable branch.
Bye!
Matthias
P.S.: You probably already guessed so, but I'm planning on using Phase3 for a knowledge database of a closed community so the next thing to implement will be some sort of invitation-based user account generation (else this viewing feature would be pretty pointless). I want to commit these closed-shop features to the main branch because I feel that other users may want to use Phase3 and its advanced Wiki engine for their own internal projects, too.
On Tue, Aug 05, 2003 at 01:02:08PM +0200, Matthias Jordan wrote:
Hi, folks.
I know it's a bold move but I want to propose a whitelist mode for article viewing. This is a feature that is most useful for Wikis with a closed user base. My implementation takes only few lines in Article.php and a new global config variable. Default action is - as usual - that everybody on this planet (or more precisely: in this net) can view everything. If the feature is turned on, only logged in users are able to view articles.
If nobody objects, I'll commit it into the unstable branch.
Bye!
Matthias
P.S.: You probably already guessed so, but I'm planning on using Phase3 for a knowledge database of a closed community so the next thing to implement will be some sort of invitation-based user account generation (else this viewing feature would be pretty pointless). I want to commit these closed-shop features to the main branch because I feel that other users may want to use Phase3 and its advanced Wiki engine for their own internal projects, too.
Do we really want all that in our codebase ? Why can't you just fork ?
on 8/5/03 5:31 AM, Tomasz Wegrzanowski at taw@users.sourceforge.net wrote:
Do we really want all that in our codebase ? Why can't you just fork ?
Sourceforge serves more than just Wikipedia. Eventually our software will be used in a variety of projects, unless it get screwed up so no one else can use it without doing extensive tedious modifications.
Fred
Hi, folks!
Fred Bauder wrote:
Sourceforge serves more than just Wikipedia. Eventually our software will be used in a variety of projects, unless it get screwed up so no one else can use it without doing extensive tedious modifications.
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 8/5/03 5:58 AM, Matthias Jordan at mjordan@code-fu.de wrote:
Hi, folks!
Fred Bauder wrote:
Sourceforge serves more than just Wikipedia. Eventually our software will be used in a variety of projects, unless it get screwed up so no one else can use it without doing extensive tedious modifications.
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
I think your whitelist mode can be set false and only be used if it is turned on.
Fred
On Tue, Aug 05, 2003 at 05:47:03AM -0600, Fred Bauder wrote:
on 8/5/03 5:31 AM, Tomasz Wegrzanowski at taw@users.sourceforge.net wrote:
Do we really want all that in our codebase ? Why can't you just fork ?
Sourceforge serves more than just Wikipedia. Eventually our software will be used in a variety of projects, unless it get screwed up so no one else can use it without doing extensive tedious modifications.
Yeah, but what he proposes is so radically unwiki that he should probably just fork.
On Tue, 5 Aug 2003 13:59:20 +0200, Tomasz Wegrzanowski taw@users.sourceforge.net gave utterance to the following:
On Tue, Aug 05, 2003 at 05:47:03AM -0600, Fred Bauder wrote:
on 8/5/03 5:31 AM, Tomasz Wegrzanowski at taw@users.sourceforge.net wrote:
Do we really want all that in our codebase ? Why can't you just fork ?
Sourceforge serves more than just Wikipedia. Eventually our software will be used in a variety of projects, unless it get screwed up so no one else can use it without doing extensive tedious modifications.
Yeah, but what he proposes is so radically unwiki that he should probably just fork.
I don't see a problem of unwikiness. I am involved in two confidential projects which use UseMod wiki where editing is restricted to a smallish (about 50) pool of people (one has a slightly larger reading pool), and having access control as part of the software would be much more convenient then having to use httpd authentication (always enter via the same URL etc) .
I'm also merging the enhanced wiki parser I'm writing with an access control script to form a content management system for my clients.
On Wed, 6 Aug 2003, Richard Grevers wrote:
I don't see a problem of unwikiness. I am involved in two confidential projects which use UseMod wiki where editing is restricted to a smallish (about 50) pool of people (one has a slightly larger reading pool), and having access control as part of the software would be much more convenient then having to use httpd authentication (always enter via the same URL etc)
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 Tue, 05 Aug 2003 13:11:07 -0700 (PDT), Brion Vibber vibber@aludra.usc.edu gave utterance to the following:
On Wed, 6 Aug 2003, Richard Grevers wrote:
I don't see a problem of unwikiness. I am involved in two confidential projects which use UseMod wiki where editing is restricted to a smallish (about 50) pool of people (one has a slightly larger reading pool), and having access control as part of the software would be much more convenient then having to use httpd authentication (always enter via the same URL etc)
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.
In my experience, if I follow a link into a subpage in the protected directory rather than the index page (where my browser does store the login) or if I follow an URL which includes the user/pass (as I might in a bookmark) then if I follow any link from that first page I have to log in a second time. This happens on several browsers.
On Wed, 6 Aug 2003, Richard Grevers wrote:
In my experience, if I follow a link into a subpage in the protected directory rather than the index page (where my browser does store the login) or if I follow an URL which includes the user/pass (as I might in a bookmark) then if I follow any link from that first page I have to log in a second time. This happens on several browsers.
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!
Tomasz Wegrzanowski wrote:
Do we really want all that in our codebase ? Why can't you just fork ?
That's an interesting point I already thought about myself. The gag is this: the article viewing whitelist stuff only takes 20 lines (and that includes the lines that merely compose the message "you gotta login to view what's written here"). I'm already experimenting with the invitation-only user account creation. I plan to implement it this way: only users who have certain rights (like "user", "sysop", "developer", maybe "accountcreation") can create accounts. It takes 10 lines of code to check a user against a list of permissions. Then this 10 lines function will be called twice: once for the construction of the login form (don't show account creation fields if user isn't allowed) and once for the function that actually creates a new account. And this code only gets called upon login - and that is not supposed to occur so often that my changes would have any impact on the CPU load.
So, all in all we talk about (estimated):
20 LOC for article writing 20 LOC for article viewing 20 LOC for account creation 4 LOC for user messages per language 3 LOC for global variables to define the behaviour.
Totaling less than 70 lines of code. Do you really want to fork a separate branch for that stuff?
(But I must say I'm happy to see that people actually read what I write - I didn't get /any/ feedback for days for what I've written.)
Bye!
Matthias
P.S.: Please, try to avoid complete quotes with only few lines of own text under the quote.
Hi, folks!
I wrote:
Totaling less than 70 lines of code. Do you really want to fork a
... 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
Matthias Jordan wrote:
Totaling less than 70 lines of code. Do you really want to fork a
[...]
But, hey, the diff is still only 150 lines in size. :-)
That's o.k., I think we all know that when a programmer says 1 week, it means 2, and when a programmer says 70 lines of code, it really means 140! :-)
For awhile, I tried to defeat this mysterious law of nature by doubling my own estimates before I told anyone. Didn't help, because it still is true that whatever you promise someone, the actuality is twice as bad!
If I think "this will take a week" and so double it and promise it in two weeks, then it takes 4.
;-)
--Jimbo
Jimmy Wales wrote:
I think we all know that when a programmer says 1 week, it means 2, and when a programmer says 70 lines of code, it really means 140! :-)
For awhile, I tried to defeat this mysterious law of nature by doubling my own estimates before I told anyone. Didn't help, because it still is true that whatever you promise someone, the actuality is twice as bad!
If I think "this will take a week" and so double it and promise it in two weeks, then it takes 4.
;-)
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
Tomasz Wegrzanowski wrote:
Do we really want all that in our codebase ? Why can't you just fork ?
Although serving a general community of wikis should never become the primary focus of our software project, i.e. we have more than enough to do just keeping wikipedia on track, I see no harm in sometimes including some features that make it easier for people to use our software for other things.
For one thing, if the software is widely used, we will get a lot more bugtesting and also a lot more interest from developers.
Right now, all the development has been done by people who were interested in the encyclopedia project first and foremost, and saw a need for software to make the pedia run better.
But if the software were a bit more widely usable, then we'd get patches from people to fix bugs or improve performance.
The main thing that people have to understand, if they want to use our software for something else, is that the software will always remain optimized for exactly what we're doing, so extensive addition of huge amounts of code that wouldn't be used by us would probably not be welcomed.
But a little bit of code, I don't see much harm, but I do see a lot of potential benefit.
On Tue, Aug 05, 2003 at 05:06:09AM -0700, Jimmy Wales wrote:
But a little bit of code, I don't see much harm, but I do see a lot of potential benefit.
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.
Hi, folks!
Tomasz Wegrzanowski 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,
No, no. Not by far. I just love Phase3 and want to use it for a closed community. So I want to ensure:
+ Only community insiders can read articles + Only community insiders can edit/create articles + Only certain people are allowed to become insiders.
A per-article ACL feature would be increadibly bloated and I wouldn't even know what benefits it could have.
Bye!
Matthias
On Tue, Aug 05, 2003 at 02:37:35PM +0200, Matthias Jordan wrote:
Hi, folks!
Tomasz Wegrzanowski 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,
No, no. Not by far. I just love Phase3 and want to use it for a closed community. So I want to ensure:
- Only community insiders can read articles
- Only community insiders can edit/create articles
- Only certain people are allowed to become insiders.
A per-article ACL feature would be increadibly bloated and I wouldn't even know what benefits it could have.
Wouldn't a simple basic authentication for the server also serve your purpose?
Regards,
JeLuF
On Tue, Aug 05, 2003 at 03:38:11PM +0200, Jens Frank wrote:
On Tue, Aug 05, 2003 at 02:37:35PM +0200, Matthias Jordan wrote:
Hi, folks!
Tomasz Wegrzanowski 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,
No, no. Not by far. I just love Phase3 and want to use it for a closed community. So I want to ensure:
- Only community insiders can read articles
- Only community insiders can edit/create articles
- Only certain people are allowed to become insiders.
A per-article ACL feature would be increadibly bloated and I wouldn't even know what benefits it could have.
Wouldn't a simple basic authentication for the server also serve your purpose?
That's more or less what I meant. If it doesn't use Wikipedia-specific information about user accounts and articles, then httpd is much better suited for it. If it uses these information, it will cause huge bloat. So either way it's not good idea to add such code to codebase.
Hi, folks!
Jens Frank wrote:
No, no. Not by far. I just love Phase3 and want to use it for a closed community. So I want to ensure:
[...]
Wouldn't a simple basic authentication for the server also serve your purpose?
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, Aug 05, 2003 at 04:13:28PM +0200, Matthias Jordan wrote:
Hi, folks!
Jens Frank wrote:
No, no. Not by far. I just love Phase3 and want to use it for a closed community. So I want to ensure:
[...]
Wouldn't a simple basic authentication for the server also serve your purpose?
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).
You have access to auth data from cgi wikipedia script. That seems like the right way.
On Tue, 5 Aug 2003, Matthias Jordan wrote:
A per-article ACL feature would be increadibly bloated and I wouldn't even know what benefits it could have.
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)
Matthias-
I know it's a bold move but I want to propose a whitelist mode for article viewing. This is a feature that is most useful for Wikis with a closed user base. My implementation takes only few lines in Article.php and a new global config variable. Default action is - as usual - that everybody on this planet (or more precisely: in this net) can view everything. If the feature is turned on, only logged in users are able to view articles.
Instead of forcing people to log in, I would prefer a small box below the edit window for anons:
If you were logged in, your edit would be attributed, and you could change your [[Wikipedia:User preferences help|preferences]].
Username: Password: [log in and save] Password repeat: Email: [create an account and save]
But I have no objection to making the whitelist a sitewide option.
Regards,
Erik
wikitech-l@lists.wikimedia.org