Last modified: 2010-05-15 15:32:59 UTC
For small intranet MediaWikis, I have written a very short patch which does what I call auto-login with auto-account-creation by the detected hostname. It uses php gethostbyaddr()) for intranet MediaWikis in Setup.php and some few lines of code in user.php and Special:Userlogin and Special:Userlogout. This patch means, that users are automatically logged-in into their accounts (if existing) or that such an account is created on-the-fly, when a user visits the wiki. A short table such as a plain text file holds a look-up table for correspondences between hostnames (e.g. IP addresses, personal staff numbers or something else depending on the intranet structure), full names and perhaps the email address in the intranet. The special:login and logout functions are disabled to prevent logging into a certain user account with other methods than the auto-login. The login and logout links in the skins are removed, but should a user come across the special functions by special knowledge, s/he sees a short notice "disabled ..." and is redirected to the Main_page . This patch can be enabled or disabled by a global Admin option $wgHostnameAutoLogin in LocalSettings.php and is potentially useful for MediaWikis, which run in safe intranet environments: users do not have to learn how to set up or create user accounts, they are logged-in as they visited the wiki URL. Should the hostname detection fail or the hostname being not listed in the lookup-table, then the visiting user is treated as anonymous user and whitelist or blacklist options apply according to the wiki installation parameters as before.
(In reply to comment #0) > For small intranet MediaWikis, I have written a very short patch which does what > I call auto-login with auto-account-creation by the detected hostname. It uses > php gethostbyaddr()) for intranet MediaWikis in Setup.php and some few lines of > code in user.php and Special:Userlogin and Special:Userlogout. > > This patch means, that users are automatically logged-in into their accounts (if > existing) or that such an account is created on-the-fly, when a user visits the > wiki. > > A short table such as a plain text file holds a look-up table for > correspondences between hostnames (e.g. IP addresses, personal staff numbers or > something else depending on the intranet structure), full names and perhaps the > email address in the intranet. This patch is available on request of the community. Tom
Created attachment 290 [details] Flowchart (PNG) of the core of the algorithm in User:loadFromSession() Flowchart (PNG) of the core of the algorithm in User:loadFromSession(). It is called in any of these case, where the original code of loadFromSession() would return "false", i.e. the priorities are currently: 1. loadFromSession() if userid and password-hash of the cookies match the database entries, then log-in to that user. otherwise: 2. goto Auto-Login flowchart 3. if gethostbyaddr() (in Setup.php) failed to deliver a hostname which matches one of the lookup-table -> then the user stays anonymous (exit B in the flowchart) otherwise log-in or create an account for username(hostname) according to the flwochart. In companies and cases where there are two staff members with exact the same name "Givenname Familyname", the first visiting the wiki gets his name as user accoutnname, the second and third and so on gets "Givenname Familyname (userid)", as account name. Those with the same name will surely have different staff ids/hostnames in a company. The table layout: My "table" looks like hostname|name|emailaddress "hostname" as seen by a gethostbyaddr() command in Setup.php "name" in UTF-8(preferred) or ISO-88859-1 according to the coding of your wiki. "emailaddress" for the user with accoutnanme "name" Example: AEA12345|Albert Einstein|aeinstein@xyz.com one entry per line, character encoding must correspond to wiki encoding; use command "iconv -f xxxxx -t yyyyyy" if needed to convert the file once. The IP address of the user is translated to the hostname (here: AE12345) which is for example your staff identity code in a company. Then my auto-login / auto-create logs you immediately into your account (or creates it) with account name (=wiki user account) "Albert Einstein" - if no valid cookie for the corresponding userid is detected from the session (see explanation above)
Excellent work Tom. The flowchart helps explains things. I would like to see the patch for this to be posted. The community can then verify so it can then be included.
In my original posting I forgot: The existing database field user_real_name - the fieldname is misleading here - in table user is now used for storing a user's unique "userid" (e.g. personal staff number or a similar string as detected by gethostbyaddr() ), so that there is no need to modify tables. To avoid abuse, the switch $wgAllowRealName is set to false in DefaultSettings.php, user_real_name cannot be set by the users any longer: they are filled during auto-account-creation, see flowchart. With the patch applied, the fields in the table user become the following meanings: user_id: user_id (unchanged; mediawiki's internal userid) user_name/accountname(*): "Givenname Familyname" = function(*) of lookup-table LUT(user_real_name) user_real_name: hostname of the computer as detected by gethostbyaddr() = staff number or similar unique string user_email: user e-mail address = function of LUT(user_real_name) (*) Conflict resolution for distinct persons, having exactly the same "Givenname Familyname" in a company (and in the LUT): The first user coming to the wiki gets "Givenname Familyname" as user_name (this is the mediawiki accountname as shown on pages, recent changes and so on); all further wiki visitor(s) get "Givenname Familyname (user_real_name)" as accountname to make the account disctinct from each other. [The patch will be published in a couple of days or mail me]
Created attachment 297 [details] sniplet for User.php of Mediawiki 1.3.7 This is the program code implementing the algorithm as shown in the flowchart of this bugzilla. The lookup-table is very simple, for each allowed user, create a line with three field separated by a vertical pipe bar "|" The Fullname is usually "Givenname Familyname" such as "Albert X. Einstein": hostname | Full Name | email-address AE12345|Albert X. Einstein|aeinstein@domain.tld and so on Remember: within this patch the "hostname" is permanently saved in the database table user in field user_real_name , which must be disabled for use in Default- or LocalSettings.php $wgAllowRealName=false; as explained above.
Is the patch still available for this fix? I think it would be very useful for the community especially for integrating into intranets.
Created attachment 332 [details] fixed a bug. Sniplet is for user.pgp, specialpreferences.php of mediawiki 1.3.7; probably easy to adapt for other version In Specialpreferences.php, setting of the realname field is skipped if $wgHostnameAutoLogin method is enabled. This patch works fine with Mediawiki 1.3.7 and can perhaps easy be adapted for other versions. I'll check how this patch works with 1.3.11 and 1.4 tonight; if it's fine, then I'll probably ask to integrate the method into CVS. Tom
Brion listening ? Brion: I could imagine of having this tiny code in the CVS HEAD version, as it is an optional code. It is admittedly not suited for Wikipedia, but for small/medium/large scale intranet mediawiki implementations. On your request I can add some short installer code for config/ . The Auto-login code as presented herein _is_ already configurable: a new global switch $wgHostnameAutoLogin enables or disables the whole. Summary of this patch: Based on a detected hostname gethostbyaddr(), the wiki automagically logs into (or creates) an account with that name - the hostname may be translated to a username by a look-up table. The LUT translates the unique hostname to a users natural name (Givenname Familiyname) and his/her primary email address, the natural name used as the wiki account name. A conflict resolution for persons with the same natural name is built in: in such cases, the second and further persons with the same name get their unique hostnames added in parentheses to their account name. The program is short, easy and works since 6 weeks in my company without problems. It saves users to create an account. The normal create/login/logoff account functions can be disabled fully, as they are not needed when using this patch. If the developers request, I can supply a replacement code for these routines, too.
The patch can easily be enhanced with NTLM authentication. This detects in Windows networks the logged-in user by using NTLM HTTP Authentication, see [1-4] . Basically, instead of reading the host name with gethostbyaddr(), one can use $_SERVER['REMOTE_USER'] which is supplied by the Apache Server with the logged-in user name after NTLM authentication via the browser. A patch can be published on request. --- [1] http://en.wikipedia.org/wiki/NTLM background info and links [2] http://www.thebluesmokeband.com/mod_ntlm.php nice reading [3] http://modntlm.sourceforge.net Official mod_ntlm [4] http://modntlm.jamiekerwick.co.uk/ Inofficial mod_ntlm
Created attachment 385 [details] flow chart (PNG 300 KB) for Auto-Login / Auto-Account creation based on either hostname (by gethostbyaddr() ) or logged-in user ( NTLM authentication)
(In reply to comment #9) Appreciate the patch: lack of autologin is one of the things that's kept us from using MediaWiki for course wikis. Still, we need to use HTTP Basic authentication (behind pubcookie) so I had to rework it a bit. Seemed a good idea to separate the site-specific stuff from code that any autologin method will want. So I'm posting a trivial udiff patch against MediaWiki 1.4.0. With it, if $wgAutoLogin is true, User.php will call $wgAuth->AutoLogin() as appropriate and if it exists. Thus anyone can write an extension implementing autologin via lookuptable/ntlm/http/whatever by subclassing AuthPlugin. Can provide a (slightly-site-specific) HttpBasicAuthPlugin.php if anyone is interested.
Created attachment 394 [details] generic autologin patch generic autologin code for mediawiki 1.4.0 to be used with site-specific autologin extension
Created attachment 398 [details] Version 1.0-alpha: generic patch for Auto-Login / Auto-account-creation - see flowchart - for Mediawiki 1.4 Version 1.0-alpha: generic patch for Auto-Login / Auto-account-creation for Mediawiki 1.4; please see flowchart to understand, how it works. This version has one remaining problem: when you want to save a page, it shows you a preview. I need more time to find this problem - any help is welcome ! Tom
Created attachment 399 [details] Patch V1.1 1. Session problem appears to be solved 2. Everything seems to work as expected 3. Login/Logout links are suppressed in Monobook and Classic If anyone has suggestions, please let me know. From my point of view, the patch is okay and ready. A code peer-review from team of developers is highly recommended. See again my remarks filed separately w.r.t to problem in setup.php
Created attachment 400 [details] Patch V1.1 with a further comment (where to call LDAP server, if you wish)
Any chance of getting this patch against v1.5?
(In reply to comment #16) > Any chance of getting this patch against v1.5? Yes, of course, it is ready and integrated in EnotifWiki for MediaWiki1.5rc4 see http://www.enotifwiki.org (download, CVS and helpdesk page on the BerliOS Open Source server - I moved away from Sourceforge, because this is so slow).
If you'd like to package an extension for it, great. It's not useful for MediaWiki's core target base however.
(In reply to comment #9) > The patch can easily be enhanced with NTLM authentication..... A patch can be published on request.---[1] I'm interessed in this solution, please can you publish this patch ?
(In reply to comment #19) > I'm interessed in this solution, please can you publish this patch ? Sorry, I'm not very familiar with PHP. Possibly the patch i asked for (NTLM Auth) is already included in patch v1.1 ?
It would be highly desirable to reopen this bug, but not necessarily to include NTLM authentication into the code base - just an ability to write such extension without modifying the main code (similar to authentication plug-in)
(In reply to comment #21) > It would be highly desirable to reopen this bug, but not necessarily to include > NTLM authentication into the code base - just an ability to write such extension > without modifying the main code (similar to authentication plug-in) There is no dependency on NTLM authentication - the Auto-Login/Auto-Creation relies only on a unique and authenticated value in the environment/server variable REMOTE_USER . The flowchart ( http://bugzilla.wikimedia.org/attachment.cgi?id=385&action=view ) shows NTLM authentication as an example for a scheme, which delivers this value. But see also the following box "optionally: try other authentication methods" in the flowchart. _Any_ scheme will work which places i.e. an userid or logon user name into that value REMOTE_USER; Remark: the current version of http://www.enotifwiki.org has this patch applied and can be switched by setting $wgAutoLogin = true ; see http://cvs.berlios.de/cgi-bin/viewcvs.cgi/enotifwiki/enotifwiki/includes/DefaultSettings.php lines 1467 seq. You can easily download EnotifWiki, which currently is MediaWiki1.5rc4 and will be upgraded soon, from the BerliOS server.
(In reply to comment #22) > Remark: the current version of http://www.enotifwiki.org has this patch applied > and can be switched by setting $wgAutoLogin = true ; see > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/enotifwiki/enotifwiki/includes/DefaultSettings.php > lines 1467 seq. > > You can easily download EnotifWiki, which currently is MediaWiki1.5rc4 and will > be upgraded soon, from the BerliOS server. Tom, you misunderstood my point - what i would like is a single source tree, without a separate project (i.e. EnotifWiki) that tries to stay in sync and continuously applying patches to the core code. If we have a common core code that is easy to extend, we can write any authentication plugins, such as NTLM or any other, and never worry that mediawiki code got updated - simply because we will be using documented extension API. Authentication plugin does exactly that - i don't need to worry (at least in theory) that the very next version of mediawiki will break that plugin. I don't need to wait for EnotifWiki to apply the changes from 1.5.4 to 1.5.5 to get them - i simply download the latest version of mediawiki 1.5.5 and it just continues to work with the plugins that i already configured. Ideally, what i would really like, is for the core code to be designed in such a way as too allow any kind of functionality extension without changes to the core. Authentication, rendering manipulations, and markup WYSIWYG editor to name just a few. MediaWiki has done a great job - it already allows authentication plugins (that give ability to authenticate using LDAP), and markup extensions (allows source code syntax highlighting, geo info, etc). NTLM plugin misses some functionality from the core, and thus requires core modifications that i would like to avoid for the above reasons.
