User talk:Otheus/Auto Login via REMOTE USER
Is there an easier way to autologin/autocreate an user account without using a seperate HTTP Request and this PEAR module? I want to use this autologin for an intranet where $SERVER["AUTH_USER"] is set to DOMAIN/firstname.lastname. Now I would like to autologin this user, and if there's not a user with this name, I want mediawiki to autocreate this User with firstname, lastname and email (firstname.lastname@domain.com) set. Has somebody tried this before?
Modifying the Userlogin Page[edit]
We run MFI-Wiki and would like our members to standardize their User Names when they create a new User Account.
Where do we edit the Userlogin page, to include the User Name standardization methodology we'd like them to use?
Rob Johnson, MFI-Wiki
maquis.com
First-Save Bug[edit]
When using this extension I'm noticing that the first time I save an edit it shows me the preview screen instead of saving. I can then save the page and from then on it works fine. However, several of my users have not noticed this preview and lost their edits.
Any idea how I can fix this? I'm using MediaWiki 1.4.2. Please reply here. -Mcrawfor
We are also experiencing first-save problem. We are recieving "Fatal error: Call to undefined function: memsess_key() in <path>\includes\User.php on line 1695". Using MediaWiki 1.6.3 /on IIS-Brian C
- I see the same "memsess_key()" error (v1.6.3). I think it's related to a combination of this auto-login extension and the access restriction patch that I have installed. Something to do with a token mismatch, but I haven't figured it out yet.
These all seem related, I fixed the latter error (the memsess_key()) by including MemcachedSession.php in User.php. This seems to work, but it produces the former "bug". It seems that the Auto Login module doesn't create a proper usersession. However I don't know how applicable this is for everybodyelse, because my mw-1.6.4 is also encumbered by a hacked LDAP Auth module... (not signing as I don't have a wm-user) -andreala
Could this 'first save bug' be unrelated to all logins. see http://www.mwusers.com/forums/showthread.php?t=1528Hopespoppa
I only ran into this problem after upgrading from 1.5.5 to 1.6.3. I am hosting my wiki on a single internal server, so I can't think that it is the same problem as those hosting on Sourceforge, but I did try moving my sessions storage somewhere other than /tmp, to no avail. I fixed, by hand, the other save problem found in 1.6.3 (bug 5576), but that didn't fix the need to save twice. The message I get after the first initial click on the "save button" is:
Sorry! We could not process your edit due to a loss of session data. Please try again. If it still doesn't work, try logging out and logging back in.
Is there any news about an update to this extension to make this problem go away? (That is, assuming that changes to the authentication process in 1.6.* have caused the wiki and this extension to not play well together...)
Justkristin 22:31, 2 May 2006 (UTC)
Hey I am getting the "We could not process your edit due to a loss of session data" problem too. What is the solution to fix this? - Justine
Another case of "We could not process your edit due to a loss of session data" on v1.8.2 any solutions? - Ulf(dot)Licht(at)esprit(dot)com 13:45, 30 January 2007 (UTC)
I'm having this "loss of session data" bug too. It looks like it's related to a session cookie that doesn't exist on the first edit. Try adding a
if( !isset( $_COOKIE[session_name()] ) ) {
User::SetupSession();
}
in front of the $wg->isLoggedIn() and see if that helps. It looks ok in my testing, but I've only tested a short time, any news from others would be helpful. --Rtdog 03:08, 5 February 2007 (UTC)
I've just implemented the above code and it appears to be working fine. Adn the problem was exactly as stated by Rtdog. There was no session cookie saved until after the first attempt at saving a persons first edit. Thank you very much for the help Rtdog. Just a FYI I'm using OpenBSD 4.0, mediawiki-1.9.0rc2, and SecurID RSA tokens. pmarcus 03/20/07 0649
My user.php doesn't have that line. If you're out of context please enlighten us about which files you're talking. - (no wm accnt) Frank
First Save bug w/ MW 1.30, AuthRU 2.0.2 and "CA Policy Agent"[edit]
- 2018-06-04-User:revansx -- I'm having this same issue too on my 1.30 wiki running AuthRU v2.0.2 and CA Policy Agent.
- I agree that the issue seems to be related to when the session cookie is created.
- Please see the following screenshot for details:
- I would really appreciate some help in implementing the hack that adds:
if( !isset( $_COOKIE[session_name()] ) ) { User::SetupSession(); }to/includes/user/user.php
$_SERVER['HTTPS'][edit]
We don't seem to have HTTPS_KEYSIZE set, but (looking at phpinfo) HTTPS seems to be set to "on" when using SSL. Your hack was throwing up a 400 error by doing http://server:443 (ie talking non-ssl on an ssl port)
I tried a quick hack, but it seemed to constantly redirect me out of the mediawiki tree :-( Elwell 16:29, 13 March 2006 (UTC)
HTTPS Quick Solution[edit]
To prevent this 400 Error with HTTPS i just removed the following block:
// if it worked: refer to login page, otherwise, exit
header( "Location: http" .
(isset($_SERVER['HTTPS_KEYSIZE'])
&& $_SERVER['HTTPS_KEYSIZE'] > 0 ? "s" : "") .
"://" . $_SERVER['SERVER_NAME'] . ":" . $_SERVER['SERVER_PORT'] .
"/" .
( isset($_SERVER['URL']) ? $_SERVER['PATH_INFO'] .
( $_SERVER['QUERY_STRING'] ? "?" . $_SERVER['QUERY_STRING'] : "" )
: "" )
);
// Now redirect to referred page
// print("Done");
exit();
and it worked fine.
Using header data with remote External Authentication[edit]
I really appreciate this improvement of the origial Auto_Login_via_REMOTE_USER. I attempted the original and found the HTTP_Request w/ POST was causing problems as well as the Pear and multiple includes.
If I understand correctly, this solution assumes the user has already externally authenticated (as in the situation where the entire wiki resides in an SSO-protected folder/site). In our situation, an unauthenticated user must be sent to some page(or script) located on a separate SSO-protected website of the same server. The wiki url is ourintranet.com/mywiki/Main_page and the SSO protected script would be at ourintranet.com:6959/SSOdetour.php.
After a successful SSO login, the SSOdetour.php currently redirects to a test.php script, which obtains LDAP info (employeeID,Name,email) from the header variables as $_SERVER['HTTP_USER_MAIL']. $_SERVER['REMOTE_USER']; returns null (running IIS).
How can we use this solution? Any help would be greatly appreciated. Anonymous wiki viewing with auto login for any 'action=' page is preferred, but auto login prior to any wiki viewing is acceptable to us.
--- Update to 'header data above'. We implemented this Auto Login via REMOTE USER solution with most of the code improvements listed with the code article. We use Oracle CoreID (Netpoint Oblix) with the Webgate filter for SSO. Our Platform is Windows 2003 IIS. Thanks to all who have contributed - Hopespoppa 20:35, 2 May 2006 (UTC)
infinite recursion[edit]
Using mediawiki 1.6.5 and following the install instructions (as far as I can tell), it appears to be busted. After putting in a bunch of wfDebug output, it appears to always attempt to create a new user account for the user I'm testing with (username 'guest' in this case). The 'isLoggedIn' test never detects that I'm logged in, the 'newFromName' always returns a non-null value, but the user id is always 0. I think that's where the infinite loop comes in. As best I can tell, the subsequent creation of the user is working (but not sure how to tell if it makes it into the persistant data store).
Also, I had to update the code that builds the redirect, as the server environment variables that were being used weren't present on my system. Instead, I replaced everything after the server/port portion with 'REQUEST_URI', which apparently contains the QUERY, as well. Not sure what's going on exactly, but hopefully this will help someone else out.
Work with 1.8.2?[edit]
I just upgraded my wiki from 1.6.x to 1.8.2 and it appears that this extension does not work with this version. Does anyone know how to modify it so that it does? If so please feel free to email me! Thanks --Sean 16:31, 27 October 2006 (UTC)
UPDATE: I found the comment on the bottom of the page here: [[1]] that told me what I needed to do. I change
$wgGroupPermissions['*' ]['read'] = false;
to
$wgGroupPermissions['*' ]['read'] = true;
and it works great!
autocreation of users on MediaWiki 1.8.2[edit]
I upgraded my Wiki from 1.7.1 to 1.8.2. Everything worked fine except autocreation of new users. After a long research I found out that records for new users are inserted into the database within a transaction, but no COMMIT takes place. I solved this in a quite rude manner by adding two lines as follows:
*** Auth_remoteuser.php~ Mon Nov 20 20:18:02 2006
--- Auth_remoteuser.php Wed Nov 22 19:41:37 2006
***************
*** 74,79 ****
--- 74,84 ----
include 'includes/SpecialUserlogin.php';
$form = new LoginForm( $wgRequest );
$form->initUser( $wgUser );
+
+ // commit user insertion - necessary since 1.8, probably there would be a more elegant way...
+ $dbw =& wfGetDB( DB_MASTER );
+ $dbw->query('COMMIT');
+
$wgUser->saveSettings();
// if it worked: refer to login page, otherwise, exit
If someone finds a slightly more elegant solution, I'd be happy to know about it.
Richard Verhoeven 14:09, 27 November 2006 (UTC)
Possible Solution[edit]
I think the user table switched from myisam to innodb at some point in the 1.5 versions. This module didn't work for me until I converted the table back to myisam.
Savings/Setting on 1.8.3[edit]
I am running the 1.8.3 release of media wiki, on WAMP5 1.6.6, after going through and reading all of the various discussions about this extension and implementing the recommended fixes I am still unable to get complete functionality. Whenever i try to edit/create a page or change preferences I get the preview window with a blank input box (even if the page already had data) or in the case of preferences it just submits but the resultant page doesn't show the new value for the respective setting. Can anyone help with this?? you can reply here of email me mlorad1 AT towson DOT edu.
blank page in 1.9.2[edit]
following these instructions you only get a blank page on mediawiki 1.9.2. the php error is:
PHP Fatal error: Using $this when not in object context in /opt/app/mediawiki-1.9.2/includes/User.php on line 642
Jay Scott sez: I changed
$wgUser = User::loadFromSession();
to
$wgUser = new User; $wgUser->loadFromSession();
I DO NOT KNOW WHETHER THIS IS CORRECT, but it allowed me to get past this error and on to the next one. The next one is "password change forbidden" at
/var/www/html/vmttestwiki/includes/SpecialUserlogin.php(311): User->setPassword()
For that, I pulled out the code of
$form->initUser( $wgUser );
into the body of the hook function, leaving out the password setting and filling in the real name and e-mail from our custom source. This now works correctly, as far as I can see, for viewing pages, but if I try editing it complains of lost session data and fails.
The switch of
$wgUser = User::loadFromSession();
to
$wgUser = new User; $wgUser->loadFromSession();
is certainly correct. Looking at MediaWiki 1.5 code (which is the version this extension was originally created for), the loadFromSession method was commented as being static, meaning that it was intended to be a class method; moreover, it returned a User instance. However, in the MediaWiki 1.9 code, the loadFromSession method is an instance method, which returns a boolean that indicates whether the action was successful.
I am still working on Jay Scott's second error.
— DLJessup 22:39, 29 March 2007 (UTC)
see http://www.mediawiki.org/wiki/Extension_talk:AutomaticREMOTE_USER "Sciurus" sets setPassword() and allowPasswordChange() to return true.
tim, 12 May 2007
Error in 1.10.0[edit]
Fatal error: Call to private method User::loadfromsession() from context in /var/www/wiki/extensions/Auth_remoteuser.php on line 49
Changed $wgUser = User::loadFromSession(); to $wgUser = new User; $wgUser->loadFromSession(); doesn't work.
EDIT: my fault :( i thing, i didn't use the newst version from http://www.mediawiki.org/wiki/Extension:AutomaticREMOTE_USER
Problem with domain\userid format[edit]
(Version 1.10.1) Our usernames are in the format domain/userid (ie. DOM\d44598). However, the username at the top of the page ends up showing Domd44598. Can anyone see why this might be happening?
Fix[edit]
I think you need to look at this bit
// Using your own methods put the users real name here.
$user->setRealName($username);
This might work?
// Using your own methods put the users real name here.
$user->setRealName(addslashes($username));
Alternatively, if you can ignore the domain completely, you can change the $_SERVER['REMOTE_USER' ] entries on lines 92, 188 and 251 to get_username() and put the function below in the file:
function get_username() {
global $_SERVER;
$domainuser = preg_split("/[\\\\\/]/", $_SERVER['REMOTE_USER']);
return end($domainuser);
}
This obviously won't be secure if you have multiple domains though.
Perhaps someone can comment if this is OK because I'm not a PHP programmer. 193.36.230.96 19:25, 29 October 2007 (UTC)
Errors in 1.11.0[edit]
Several of these errors appear at top and bottom of page:
Warning: Cannot modify header information - headers already sent by (output started at /webdocs/mediawiki-1.11.0/extensions/Auth_remoteuser.php:306) in /webdocs/mediawiki-1.11.0/includes/WebResponse.php on line 11
FIX:
I found the cause of the problem in http://www.mediawiki.org/wiki/Extension_talk:MediaWiki_Bulletin_Board
The extra line after close tag (?>) in this extension is the culprit, just delete it and everything works fine.
Problem with name normalization[edit]
Reposted here, so it can hopefully be worked into the current revision. I found a problem where usernames with underscores in them would fail to work. I've posted a patch here: http://www.mediawiki.org/wiki/Extension_talk:AutomaticREMOTE_USER#Problems_with_name_normalization_and_patch
--XXV 15:55, 14 September 2009 (UTC)
mediaiwiki-1.16 generates fatal error on getName()[edit]
I'm trying to migrate from mw-1.15 to 1.16beta2 and this newer version of Auth_remoteuser isn't working for me.
I've brought up a fresh instance (to remove other variables) behind a HTTP authenticated directory, on a CentOS4 system with PHP-5.1.6-3.5
When I load this extension, it crashes mw with the following error
PHP Fatal error: Call to a member function getName() on a non-object in /var/www/html/secure/mediawiki-1.16.0beta2/includes/specials/SpecialUserlogin.php on line 456
mw-1.16 doesn't seem to have any issues with this older version of PHP - but I'm suspecting that is the cause of the problem within Remote_authuser?
Is this a fault, or do I have to run a newer PHP version to get this to work? Thanks!
1.19.0 email not being created.[edit]
i'm trying out this extension on 1.19.0. i enabled the extension, and it logs me in successfully, but the real name and email address is not being set.
i've set
$wgAuthRemoteuserDomain = "MYDOMAIN.COM"; $wgAuthRemoteuserMailDomain = "mydomain.com";
is there something i'm missing?
i do see in the code the following:
// You probably want to edit the initUser function to set the users real name // and email address properly for your configuration.
which is amusing in that, yes i do want to do that, but without a background in php, i don't know what to change in initUser to achieve this, especially as there are no inline comments at that point. looking at the code further, i get the feeling that initUser should be setting real name and email but it isn't because of the section above:
/* User's name */
$wgAuthRemoteuserName = isset( $_SERVER["AUTHENTICATE_CN"] )
? $_SERVER["AUTHENTICATE_CN"]
: ;
/* User's Mail */
$wgAuthRemoteuserMail = isset( $_SERVER["AUTHENTICATE_MAIL"] )
? $_SERVER["AUTHENTICATE_MAIL"]
: ;
this part of the code however i'm not understanding at all.
Zee (talk) 19:10, 14 June 2012 (UTC)
Unable to login. Please help![edit]
Hello,
I have implemented this extension and has configured to the IIS settings as mentioned in the page.
When I enabled windows authetication in IIS, it shows me the prompt on IE/Chrome/Firefox and when I entered DOMAINNAME\USERNAME and password, it denies my entry. It keeps looping.
However, when I enabled basic auth instead of windows auth, it prompts me again but when I entered DOMAINNAME\Username and password, I am able to login.
Why is that so?
Please help.
Thanks so much for all the assistance!
Mediawiki 1.27.0[edit]
Fatal error: Call to undefined method LoginForm::authenticateUserData() in /srv/www/mediawiki-1.27.0/extensions/Auth_remoteuser/Auth_remoteuser.body.php on line 335
There is a rewrite available for MW1.27 here: AuthRemoteuser from noris-network
visual editor is broken[edit]
Version 1.30.0 of mediawiki and version 2.0.0 of Auth_Remoteuser, actually using 2.0.1 with the userloggedin hooks in place.
Visual editor version 0.1.0 says my user isn't logged in. I first tried the stable version of auth from the download page of the extension on the
mediawiki site and it totally broke visual editor, so I downloaded the latest developer edition and I find that it's way different
but at least its half right. So it thinks I'm not logged in and then it gives an error message when I try to save anon-ly.
Something went wrong
We could not save your edit because the session was no longer valid. Do you want to save this page as an anonymous user instead? Your IP address will be recorded in this page's edit history.TespSam (talk) 21:41, 8 March 2018 (UTC)
- Found your report here now. This talk page is for the legacy version which isn't supported anymore. Regarding your question about the current version it's better to use the current talk page mw:Extension_talk:Auth_remoteuser. But to your problem. Can you try it again, when this task (T171190) gets resolved. This patch will rule out current same-domain-problems with the auth cookie and maybe it relates to your problem too. -- Enst80 (talk) 12:37, 17 March 2018 (UTC)
- dunno if you saw it yet, but i poked a new topic on the suggested page.--TespSam (talk) 22:09, 21 March 2018 (UTC)