Extension talk:NetworkAuth

permission caching bug goes beyond just viewing browser cached pages

The logout page says, "some pages may continue to be displayed as if you were still logged in" -- OK, but not only that, you can actually edit and save changes even after logged out.

Scenario: I am logged in as a user with edit permissions and I was editing an article called "Sample_Article". Then I do a "log out" MediaWiki shows me this as expected:

You are now logged out.

You can continue to use My Wiki anonymously, or you can log in again as the same or as a different user. Note that some pages may continue to be displayed as if you were still logged in, until you clear your browser cache.

Return to Sample_Article.

I then click on "Return to Sample_Article" and I'm returned to the article. It shows me logged-in as my former user login. That's OK. The log out warns me of this, so I understand this is a limitation. But I can actually click on "edit"; make changes; and then click "Save Page" to save those changes. I think allowing edits after a Log Out goes beyond a browser cache quirk. Allowing edits after a Log Out is a bug. The edits are also actually saved under the former user_id.

I'm testing with MediaWiki version 1.12.0. I have the following lines in my LocalSettings.php file. The 'Staff' user has read permissions set true, but edit is false:

$wgUseFileCache = false;
$wgNetworkAuthUsers[] = array(
        'iprange'               => array('192.168.1.0/24'),
        'user'                  => 'Staff');

--Noahspurrier 21:29, 3 September 2008 (UTC)

If you're still around, you might want to try setting " $wgCookieExpiration = 0; " in LocalSettings.php. I imagine that the cookie must be remembering your login status even after you logout, so this could work. --朝彦 (Asahiko) 08:25, 9 October 2010 (UTC)

Undefined $u in efNetworkAuth_Authenticate()

First of all, thank you for this great extension. I run a wiki (PHP 5.1.6, MW 1.16.0) for in a university laboratory where all of the users access from a limited IP range (local area network), and this extension has been so useful.

One minor thing that bothered me was an error message I get on the top of the page when accessing from outside the specified range: "Notice: Undefined variable: u in (...)/extensions/NetworkAuth/NetworkAuth.php on line 123". I believe this is because when efNetworkAuth_checkForNetworkAuthUser() returns an empty string (''), the definition of $u at line 120 never happens, leaving $u undefined. To suppress the error, I changed a line in efNetworkAuth_Authenticate()

if( is_null( $u ) || !User::isUsableName( $u->getName() ) ) {

to

if( !isset( $u ) || !User::isUsableName( $u->getName() ) ) {

because applying is_null() on an undefined variable was the source of the error. See this post by dward.

Cheers --朝彦 (Asahiko) 12:05, 9 October 2010 (UTC)

I second! Please include this patch!

I've submitted a bug to bugzilla: https://bugzilla.wikimedia.org/show_bug.cgi?id=32808

--Olenz 15:49, 5 December 2011 (UTC)

That was quick: the bug is fixed. --Olenz 15:59, 5 December 2011 (UTC)

Security problem in extension

I have found a security problem in the extension where the extension does not correctly match an IP range and therefore may authenticate users even when they are not in the specified IP range. I have reported the bug here: https://bugzilla.wikimedia.org/show_bug.cgi?id=38117 --Olenz (talk) 13:32, 2 July 2012 (UTC)

Forced logout before page is displayed

In the code I found this: "Since we're not really logged in, just pretending - force a logout before the page gets displayed.". Why is this actually done? And why is it done before the page is displayed, and not after it is displayed (e.g. in the hook ArticleViewFooter)?

The problem with this is that it creates an undefined state: the user is neither really logged in, nor anonymous. I would prefer it, if the user would be cleanly logged in. Is there any danger in not forcing the logout at the end? --Olenz (talk) 15:31, 1 October 2012 (UTC)

version?

this uses RequestContext which is 1.18 onwards, so the earliest compatible version is wrong

Y Updated to minimum version 1.19 – I added some compatibility notes [1]. ~ Seb35 [^_^] 10:40, 2 April 2017 (UTC)

Bug - fatal error if gettitle fails to return an object

I've been getting these errors in my php log

[22-Oct-2014 09:07:13 UTC] PHP Fatal error:  Call to a member function isSpecial() on a non-object in C:\inetpub\wwwroot\mediawiki\extensions\NetworkAuth\NetworkAuth.class.php on line 46

I fixed them by changing that part of the code to this:

    	$title = $context->getTitle();
     	if ( !is_object($title) ) return true;
     	else if ( $title->isSpecial('Userlogin') ) 

There is almost certainly a cleaner way to do it.

— Preceding unsigned comment added by Hoggle42 (talk • contribs) 09:32, Oct 22, 2014 (UTC)

Y This was fixed in 396fb835 (9 April 2014). ~ Seb35 [^_^] 12:05, 2 April 2017 (UTC)

AccessDeniedError - Only first letter can be capital in user name "NetworkAuthUser"

When I have use NetworkAuth to log in a normal user account and this account to the variable $wgNetWorkAuthSpecialUsers, the problem "AccessDeniedError" was still occurred:

AccessDeniedError: Your wiki requires a logged-in account to access the API.

When I have change the name from "NetworkAuthUser" to "Networkauthuser" the problem was solved.

My exampel:

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

$wgNetworkAuthUsers[] = array(
        'iprange'               => array('xxx.xxx.xxx.xxx'),
        'user'                  => 'Networkauthuser'); // Only first letter can be capital

I just tested this with NetworkAuth 2.1.2 (4a39085) and MediaWiki 1.29-alpha (1d31b52) and it works with the normal username (e.g. NetworkAuthUser), I guess it was fixed at some point. ~ Seb35 [^_^] 10:34, 2 April 2017 (UTC)