On 7 September 2013 16:08, <vitalif(a)yourcmc.ru> wrote:
Oh, thanks for clarifying. Two things that come to my
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
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!