Extension:Auth remoteuser/ru
![]() Статус релиза: стабильно |
|
---|---|
Реализация | Идентификация пользователя , Хук |
Описание | Automatically logs-in users if they are already authenticated by a remote source (e.g. environment variable REMOTE_USER ). |
Автор(ы) |
|
Последняя версия | 2.1.1 |
MediaWiki | >= 1.35.0 |
PHP | 5.4+ |
Изменения в БД | Нет |
Composer | mediawiki/auth-remoteuser |
Лицензия | GNU General Public License 2.0 или позднее |
Скачать | README |
Legacy parameters:
|
|
Ежеквартальные загрузки | 289 (Ranked 16th) |
Переведите расширение Auth remoteuser | |
Проблемы | Открытые задачи · Сообщить об ошибке |
The Auth remoteuser extension automatically logs-in users if they are already authenticated by an arbitrary remote source. The extension maps the given remote user name to an existing user name in the local wiki database (or creates it first if it has the permissions to do so). The external source takes total responsibility in authenticating that user.
This allows integration with the web server's built-in authentication system (for example via the REMOTE_USER
environment variable, which is set through HTTP-Auth[1], LDAP[2], CAS[3], PAM[4], etc.) or any other type of external authentication (SSL[5] client auth, user accounts provided by different forum software, etc.).
Установка
- Скачайте и распакуйте файл(ы) в папку с названием
Auth_remoteuser
в вашей папкеextensions/
.
Вместо этого разработчикам и соавторам кода следует установить расширение из Git, используя:cd extensions/
git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Auth_remoteuser - Добавьте следующий код в конце вашего файла LocalSettings.php :
wfLoadExtension( 'Auth_remoteuser' );
- Готово – Перейдите на страницу Special:Version на своей вики, чтобы удостовериться в том, что расширение успешно установлено.
Конфигурация
Take account of MediaWikis global permissions for account creation (createaccount
or autocreateaccount
) inside your LocalSettings.php
.
At least one of them must be true
for anonymous users to let this extension create accounts for users as of yet unknown to the wiki database.
If you set this to false
, then automatic login works only for users who have a wiki account already.
- Примеры
// The extension can create accounts, because all anonymous users can. $wgGroupPermissions['*']['createaccount'] = true;
// If account creation by anonymous users is forbidden, then allow it to be created automatically (by the extension). $wgGroupPermissions['*']['createaccount'] = false; $wgGroupPermissions['*']['autocreateaccount'] = true;
// Only login users automatically if known to the wiki already. $wgGroupPermissions['*']['createaccount'] = false; $wgGroupPermissions['*']['autocreateaccount'] = false;
Параметры
Add some of the following global variables to your LocalSettings.php
to adjust the extensions behaviour to your specific needs.
Default values for each global are marked with the "// default
" comment in the examples section.
global | описание и примеры |
---|---|
$wgAuthRemoteuserUserName
|
Set the name(s) to use for mapping into the local wiki user database. This can either be a simple string , a Closure [6] or a mixed array of strings and/or Closure . If the value is null , the extension defaults to using the environment variables REMOTE_USER and REDIRECT_REMOTE_USER . The first name in the given list, which can be used as a valid MediaWiki user name, will be taken for login (either by login to an existing wiki account or by creating first):
|
$wgAuthRemoteuserUserNameReplaceFilter
|
This extension comes with predefined remote user name filters (which are utilizing the provided hook). If you want to replace something, set an array of search and replacement patterns to the following configuration variable (Each pattern can be a regular expression in PCRE[7] syntax too):
|
$wgAuthRemoteuserUserNameBlacklistFilter
|
If you want to prevent some names from being logged in automatically, blacklist them with the following filter. It accepts a list of names, where each name can also be a regular expression in PCRE syntax:
|
$wgAuthRemoteuserUserNameWhitelistFilter
|
The opposite of the UserNameBlacklistFilter can be achieved by using the following filter, which permits the automatic login instead of preventing it:
|
$wgAuthRemoteuserUserPrefs
|
When you have further user information available in your environment, which can be tied to a created user, for example email address or real name, then use one of the following configuration variables. Either UserPrefs or UserPrefsForced , which applies them to new users only or force them by applying them on each request. This can be useful if you don't want the user to change this preference inside MediaWiki (for example your company email address given by a remote source). They are expecting an array of key value pairs of which realname and email corresponds to the new users real name and email address. Any further key value pair specified gets mapped to a user preference of the same name. But take note of MediaWikis $wgDefaultUserOptions and $wgHiddenPrefs for declaring user preference options. In most cases these globals are better suited for a definition of a default value and disabling their modifiability:
You can specify an anonymous function for the values too.
These closures getting called when the actual value is needed, and not when it is declared inside your
Take the following as an example in which a cost-intensive function (in a timely manner) is getting executed only once per user and not on every request:
|
$wgAuthRemoteuserUserUrls
|
You can replace URLs in MediaWiki, if your remote source is better suited for handling specific behaviour. For example by default no automatically logged-in user is allowed to logout (because he will be logged-in automatically again with the next request). But maybe your remote source should handle that logout (so that with the next request there isn't a remote user name provided anymore to this extension). Set an appropriate URL to one of the following keys of the associative array $wgAuthRemoteuserUserUrls :
|
$wgAuthRemoteuserAllowUserSwitch
|
By default this extension mimics the behaviour of Auth_remoteuser versions prior v2.0.0 , which prohibits using another local user then the one identified by the remote source. You can change this behaviour with the following configuration:
|
$wgAuthRemoteuserRemoveAuthPagesAndLinks
|
As an immutable SessionProvider (see AllowUserSwitch config above) all special pages and login/logout links for authentication aren't needed anymore by the identified user. If you still want them to be shown, for example if you are using other session providers besides this one, then set the following accordingly:
|
$wgAuthRemoteuserPriority
|
If you are using other SessionProvider extensions besides this one, you have to specify their significance by using an ascending priority:
|
Legacy parameters
You can still use all legacy parameters from versions prior v2.0.0
, but their usage is deprecated in favour of the new parameters:
$wgAuthRemoteuserAuthz = true; /* Your own authorization test */
$wgAuthRemoteuserName = $_SERVER["AUTHENTICATE_CN"]; /* User's name */
$wgAuthRemoteuserMail = $_SERVER["AUTHENTICATE_MAIL"]; /* User's Mail */
$wgAuthRemoteuserNotify = false; /* Do not send mail notifications */
$wgAuthRemoteuserDomain = "NETBIOSDOMAIN"; /* Remove NETBIOSDOMAIN\ from the beginning or @NETBIOSDOMAIN at the end of a IWA username */
/* User's mail domain to append to the user name to make their email address */
$wgAuthRemoteuserMailDomain = "example.com";
Provided hooks
When you need to process your remote user name before it can be used as an identifier into the wiki user list, for example to strip a Kerberos principal from the end, replacing invalid characters, or blacklisting some names, use the hook AuthRemoteuserFilterUserName
provided by this extension.
Just have a look at MediaWikis Hook documentation on how to register additional functions to this hook.
It provides as first parameter the remote user name by reference to the hook function.
If the function returns false
, the remote user name will be ignored for automatic login.
(See parameters $wgAuthRemoteuserUserNameReplaceFilter
, $wgAuthRemoteuserUserNameBlacklistFilter
or $wgAuthRemoteuserUserNameWhitelistFilter
for predefined filters which utilizing this hook.)
Configuring different remote sources
- Setup
REMOTE_USER
environment variable
This environment variable can be set by many different authentication systems and the configuration of these is heavily dependent on which one you are using.
You can always use phpinfo();
to check the contents of REMOTE_USER
and to troubleshoot your setup.
What follows are examples of different webserver environments and how to put a username into this environment variable.
Apache
Consult the Apache documentation for details.
You can use mod_auth_ldap
, mod_auth_cas
, mod_auth_pam
, mod_auth_kerb
, mod_auth_vas4
or any other authentication module that utilizes REMOTE_USER
.
Once you have verified that the REMOTE_USER
environment variable is being set to the proper username, continue with installation/configuration of the extension.
Some examples:
- For simple HTTP authentication add this
.htaccess
:
AuthType Digest AuthName Wiki AuthUserFile /etc/passwd-apache Require valid-user
- The
REMOTE_USER
environment variable is getting evaluated by default from the extension, so the following code is all you need in yourLocalSettings.php
:wfLoadExtension( 'Auth_remoteuser' );
- Setup HTTP SPNEGO[8] with Vintella/Quest Authentication Services for your heterogeneous network, using
.htaccess
:
AuthType VAS4 AuthVasRemoteUserMap default AuthVasUseBasic On AuthName Wiki Require valid-user
- Now the
REMOTE_USER
environment variable contains the full principal name, so remove the realm from the username inside yourLocalSettings.php
with:wfLoadExtension( 'Auth_remoteuser' ); $wgAuthRemoteuserUserNameReplaceFilter = [ '@INTRA.EXAMPLE.COM$' => '' ];
Kerberos SSO AD
Prerequisites:
To install & enable them in Devuan:
apt install libapache2-mod-auth-kerb a2enmod authnz_ldap
Configure Kerberos in the OS (long story short):
- Join to AD domain:
- realm join corp.ds.company.net -U domain_user_with_rights_to_join --computer-ou="use dsquery computer in windows cmd domain joined machine to get the value" --verbose
- Generate keytab on Windows AD server cmd:
- ktpass -princ HTTP/en.mediawiki.company.net@CORP.DS.COMPANY.NET -mapuser mediawiki_windows_domain_user@CORP.DS.COMPANY.NET -pass mediawiki_windows_domain_user_secret_password -crypto all -ptype KRB5_NT_PRINCIPAL -out C:\Temp\en-mediawiki.keytab
- setspn -A HTTP/en.mediawiki.company.net@CORP.DS.COMPANY.NET mediawiki_windows_domain_user@CORP.DS.COMPANY.NET
Apache con file:
AuthType Kerberos Krb5Keytab /path/to/your/keytab_file.keytab KrbServiceName Any KrbLocalUserMapping On AuthLDAPBindDN "user_name_to_authenticate_to_LDAP_server" AuthLDAPBindPassword "password_for_the_user_from_above" AuthLDAPURL "http://ldap_server_url/DC=CORP,DC=DS,DC=COMPANY,DC=NET?sAMAccountName,mail,displayName?sub?(objectClass=*)" Require ldap-attribute attribute="value"
It is required to use LDAP authorization together with Kerberos SSO[9] if you want to get user information (email, real name) from AD.
The info from LDAP must be published to AUTHORIZE_ environment variables, so make sure you use it, not AUTHENTICATE_ in LocalSettings.php.
Using ldap-group did not publish environment variables for me, using ldap-attribute did (a bug in apache?).
IIS
Depending on your version of Internet Information Services (IIS) Manager, your navigation may be slightly different. The instructions below are specified for a corporate server running IIS v7.5 on Windows Server 2008 R2 Enterprise. (Trust me, I wanted Linux and Apache but IT wont allow it)
To enable simple authentication navigate to the following paths.
- IIS
- (Server Name) > Sites > Default Web Site
- From "Features View" double click, "Authentication"
- Disable — "Anonymous Authentication"
- Enable — "Windows Authentication" (HTTP 401 Challenge)
Support
Known issues
This extension gets managed as a project on Phabricator.
There you can see a list of all known and still open issues. If there is no open task related to the problem/error you've encountered, then have a look on howto report errors.
Howto debug
Read the MediaWiki manual on debugging or take the following as a start:
- Enable logging by setting the
$wgDebugLogFile
inside yourLocalSettings.php
to a file to which your webserver has write access to. - Request your MediaWiki installation like you did when the error occurred. This extension logs all its output to the
[session]
channel into your log file. - Inspect the log file and search for all lines starting with
[session]
. - Decide if you can fix the error by yourself or if it is related to how this extension works. If so, then have a look on howto report errors.
Report errors
Assemble relevant debugging information (relevant in terms of others can reproduce the error) and:
- Either read MediaWiki's howto on reporting bugs, or
- create a new task on this extensions Phabricator project (if you have a Phabricator account), or
- write an email to members of the Phabricator project, or
- use this extensions talk page.
Contribute
You're welcome to enhance this extension.
Read How_to_become_a_MediaWiki_hacker, grab one of the open issues from the Phabricator project (or create a new task) and upload your patch to this extensions Gerrit project. There you can also see:
- a list of current extension maintainers with write access (if you have a Gerrit account),
- a list of uploaded patch sets.
Feature requests
Just use the same workflow as with error reporting.
Notes
- ↑ authentication by HTTP (RFC 2617)
- ↑ Lightweight Directory Access Protocol (LDAP)
- ↑ Central Authentication Service (CAS)
- ↑ Pluggable authentication module (PAM)
- ↑ Secure Sockets Layer (SSL)
- ↑ closure — anonym function without name
- ↑ Perl Compatible Regular Expressions (PCRE)
- ↑ Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO)
- ↑ Single sign-on
Это расширение включено в следующие вики-фермы/хостинги и/или пакеты: Это не исчерпывающий список. Некоторые вики-фермы/хостинги и/или пакеты могут содержать это расширение, даже если они не перечислены здесь. Всегда сверяйтесь со своими вики-фермами/хостингами или комплектами/бандлами для подтверждения. |