Community
Participate
Working Groups
Currently only committers can edit the wiki, however bugzilla users also agree to a use agreement, so perhaps they should be allowed to use the wiki as well. This requires extending the Mediawiki login mechanism to validate against bugzilla users as well as LDAP. Or perhaps there is a second wiki?
+1 We could perhaps extend MediaWiki in a way that doesn't interfere with too much of the source code (so that we can upgrade MediaWiki easily). I believe the LDAP authentication module is already done in this fashion.
I agree with this, and Denis and I've discussed it in the past. A second wiki is not an option, and here is why...(and also the reason why access is restricted on the current wiki...) We want to ensure that all of the content on the wiki conforms with the Eclipse website Terms of Use. This means that we want the content on the site to be (a) submitted under the EPL and (b) tracable to a known contributor so that if we wanted to use any such content in a project, we would have the verifiable copyright provenance to allow us to do so. In order for this to work, we need to have the content on the wiki tracable to users. Anonymous access to the wiki would mean that all of the content on there would be suspect in terms of provenance. It would be a real drag to have great content (e.g. examples and code) on the wiki which could not be used by projects. So, once we get Phoenix shipped and catch our collective breath, I am hopeful that we can get something along the lines you've described here completed. Using the bugzilla userids and logins seems like the right approach since there are so many users already registered there, and the process for doing so is lightweight and well known.
+1 we need this if the wiki will become a truly community effort.
*** Bug 120451 has been marked as a duplicate of this bug. ***
Allowing non-committers to edit the wiki would be nice, and I'm definitely +1 with that. More importantly, non-committer users who DEPEND on Eclipse components should be able to subscribe individual Eclipsepedia pages (or, in MediaWiki terms, add individual pages to their watch lists). E.g. https://bugs.eclipse.org/bugs/show_bug.cgi?id=120451#c0 (tweaked) > Steve Gambino 12/07/05 16:45 > >>> Not sure if we need to keep apprised of this. The "changes" > >>> M2_32 caught my eye. > >>> http://wiki.eclipse.org/index.php/Platform-releng-basebuilder > David Olsen 12/08/2005 05:21:23 PM: > >> We should keep an eye on that page. > > However I'm not seeing any way for someone who is not an Eclipse > > committer to subscribe an Eclipsepedia page, probably because > > there is no way for such persons to create an Eclipsepedia account https://bugs.eclipse.org/bugs/show_bug.cgi?id=120451#c1 > If Bugzilla registered users could log in to the wiki, they would > have the same privileges as committers, thus enabling watches.
There should be also a self-register option/howto added, i.e. pointing unregistered/new user to the Bugzilla self-register page.
I have just moved the RCP home page over to the Wiki, and would like to allow others in the community to contribute to it, not just committers. Requiring authentication makes sense, for both IP protection and spam control. Using bugzilla credentials makes sense to me.
Matt looked into it, and because MediaWiki uses a pluggable authentication scheme, we can hook ourselves up into the Bugzilla database. Proposed solution is to develop an authentication Plugin and release it as an Open Source component of Phoenix. The only caveat is that, as with the Committer authentication, the first time a bugzilla users logs in to Wiki, they will need to "create their wiki account" even if it is tied to their bugzilla authentication. Once wiki knows who they are, they can log in and out as they please. The password used for authentication will be the one on bugzilla at all times. D.
I'm not sure how notification of changes is currently done in MediaWiki, but it would seem to make sense to send any notifications to the user's bugzilla account email address too.
Targeting for Q2/2006. D.
Sorry: Is there something easier to manage than full rights for any bugzilla user? Or is it just hand-to-hand against incompetence or malice? The wiki should be great for pulling code samples from the user community for AspectJ, but I'm leery of other people speaking about AspectJ semantics or implementation with the authority of Eclipse; we've been very careful (at least in the past) to be right so people rely on us. On the mailing list it's costly enough already to correct (and limit the effect of) self-styled experts when the text is clearly their's and they don't get to modify committer posts. So permitting user edits makes our adoption of the wiki both more enticing and potentially a PITA. If we move our content to the wiki, then we'd have to keep it there and keep maintaining it, even if user edits turn out to be more trouble than help -- which makes me at least disinclined to move content over. We at one point planned a code submission page which would actually validate that the code compiles and runs before posting. We also considered separate commit rights for a separate library and/or doc module. And not surprisingly, we haven't done that and don't get community contributions. (There are blogs, but that's kind of the opposite of a wiki, eh?)
This is where I believe we, the foundation, should offer guidance to the projects regarding what content should/could go on the wiki, and what should not. For instance, content you believe requires the "Authority" of Eclipse should be on your website, where only committers can publish content modifications. However, documentation, tutorials, how-to's could be great community-driven documents that could reside on the wiki. These are only examples, but I think these guidelines are a must-have. See bug 125497 for the Wiki != website discussion. D.
I don't mean to be a nag, but how is this coming along? Can we expect a beta of some kind or even (hope hope) the final version any time soon?
(In reply to comment #13) > I don't mean to be a nag, but how is this coming along? Can we expect a beta > of some kind or even (hope hope) the final version any time soon? > As per comment 10, this should be an objective for Q2/2006. D.
> Or is it just hand-to-hand against incompetence or malice? It is my experience that complete and well written pages on technical topics require very little attention. However, you should certainly subscribe for notification on pages that you tend and report abuse to the webmaster. Wikis thrive on large, interested communities. Without community it becomes just a clunky content management system. As a committer only resources the wiki has been hovering below the critical mass of attention required to make it work well. Adding Bugzilla users is a good move.
>As a committer only resources the wiki has been >hovering below the critical mass of attention >required to make it work well. Adding Bugzilla >users is a good move. Amen brother!
Because Eclipse committers indeed have a bugzilla account, would it make more sense to disable the actual authentication using the committer ID and allow everyone, including committers, to login to the wiki using their Bugzilla account? It seems redundant to have both. D.
Denis, I think this is a good idea. At least for me it makes it easier to login. In generally, I feel very uncomfortable if I have to enter a password I use for shell access somewhere in a web form. Even if it's SSL submitted.
I agree it is kinda silly to have two authentication methods for the same group of people. I'll go with Bugzilla-only. The positive bonus, as Gunnar mentions, is that it involves less risk to our server security vs. LDAP. The MediaWiki authentication plugin mechanism is fairly simple; with only a bit of coding I already have a sandbox that authenticates (somewhat) against Bugzilla. Things could get hairy with an e-mail address as MediaWiki's user id, but when it's ready for testing, I'll post the URL here. D.
Created attachment 38544 [details] Wiki snapshot with e-mail address as user id I ran into a small snag - because the bugzilla login id is an e-mail address, this would have been the wiki login id as well. This would result in bugzilla e-mail addresses being used on wiki pages without any munging. I did a basic behind-the-schenes replace of the @ symbol to ".". This allows you to perform a wiki login using your bugzilla e-mail address unchanged, but on the wiki pages, e-mail addresses look nothing like an e-mail address: webmaster.eclipse.org denis.roy.eclipse.org Of course, to the human eye (and because you know my e-mail address), it's quite obvious, but it makes a nice, clean wiki user id. I can't use weird characters ([])_!/';: etc.. as a wiki user id, and I can't just strip the domain name because the wiki id it needs to be unique. So my question is: does my simple e-mail munging scheme seem like an acceptable solution? D.
Another option I'm open to is stripping dots, then replacing the "@" with a dot: webmaster.eclipseorg denisroy.eclipseorg This would make it easy for us humans to figure out who's who, yet make it darn near impossible for a spambot to figure out. D.
+1 to whatever you gotta do to reduce spam!!! - Don
(In reply to comment #22) > +1 to whatever you gotta do to reduce spam!!! We should remember that the first goal is not to reduce spam but to allow every member of the community to edit the wiki. But it's really good to have this solution, too. Personally, I think the ids with only one dot will be more eye catching. Denis, what about other email characters (like underscores, dashes and pluses)?
(In reply to comment #23) > Personally, I think the ids with only one dot will be more eye catching. I just found out that this will not work. fr.eak@company.com and f.reak@company.com are different accounts on Bugzilla but would map to the same user on the wiki. Thus, I think we need to keep all dots.
(In reply to comment #24) > fr.eak@company.com and f.reak@company.com are different accounts on Bugzilla Good catch. I've reverted to user.name.domain.org D.
I've created a sandbox wiki for your testing pleasure. You should be able to log into the Wiki using your Bugzilla account. http://wiki.eclipse.org/wikitest/ Committers who are logged in using their Committer account may possibly remain logged in until they log out. After that, they won't be able to log in using their Committer account. (Note: the above sandbox may not work for Foundation staff in the Ottawa office because I didn't put tricky https redirects) D.
Eclipse Webmaster 2006-04-26 16:49 > I've created a sandbox wiki for your testing pleasure. You should be > able to log into the Wiki using your Bugzilla account. Indeed, one can even edit! Thanks.
Two comments/questions: 1. Can you avoid the capitalization of the first letter? 2. The user names would be probably better readable of we replace the @ not with a dot but with ".from.". I don't think that spambots will catch this. Any thoughts?
Works like a charm for me. Can't wait to see this in production!
Need to test what happens when a Bugzilla user has an underscore character in the username. Seems Wiki maps it to a space (and back) but fails the authentication in the interim.
I clicked on one of the edit buttons on the front page and got directed to http://wiki.eclipse.org/wikitest/index.php?title=Main_Page&action=edit§ion=2 which says: "You have to _login_ to edit pages." _login_ is a link to http://wiki.eclipse.org/wikitest/index.php/Special:Userlogin . When I click on that link I get a Firefox error: "The page isn't redirecting properly Firefox has detected that the server is redirecting the request for this address in a way that will never complete. * This problem can sometimes be caused by disabling or refusing to accept cookies." I don't have cookies disabled so I don't know what the problem is.
There was indeed a problem with e-mail addresses with underscores. This has been fixed - the underscore is replaced with a space. I tried to work around this, but MediaWiki just seems to replace any occurrence of underscore with a space. Any users with an underscore are invited to test the sandbox to make sure they can log in. D.
This is now live. If there are any bugs with the Wiki-Bugzilla authentication, please open a new bug for them. D.
Code submitted to MediaWiki: http://bugzilla.wikipedia.org/show_bug.cgi?id=5840 D.
So, "the obvious @ of the e-mail address" is already fixed?
It appears we can no longer login to our "old" wiki accounts based on CVS permissions. This loses a bunch of information, such as my watch list, talk page, the list of my contributions, etc. Is there any way to keep these old accounts active or to migrate user-specific data to the new accounts?
(In reply to comment #35) > So, "the obvious @ of the e-mail address" is already fixed? > Yes.. Look at the Wiki "Recent changes" history. (In reply to comment #36) > It appears we can no longer login to our "old" wiki accounts based on CVS > permissions. This loses a bunch of information, such as my watch list, talk > page, the list of my contributions, etc. Is there any way to keep these old > accounts active or to migrate user-specific data to the new accounts? > No, you'll need to re-create this data. D.
(In reply to comment #37) > (In reply to comment #35) > > So, "the obvious @ of the e-mail address" is already fixed? > > > > Yes.. Look at the Wiki "Recent changes" history. In "Recent changes" history e-mails looks like it is not fixed.
Created attachment 41182 [details] Screenshot of bugzilla usernames I'm not sure what you mean. See attached screenshot. These are the bugzilla user id's (which are e-mails, but who would know?) D.
(In reply to comment #35) > So, "the obvious @ of the e-mail address" is already fixed? I just read comment #28 about ".from." and did not see the others where we were agreed to just '.' for e-mail separator, sorry. Personally, I'd prefer ".at.".
(In reply to comment #40) > Personally, I'd prefer ".at.". My line of thought here is that it's really easy to replace .at. with @ programmatically, making harvesting possible. However, relacing "." with @ programmatically will definitely not work. I'm just trying to protect our e-mail addresses as best I can :) D.
(In reply to comment #41) > I'm just trying to protect our e-mail addresses as best I can :) I did not get it was munging, sorry. BTW, '.' harvesting is possible. For example, considering that most domains have 2-3 levels. BTW2, wikipedia exposes your Username and this is not your munged e-mail. This is definitely more secure. PS. This is not an attempt to reopen this bug, just thoughts... :)
I think I agree with Dennis that . vs .at. is much more difficult to harvest. For instance, consider the following modified addresses: djspiewak.gmail.com daniel.spiewak.gmail.com daniel.spiewak.wi.rr.com Notice the problem from a spider's perspective? You can count from either side because some domains allow for 'dot' usernames and some don't. Some domains have sub-domains - like Road Runner - and some (like GMail) don't. There's no way to automatically tell. The only practicable way would be to build a list of common email domains and filter text based on that. All in all, more trouble than most people are willing to take. . harvesting is definately possible, but much more difficult than .at. because there's no repeatable deliminator.
(In reply to comment #42) > BTW2, wikipedia exposes your Username and this is not your munged e-mail. This > is definitely more secure. Agreed, but we're using your Bugzilla username for authentication to the Wiki... Our train of thought here is that we all have enough darn usernames and passwords for all the sites we go to, we didn't want the Wiki to be yet another one, and because so many people in our community already registered Bugzilla users, this only made sense. I appreciate your thoughts, Sam. Keep 'em coming. D.
(In reply to comment #44) > I appreciate your thoughts, Sam. Keep 'em coming. Bugzilla's Email Address Munging (not really mine:) http://www.bugzilla.org/features/#eam Unfortunately, http://bugzilla.org itself does not use it. :)
