Extension:OpenID

From MediaWiki.org
Jump to: navigation, search
shortcut OPENID

This is the manual of the OpenID extension (in svn trunk) which is suited for MediaWiki trunk and PHP 5.3.x. If you need older deprecated versions, please consult one of the archived pages.

MediaWiki extensions manual - list
Crystal Clear action run.png
OpenID

Release status: stable

Implementation User identity, Special page
Description Allow users with accounts on other OpenID-enabled sites to log in; if enabled, it also allows to use user page urls as OpenID identities on other sites
Author(s) E. Prodromou, T. Gries, S. Chernyshev, A. Emsenhuber
Last version SVN trunk 1.001 (2012-02-20
see "Download" section)
MediaWiki stable version in trunk for MediaWiki trunk

stable versions for MW 1.15.1, 1.16.1 on request
Please reports other MW versions which you known are working.

PHP tested with 5.2.17 and all 5.3.x
Database changes php update.php was required until r89709
  1. OpenID> make
  2. maintenance/php update.php
License GPL
Download see "Download" section
Download snapshot
Subversion [Help]

Browse source code
View code changes

README

Example Special:OpenIDLogin
Parameters

(see below)

Hooks used
PersonalUrls

BeforePageDisplay
ArticleViewHeader
SpecialPage_initList
LoadExtensionSchemaUpdates
GetPreferences
DeleteAccount
MergeAccountFromTo

Check usage (experimental)
Bugs: list open list all report

The extension makes a MediaWiki installation OpenID 2.0-aware and lets users log in using their OpenID identity - a special URL - instead of (or as an alternative to) standard username/password log in. In that way, the MediaWiki acts as Relying part (RP) = OpenID consumer.[1] As an option, it also allows the MediaWiki to act as OpenID provider, so that users with an account on that wiki can use their userpage URL as OpenID with which they can log in to other OpenID-aware web sites.

Typical uses of OpenID and the OpenID extension for MediaWiki are:

  • Single-signon between multiple affiliated wikis and other sites.
  • Single-signon across the Internet. Many sites support OpenID, including Google, Yahoo, and Verisign. Allowing users to login with OpenID means one less step for them to create an account and to contribute to your wiki.
  • Distributed reputation. Logging into a new wiki with the same username as on another wiki does not prove that they are the same person, but logging in with OpenID from the old wiki does. In that way, OpenID can help building a distributed reputation across different sites.

It as been in use for years on several large wikis without known security[2] problems. However, no software is completely bug-free or secure, and there's no guarantee that this software will work as advertised.

Contents

[edit] Pre-requisites and dependencies

The OpenID extension version comes with a tiny "Makefile" which creates a sub directory in your extensions path, and downloads the required php-openid library in one go. Run "make" in you extensions folder; it satisfies the "requisite 1" which reading you can skip.

[edit] requisite 1: php-openid library

The extension depends on the PHP library for OpenID, which in turn depends on the OpenIDEnabled.com PHP library for YADIS. This package is called "php-openid library" here. The step of downloading and installing is automated by running "make" in your extensions folder.

[edit] requisite 2: PHP extensions or modules

You need to install a few additional dependencies as PHP extensions (or recompile your PHP[3]) if these are not part of your standard PHP installation. When running a server with OpenSUSE you often need to add via YaST or manually at least

gmp
mcrypt
curl
openssl

You can resolve the missing dependencies one by one: use YaST, add module, restart configure - or check your system's manual and the PHP documentaion how to install php5-modules. As an alternative, you can recompile PHP until the ./configure[3] command is fully statisfied and finishes without errors.[3] The php-openid OpenIDEnabled documentation README tells you more about the dependencies.

Note: Some versions of MediaWiki overwrite or extend the PHP library path in $IP/LocalSettings.php. You may need to add the path to your PHP library directory to the $path variable, like "/usr/share/php" or "/usr/local/share/php" as explained below.

[edit] Download

These are recommended revisions of OpenID use per MediaWiki version. If a revision does not work with a certain MediaWiki version, please report. In ViewVC, make sure to click the revision download link for each file, not the HEAD download link.

[edit] Installation

Warning Warning: Instructions are for the trunk version - they do not work with MediaWiki 1.17 or 1.18.

The installation is explained for OpenID extension versions 0.925-beta (and later) suited for MediaWiki trunk and contemporary PHP.
Note: $IP stands for the root directory of your MediaWiki installation, the same directory that holds LocalSettings.php.

1. make sure that you have the pre-requisites 2. Pre-requisite 1 will be downloaded by the makefile during step 3.

2. download from svn into a new subdirectory $IP/extensions/OpenID

cd $IP/extensions
$IP/extensions# svn checkout http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/OpenID OpenID

3. goto the OpenID directory and run make to download the library

 cd $IP/extensions/OpenID
 $IP/extensions/OpenID# make

4. In your MediaWiki $IP/LocalSettings.php, at the bottom of the file add

require_once( "$IP/extensions/OpenID/OpenID.php" );

5. Run update.php script in in your MediaWiki maintenance folder $IP/maintenance to create a new table in the MediaWiki database which is used by the OpenID extension:

$IP/maintenance# php update.php

It should work out of the box, but you'll almost definitely want to set the trust root and access controls (see Configuration below).

Note: If you restrict general access to wiki pages, you must add anonymous access for Special:OpenIDLogin and Special:OpenIDFinish or the OpenID Verification will fail. Typically this is done by adding those pages to $wgWhitelistRead in LocalSettings.php.

[edit] Logging in using OpenID (MediaWiki as OpenID consumer)

To log in to the wiki using an OpenID, go to the Special:OpenIDLogin page on the wiki. Add the OpenID identity URL to the login box, and click "Verify".

This should take you to the OpenID server for your identity, where you can either log in (if you're not already) or approve allowing the wiki to use your OpenID for logging in. If the OpenID server supports the Simple Registration Extension ('sreg'), it may also ask you whether to share personal information like your preferred nickname, real name, email address, etc. Choose as you wish.

Once you're logged in to your OpenID server, and you've finished approving the login, you should return to the wiki from whence you came automatically.

Every user who logs in with an OpenID identity for the first time will be assigned a "fake" username in the local wiki. (This just makes things work better.)

If you've allowed your nickname to be passed to the wiki, and it's not already taken, and it's a legal MediaWiki user name, then it should use that for your login automatically. If not, the extension will try to make up some good candidate usernames for you and present you with a choice. If you don't like any of them, you can make up your own.

After you're logged in, you can edit, read, write, and do all the other things that MediaWiki users do. Since you've got a "real" account, you'll also have a home page and a message page and such. It should also be possible to assign extra permissions ('sysop', 'bureaucrat') to the account. You can log out as normal.

To log back in, use the OpenIDLogin page again. Don't try to login using the regular login page, since it won't work.

You can log in with an Interwiki abbreviation of an URL right now, but that's experimental and may disappear in later versions. Don't fall in love with this convenient, useful feature. You may get hurt.

[edit] Using a MediaWiki account as an OpenID (MediaWiki as OpenID Server)

MediaWikis with the extension act as OpenID consumers (clients). They also can work as OpenID server, but only if the Wiki adminstrator has enabled this feature.

To log in to other OpenID-aware sites (consumer) with your MediaWiki account (OpenID server):

if, and only if you have a user account, and
if, and only if you have manually set a password to your account via Reset Password (link in your User profile preferences), and
if the user page exists (has some content)[4]

then your OpenID identity URL is the full URL of your non-empty MediaWiki user page

  http://www.server.org/wiki/index.php/User:MySelf

When you use this OpenID with another site, logging in should take you to the wiki site. You may need to enter your password if you're not already logged in (by cookie, or by session).

You'll then be asked if you want to let the other site log you in, and if you want the MediaWiki wiki to share your personal information (nickname, email, full name, language) with the other site. Choose what feels comfortable to you. For some sites, you may not be asked; see configuration below.

Once you've finished deciding, the other site will finish the login.

Note: You cannot log in through OpenID on the same server.
Note: It is not sufficient to have a user account: the user page needs to exist, it needs to have some content.
Note: The user account must have a password associated to it: in Special:Preference Password Reset is added as new link.

[edit] Configuration

These settings can be configured in the LocalSettings.php file.

Note: Place your parameters after the require_once line for the OpenID extension.
Configuration parameters for OpenID extension
variable default description
$wgOpenIDOnly false With this enabled, the default login peronal_urls will be removed and additionally the options for linking your OpenID to an existing account will be removed from the registration form. Users then can only login via their OpenID accounts. This is perhaps the most important option.
$wgOpenIDClientOnly true If true, user accounts on this wiki *cannot* be used as OpenIDs on other sites. If set to false, the MediaWiki can act als OpenID consumer and server. (The name of the variable and the default value might change in newer versions.)
$wgOpenIDAllowServingOpenIDUserAccounts false With this enabled, it allows to use User pages as OpenIDs even if user is using OpenID already. Users can use their user page URLs of this site A as OpenID on another site B even if user is using OpenID on A already. Some users might want to do that for vanity purposes or whatever. If false, prevent serving OpenID accounts (this was an TODO list item)
$wgTrustRoot This is an URL that identifies your site to OpenID servers. Typically, it's the "root" url of the site, like "http://en.wikipedia.org/" or "http://wikitravel.org/it/". If this is not set, the software will make a half-hearted guess, but it's not very good and you should probably just set it.
$wgOpenIDConsumerDenyByDefault The administrator can decide which OpenIDs are allowed to login to their server. If this flag is true, only those OpenIDs that match one of the $wgOpenIDConsumerAllow and not one of the $wgOpenIDConsumerDeny patterns will be allowed to log in. If it is false, all OpenIDs are allowed to log in, unless they are matched by an $wgOpenIDConsumerDeny pattern and not an $wgOpenIDConsumerAllow. Typically you'll set this to true for testing and then false for general use.
$wgOpenIDConsumerAllow an array of regular expressions that match OpenIDs you want to allow to log in. For example, "@^(http://)?wikitravel.org/@" will allow OpenIDs from the Wikitravel domain.
$wgOpenIDConsumerDeny an array of regular expressions that match OpenIDs you want to deny access to. This is mostly useful for servers that are known to be bad. Example: "#^(http://)?example.com/#".
$wgOpenIDServerForceAllowTrust an array of regular expressions that match trust roots that you want to skip trust checks for when the user logs in from those sites. A typical example would be a closely federated cluster of sites (like Wikimedia, Wikia, or Wikitravel) where the personal data is available to the trusting server anyways. Be very careful using this across organizational boundaries.
$wgOpenIDUseEmailAsNickname false when first-time logging-in with OpenID, use the part before the @ in any given e-mail address as the username if a nickname is not given by the OpenID. This works well with $wgOpenIDConsumerForce where all users have a unique e-mail address at the same domain.
$wgOpenIDProposeUsernameFromSREG[5] true when first-time logging in with OpenID, propose and allow new account names from OpenID SREG data such as fullname or nickname
$wgOpenIDAllowManualUsername[5] true when first-time logging in with OpenID, show option to enter and to allow a manually chosen username
$wgOpenIDAllowAutomaticUsername[5] true when first-time logging in with OpenID, show option to choose and to allow an automatically generated username
$wgOpenIDConsumerStoreType
$wgOpenIDServerStoreType strings denoting the type of storage to be used to store OpenID association data when acting as an OpenID relying party (consumer) and server, respectively. Only valid value is "file"; "memc" no long valid.
$wgOpenIDConsumerStorePath
$wgOpenIDServerStorePath strings specifying the paths where OpenID assocation data should be stored when acting as a relying party (consumer) or server, respectively. Each of these need only be set if the store type settings (above) are set to "file", respectively. These strings, if both are set, MUST NOT be equal. If the store type is "file", the default here is "/tmp/$wgDBname/openidconsumer/" and "/tmp/$wgDBname/openidserver/" respectively. The path will be automatically created if it doesn't exist at runtime.
$wgHideOpenIDLoginLink boolean that says whether or not to hide the OpenID login link in the personal URLs. Typically you'd use this if you've already got some other method for showing the OpenID login link, like in your skin. Note that it will not prevent login if the user navigates to Special:OpenIDLogin directly; it's simply cosmetic. This is mostly a backwards-compatibility option.
$wgOpenIDLoginLogoUrl Url of the OpenID login logo. Defaults to http://www.openid.net/login-bg.gif, but you may want to move it to a local URL, or an URL on a CDN, if that kind of thing floats your boat.
$wgOpenIDShowUrlOnUserPage "never" whether to show the OpenID identity URL on a user's home page. Possible values are
  • "never"
  • "user" (let the users decide in their preferences)
  • "always"
$wgOpenIDShowProviderIcons false defaults to false due to potential brand issues. With this enabled, users will see button graphics instead of just links in OpenID provider UI.
$wgOpenIDConsumerForce Url of required OpenID provider. When this is set it bypasses the OpenID provider selection form.

[edit] OpenID servers (where you can register an OpenID)

Note: In case of https:// OpenID identities, the extension accepts them only if the associated server certificate is valid and trusted. It does not work with self-issued, self-signed, or expired certificates.

The following non-comprehensive list of OpenID services shows those with which the extension has been tested in the past. All have free signup for identities.

Free OpenID providers
OpenID provider comments
http://www.google.com smart and reliable, very quick response
http://pip.verisignlabs.com/ recommended by the extension maintainer.

Verisign is a fully featured free OpenID provider with many OpenID-standard-conform features
quick response

http://openid.yahoo.com only basic features; slow response
http://www.myopenid.com/ simple registration extension
http://getopenid.com/
http://www.typekey.com/
http://www.claimid.com/
http://openid.35.com/
http://certifi.ca/

[edit] "It does not work": bugs, common pitfalls

Please check our First aid checklist before asking for help. Report a bug: see info box.
  • one MediaWiki acting as OpenID server Bob does not work with another or same MediaWiki acting as OpenID consumer Alice on the same server. Advice for the moment: use two different servers while playing with the extension
  • when you want to log in to your OpenID-consuming MediaWiki Alice as user X:
make sure that your are not logged in to the OpenID identity server Bob as another user Z ; otherwise you will see an error, which is intended.
I recommend you log out every persona you may have on server Bob while testing the extension
clear your browser cache of all Bob-related cookies, and session cookie.
The OpenID authentication process flow will redirect you from Alice to Bob. Bob will then prompt you to log in and hopefully everything works.
  • If you see
PHP Fatal error: Define Auth_OpenID_RAND_SOURCE as null to continue with an insecure random number generator.
in $IP/extensions/OpenID/Auth/OpenID/CryptUtil.php on line 52

follow the instruction and define the value to null. The internet community says "No you are not compromising anything."[6][7]

[edit] information for legacy version users

Please consult older page versions for more detailed information and special cases, or check our discussion page.

[edit] Deinstallation

If you want to deinstall the OpenID extension without remains. Make sure that users can log in with their usernames and passwords. Removing the OpenID extension from a wiki where this was the only way to log in ( $wgOpenIDOnly=true; ) does not make sense.

  1. delete the table user_openid in your wiki database ( "DROP TABLE user_openid;" )
  2. remove the require_once( "$IP/extensions/OpenID/OpenID.php" ); from your $IP/LocalSettings.php
  3. delete $IP/extensions/OpenID subdirectory

[edit] References

  1. Relying party (RP) = consumer: The site that wants to verify the end-user's identifier; other terms include "service provider" or the now obsolete "consumer" - which is still used here (this will be changed soon)
  2. http://sites.google.com/site/openidreview/resources OpenID resource papers and discussion of security issues
  3. 3.0 3.1 3.2 How to compile PHP with all options needed for OpenID extension (directory names are shown for a standard OpenSUSE server configuration)
    1. get the latest PHP version 5.3.x from http://www.php.net
    2. make a backup copy of your working php binaries /usr/bin/php and apache module /usr/lib64/apache2-prefork/libphp5.so or /usr/lib64/apache2-worker/libphp5.so . Assign a meaningful name so that you can easily return to your previous version in case that something went wrong during compilation of the new PHP
    3. memorize the configure options with which your present PHP was built, type
    4. php -i
    5. ./configure --prefix=/usr --datadir=/usr/share/php --mandir=/usr/share/man --bindir=/usr/bin --libdir=/usr/share --includedir=/usr/include --sysconfdir=/etc --with-libdir=lib64 --with-config-file-path=/etc --with-exec-dir=/usr/lib64/php/bin --with-apxs2=/usr/sbin/apxs2-prefork --with-openssl --with-bz2 --with-zlib --with-curl --with-ldap --with-mysql --enable-soap --enable-mbstring --with-xsl --enable-calendar --with-gd --with-iconv --with-pspell --with-gmp --with-mcrypt --enable-zip
    6. if configure stops prematurely because of missing modules, you need to install missing developers' libraries with header files using YaST. This can be done, usually step-by-step, until configure finishes successfully without missing dependencies.
    7. make
    8. make install
  4. in the current version; this might become per-wiki configurable and change
  5. 5.0 5.1 5.2 https://bugzilla.wikimedia.org/show_bug.cgi?id=27581
  6. http://www.zenorsoft.com/community/viewtopic.php?f=30&t=944#wrap "No you are not compromising anything. As far as I can tell you are just defining where it gets the random number from. It may not be a best practice to use this but it is not a security risk. It just uses a random number generator that might be a bit more predictable, but it does not effect the users or security of your board."
  7. http://wordpress.org/support/topic/fatal-error-when-trying-to-authenticate
Personal tools
Namespaces

Variants
Actions
Site
Support
Download
Development
Communication
Print/export
Toolbox