Hi David! What do you exactly mean by "local" and "remote" users? Where do either of them really have accounts?

david mason vid_wikimedia_enterprise@zooid.org пишет:

Hi all,

I've been hacking at this for a while and hoping someone has solved it.

I am trying to set up MediaWiki with LDAP so users from a remote network must log in, but it's optional on the local network. I don't want users to have to log in twice, so I set up Extension:AutomaticREMOTE_USER (htauth) which works well for remote users, but I can't determine a good way to permit login for local users in the same instance.

I've tried a variety of hacks, including setting a directory where the local user must log in then directing them back, but Apache won't pass REMOTE_USER in the MW directory for a local user, and other hacks are all ugly in one way or another. Does anyone have any ideas?

Thanks!

David

"Local" users are on an identified network address range (via .htaccess) and "remote" users are anyone who's not "local." In both cases they have accounts.  The problem is Apache won't pass REMOTE_USER if the directory is considered to not require auth, which I need to have the site read-only for logged in local users. The only thing I've been able to come up with is to duplicate the MW instance using the same database at a different locations, but that means people will be using different URLs. I also set up a scheme where a directory requiring htauth login stores REMOTE_USER in a session variable then bounces them back, but it required further hacks and I'd prefer something cleaner.

I don't understand why do you want REMOTE_USER at all? Is it because you use Apache authentication modules - some kind of domain autologin? (and what kind?) And if it isn't automatic, if it's just HTTP LDAP authentication using login and password - why you don't use http://www.mediawiki.org/wiki/Extension:LDAP_Authentication?

Oh, thanks for clarifying. Two things that come to my mind are:

1) Try to do it on the application level. For example, try a following hack - check $_SERVER['REMOTE_ADDR'] in LocalSettings.php and conditionally set $wgGroupPermissions['*']['read'] to false (also 'edit', 'createaccount', 'createpage', 'createtalk', 'writeapi') => the wiki will become read-only for non-local addresses... Or another kind of hack - maybe it's even better because of missing userCanRead() calls in different parts of MW: redirect all anonymous external users to Special:Userlogin (again with PHP, using IP check in LocalSettings.php), so the only page they will have access to will be the login page.

2) Try "Satisfy any" in Apache and still use REMOTE_USER, i.e.:

Allow from 192.168.0.0/24 Require valid-user Satisfy any

This will probably lead to external users having to log in using HTTP authentication and internal users having to use normal application-level authentication. But I think this is uglier, at least because of HTTP auth.

hi again,

On 7 September 2013 16:08, vitalif@yourcmc.ru wrote:

Oh, thanks for clarifying. Two things that come to my mind are:

1. Try to do it on the application level. For example, try a following

hack - check $_SERVER['REMOTE_ADDR'] in LocalSettings.php and conditionally set $wgGroupPermissions['*']['**read'] to false (also 'edit', 'createaccount', 'createpage', 'createtalk', 'writeapi') => the wiki will become [unreadable] for non-local addresses... Or another kind of hack - maybe it's even better because of missing userCanRead() calls in different parts of MW: redirect all anonymous external users to Special:Userlogin (again with PHP, using IP check in LocalSettings.php), so the only page they will have access to will be the login page.

This might be the simplest, though I was hoping to avoid any code-level hack since it may be more difficult to keep up to date with MW releases. Though MW auth would be better than the htauth popup that no one likes. I didn't realize this could be done in LocalSettings, I thought it was cached, I will experiment with this Wednesday.

2. Try "Satisfy any" in Apache and still use REMOTE_USER, i.e.:

Allow from 192.168.0.0/24 Require valid-user Satisfy any

This will probably lead to external users having to log in using HTTP authentication and internal users having to use normal application-level authentication. But I think this is uglier, at least because of HTTP auth.

It appears that if Satisfy any is present, REMOTE_USER isn't passed on.

Thanks for your help so far!

David

hi again,

Just wanted to say thanks. Although through all my testing REMOTE_USER did not show up in "local" networks, I was able to use the LocalSettings approach as you suggested to achieve the configuration I was looking for.

David

On 10 September 2013 07:34, vitalif@yourcmc.ru wrote:

This might be the simplest, though I was hoping to avoid any

...

code-level hack since it may be more difficult to keep up to date with MW releases. Though MW auth would be better than the htauth popup that no one likes. I didn't realize this could be done in LocalSettings, I thought it was cached, I will experiment with this Wednesday.

No, it isn't, and even if it was - you could create some small extension doing the same check during initialisation :)

It appears that if Satisfy any is present, REMOTE_USER isn't passed on.

...

...

I've just tested such setup, and REMOTE_USER is passed in my case... (of course, only if access isn't allowed by host-based auth)

______________________________**_________________ Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.**wikimedia.orgMediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/mediawiki-**enterprisehttps://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise