hi again,

On 7 September 2013 16:08, <[email protected]> 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
_______________________________________________
Mediawiki-enterprise mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise

Reply via email to