(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
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)

attachment AutoLogin.png ignored as obsolete

marcus wrote:

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
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.

attachment AutoLogin.php ignored as obsolete

marcus wrote:

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
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

attachment AutoLogin.php ignored as obsolete

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
flow chart (PNG 300 KB) for Auto-Login / Auto-Account creation based on either hostname (by gethostbyaddr() ) or logged-in user ( NTLM authentication)

Attached:

bruno wrote:

(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.

bruno wrote:

generic autologin patch

generic autologin code for mediawiki 1.4.0 to be used with site-specific
autologin extension

attachment mediawiki.diff ignored as obsolete

Created attachment 398
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

attachment x.diff ignored as obsolete

Created attachment 399
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

attachment x.diff ignored as obsolete

Created attachment 400
Patch V1.1 with a further comment (where to call LDAP server, if you wish)

Attached:

dax wrote:

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.

Udo.Adametz wrote:

(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 ?

Udo.Adametz wrote:

(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.