Para obtener ayuda sobre la personalización de los derechos de usuario, consulta Manual:Derechos de usuarios . Esta página contiene ejemplos útiles para restringir el acceso.

Para más información sobre cómo editar LocalSettings.php, consulta Manual:LocalSettings.php . Para una mejor restricción de accesos, considera Extension:AccessControl o Extensión:ConfirmAccount .

Wiki privado sencillo

Para el caso de uso común de «un wiki privado, para uno mismo y otros usuarios autorizados», debes:

• § Restringir la visualización
• § Restringir la edición
• § Restringir la creación de cuentas de usuario

Advertencia:

No utilices el código de ejemplo sin someterlo a pruebas exhaustivas y sin personalizarlo. El código proporcionado es básico e incompleto para un uso real. Puede no bloquear el acceso de todas las maneras posibles, puede causar problemas con otras extensiones y hasta podría mostrar información de forma accidental. For better access restriction, consider Extension:AccessControl or Extension:ConfirmAccount.

# Deshabilitar la lectura para usuarios anónimos
$wgGroupPermissions['*']['read'] = false;

# Deshabilitar la edición para usuarios anónimos
$wgGroupPermissions['*']['edit'] = false;

# Impedir nuevos registros de usuarios excepto por operadores del sistema
$wgGroupPermissions['*']['createaccount'] = false;

Dependiendo de las extensiones que tengas instaladas, puede que desees añadir más páginas a la lista blanca. Por ejemplo, si utilizas la extensión Extensión:ConfirmAccount , probablemente quieras Special:RequestAccount esté en la lista blanca. Si el idioma de contenido de tu wiki no es el inglés, puede que tengas que utilizar el nombre traducido de las páginas especiales en cuestión.

Restringir la creación de cuentas

Para restringir la creación de cuentas, debes editar LocalSettings.php en la ruta raíz de tu instalación de MediaWiki.

# Impedir nuevos registros de usuarios excepto por operadores del sistema
$wgGroupPermissions['*']['createaccount'] = false;

1. Ve a Special:Userlogin habiendo iniciado sesión como operador de sistema.
2. Haz clic en el enlace «Crear cuenta» para acceder al formulario de creación de cuentas.

Introduce un nombre de usuario y una dirección de correo electrónico y haz clic en el botón «por correo electrónico». Ten en cuenta que necesitarás que $wgEnableEmail=true o en otro caso el operador de sistema tendrá que escoger una contraseña y enviársela al usuario.

1. Se creará la cuenta con una contraseña aleatoria que se enviará a la dirección dada de correo electrónico (al igual que con la funcionalidad de «¿has olvidado tu contraseña?»). Ante el primer inicio de sesión, se le pedirá al usuario que cambie la contraseña; una vez hecho esto, también se marcará la dirección de correo electrónico como confirmada.

   Si en su lugar haces clic en el botón «crear cuenta», deberás enviar la contraseña al usuario de forma manual.

También puedes modificar el contenido del correo enviado a los nuevos usuarios editando la página MediaWiki:Createaccount-text.

Para impedir incluso a los operadores de sistema la creación de cuentas:

# Impedir nuevos registros de usuarios por cualquier usuario.
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['sysop']['createaccount'] = false;

Para añadir un mensaje a la parte superior del formulario de inicio de sesión, modifica MediaWiki:Loginprompt.

Restringir la edición

$wgGroupPermissions['*']['edit'] = false;

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['sysop']['edit'] = true;

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['sysop']['edit'] = false;

# Permitir solo a los usuarios autoconfirmados la edición del espacio de nombres Project
$wgNamespaceProtection[NS_PROJECT] = array( 'autoconfirmed' );

# No permitas a nadie editar páginas que no sean de discusión hasta que hayan confirmado su dirección de correo electrónico (asumiendo que no tengamos espacios de nombres personalizados y que permitamos ediciones de usuarios que no hayan confirmado su dirección de correo electrónico, para empezar)
# Nota para 1.13: el grupo «emailconfirmed» y sus permisos fueron eliminados de la configuración predeterminada; si deseas utilizarlo, tendrás que volver a habilitarlo a mano
$wgNamespaceProtection[NS_MAIN]     = $wgNamespaceProtection[NS_USER]  =
$wgNamespaceProtection[NS_PROJECT]  = $wgNamespaceProtection[NS_IMAGE] =
$wgNamespaceProtection[NS_TEMPLATE] = $wgNamespaceProtection[NS_HELP]  =
$wgNamespaceProtection[NS_CATEGORY] = array( 'emailconfirmed' );

# Permitir solo a los operadores de sistema editar el espacio de nombres «Policy»
$wgGroupPermissions['sysop']['editpolicy'] = true;
$wgNamespaceProtection[NS_POLICY] = array( 'editpolicy' );

# Anonymous users can't create pages
$wgGroupPermissions['*']['createpage'] = false;

# Only users with accounts four days old or older can create pages
# Requires MW 1.6 or higher.
$wgGroupPermissions['*'            ]['createpage'] = false;
$wgGroupPermissions['user'         ]['createpage'] = false;
$wgGroupPermissions['autoconfirmed']['createpage'] = true;

If you have enabled the ability to upload files, these will be served directly by the underlying web server. As a result, account-based access to the file is unrestricted by default.

If sensitive files are uploaded to an internet-accessible wiki, you may wish to add restrictions on where these can be accessed from. On Apache, if your local network were 10.1.2.*, you could restrict serving files to local addresses with:

  <Location /mediawiki/images>
    Order deny,allow
    Allow from 10.1.2.3
    Deny from all
  </Location>

Advertencia:

If you want anonymous users to be unable to view the wiki markup/code, you should not allow them to edit any page (see § Restrict editing of all pages above). If they can edit any page, they can use template inclusion to view even pages they can't edit. This may be possible to avoid by using $wgNonincludableNamespaces

Advertencia:

This method allows any visitor to view the wiki after creating an account. You may wish to combine it with § Restrict account creation above.

Advertencia:

Uploaded images will still be viewable to anyone who knows the image directory's name. Either point $wgUploadPath to the img_auth.php script and follow the instructions in Manual: Autorización de imagen , or use some external method to protect images, like .htaccess.

Advertencia:

Wiki pages like MediaWiki:Common.css and MediaWiki:Gadget-foo.css may be part of a public ResourceLoader module, and thus can have their source code exposed through load.php. Turn off $wgUseSiteJs and $wgUseSiteCss to disable this functionality.

# Disable reading by anonymous users
$wgGroupPermissions['*']['read'] = false;

# But allow them to read e.g., these pages:
$wgWhitelistRead = [ "Main Page", "Help:Contents" ];

The $wgWhitelistRead setting allows users to view the main page. If page names have more than one word, use a space " " between them, not an underscore "_".

Advertencia:

If you are running a private wiki, you need to update to MediaWiki version 1.39.13 / 1.42.7 / 1.43.2 / 1.44.0 or later. There is a vulnerability (CVE-2025-6590) allowing any user viewing any pages in private wikis using older MediaWiki version. There are no workaround available.

MediaWiki was not designed to support per-page or partial-page access restrictions. If you require this level of control, you are strongly advised to use a content management system that supports it natively. Patches or third-party extensions claiming to provide access control may contain security flaws, potentially exposing confidential data. Use them at your own risk. Neither the MediaWiki developers nor the Wikimedia Foundation are responsible for any data leaks that may result. This message is added to all extensions of this nature and may not reflect the actual security status of this extension. For more information, see Security issues with authorization extensions .

To prevent anyone but sysops from viewing a page, it can simply be deleted . To prevent even sysops from viewing it, it can be removed more permanently using Manual:RevisionDelete . To completely destroy the text of the page, it can be manually removed from the database. In any case, the page cannot be edited while in this state, and for most purposes no longer exists.

To have a page act normally for some users but be invisible to others, as is possible for instance in most forum software, is a very different matter. MediaWiki is designed for two basic access modes:

This is the mode used by Wikipedia and its sister projects.

This is basically the same as the above, in terms of technical implementation (just an extra check for every page view), which is why it exists. This is the mode of operation used by certain private wikis such as those used by various Wikimedia committees.

If you intend to have different view permissions than that, MediaWiki is not designed for your usage. (Véase T3924 N Declined.) Data is not necessarily clearly delineated by namespace, page name, or other criteria, and there are a lot of leaks you'll have to plug if you want to make it so (see security issues with authorization extensions for a sample). Other wiki software may be more suitable for your purpose. You have been warned. If you must use MediaWiki, there are three basic possibilities:

See the section above.

You will have to reapply it every time you upgrade the software, and it may not be updated immediately when new security fixes or upgrades of MediaWiki are released. Third-party hacks are, of course, not supported by MediaWiki developers, and if you're having problems you shouldn't ask on MediaWiki-l, #mediawiki, or other official support channels. A number of hacks are listed in Category:Page specific user rights extensions . Read about security issues with authorization extensions if you plan to use one of those.

Véase también: Manual:Parámetros para Special:Export

If you want to completely remove access to a user, e.g. on a simple private wiki, it's not possible to simply delete the account (unless no edits have been made ); you can block it, but the user will still be able to read pages (unless $wgBlockDisablesLogin is set). However, using User Merge and Delete extension you can merge the account in another one and delete the former; the original account will then "disappear". If you want to preserve history readability (i.e., to have edits from the user to be still shown under their name), you can create a new account e.g. with username "OriginalUserName (deactivated)" and then merge "OriginalUserName" into the former, or even use Renameuser extension to rename "OriginalUserName" into "AnotherUserName", then create an account under "OriginalUserName" and merge "AnotherUserName" into it: in this manner, "OriginalUserName" will be completely "usurped" (if you've set a non-null password).

You may want to have pages editable only by their creator, or ban viewing of history, or any of a number of other things. None of these features are available in an unhacked version of MediaWiki. If you need more fine-grained permissions, see the #See also section for links to other wiki packages that are designed for this, as well as hacks that attempt to contort MediaWiki into something it's not designed to be but may work anyway.

• Manual:LocalSettings.php
• Manual:$wgGroupPermissions
• Manual:$wgRestrictionTypes
• Manual:$wgRestrictionLevels
• Manual:$wgNamespaceProtection
• Manual:$wgEmailConfirmToEdit
• Manual:$wgNonincludableNamespaces
• Manual:Derechos de usuarios
• Ayuda:Permisos y grupos de usuario

• MoinMoin
• TWiki
• TikiWiki - has fully configuable access control to features and permission levels.

If you want better access control but want to use MediaWiki, this is a list of extensions and hacks to allow restrictions not possible in the software proper. These hacks may be out-of-date (check the version they're for). Please don't ask in official MediaWiki support channels if something goes wrong with a third-party hack.

• Extension:Flagged Revisions
• Extensión:Moderación
• Extensión:Approved Revs
• Extension:Lockdown
• Extension:AuthorProtect
• Extension:EditSubpages - restricts anonymous users from editing most pages
• Extension:NSFileRepo