Last modified: 2010-05-15 15:32:59 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1360 - Auto-login / Auto-account-creation by hostname for intranet MediaWikis
Auto-login / Auto-account-creation by hostname for intranet MediaWikis
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.4.x
All All
: Lowest enhancement with 3 votes (vote)
: ---
Assigned To: T. Gries
: patch
Depends on: 1805
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-19 08:16 UTC by T. Gries
Modified: 2010-05-15 15:32 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Flowchart (PNG) of the core of the algorithm in User:loadFromSession() (165.50 KB, image/png)
2005-02-16 06:58 UTC, T. Gries
Details
sniplet for User.php of Mediawiki 1.3.7 (4.52 KB, text/x-csrc)
2005-02-18 22:05 UTC, T. Gries
Details
fixed a bug. Sniplet is for user.pgp, specialpreferences.php of mediawiki 1.3.7; probably easy to adapt for other version (4.82 KB, text/plain)
2005-03-03 21:32 UTC, T. Gries
Details
flow chart (PNG 300 KB) for Auto-Login / Auto-Account creation based on either hostname (by gethostbyaddr() ) or logged-in user ( NTLM authentication) (294.96 KB, image/png)
2005-03-25 14:02 UTC, T. Gries
Details
generic autologin patch (2.31 KB, patch)
2005-03-28 15:48 UTC, Bruno Browning
Details
Version 1.0-alpha: generic patch for Auto-Login / Auto-account-creation - see flowchart - for Mediawiki 1.4 (12.45 KB, patch)
2005-04-02 21:31 UTC, T. Gries
Details
Patch V1.1 (14.26 KB, patch)
2005-04-03 15:28 UTC, T. Gries
Details
Patch V1.1 with a further comment (where to call LDAP server, if you wish) (14.40 KB, patch)
2005-04-03 15:41 UTC, T. Gries
Details

Description T. Gries 2005-01-19 08:16:29 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.
Comment 1 T. Gries 2005-02-16 06:23:40 UTC
(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
Comment 2 T. Gries 2005-02-16 06:58:40 UTC
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)
Comment 3 Marcus Kazmierczak 2005-02-16 16:47:36 UTC
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.
Comment 4 T. Gries 2005-02-17 07:21:21 UTC
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]
Comment 5 T. Gries 2005-02-18 22:05:56 UTC
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.
Comment 6 Marcus Kazmierczak 2005-03-03 20:03:23 UTC
Is the patch still available for this fix?
I think it would be very useful for the community
especially for integrating into intranets.
Comment 7 T. Gries 2005-03-03 21:32:54 UTC
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
Comment 8 T. Gries 2005-03-05 11:44:19 UTC
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.
Comment 9 T. Gries 2005-03-16 00:22:02 UTC
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
Comment 10 T. Gries 2005-03-25 14:02:33 UTC
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)
Comment 11 Bruno Browning 2005-03-28 15:46:36 UTC
(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.
Comment 12 Bruno Browning 2005-03-28 15:48:18 UTC
Created attachment 394 [details]
generic autologin patch

generic autologin code for mediawiki 1.4.0 to be used with site-specific
autologin extension
Comment 13 T. Gries 2005-04-02 21:31:47 UTC
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
Comment 14 T. Gries 2005-04-03 15:28:20 UTC
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
Comment 15 T. Gries 2005-04-03 15:41:24 UTC
Created attachment 400 [details]
Patch V1.1 with a further comment (where to call LDAP server, if you wish)
Comment 16 Dax Kelson 2005-09-06 19:15:02 UTC
Any chance of getting this patch against v1.5?
Comment 17 T. Gries 2005-09-06 20:31:05 UTC
(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).
Comment 18 Brion Vibber 2005-09-06 22:39:39 UTC
If you'd like to package an extension for it, great. It's not useful for 
MediaWiki's core target base however.
Comment 19 Udo Adametz 2005-10-06 15:00:19 UTC
(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 ?
Comment 20 Udo Adametz 2005-10-07 08:30:17 UTC
(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 ?



Comment 21 Yuri Astrakhan 2005-12-04 02:40:23 UTC
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)
Comment 22 T. Gries 2005-12-04 07:30:34 UTC
(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.
Comment 23 Yuri Astrakhan 2006-01-17 02:22:05 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links