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
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
Hi,
"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.
David
On 7 September 2013 06:07, Виталий Филиппов vitalif@yourcmc.ru wrote:
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
Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
"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?
I want REMOTE_USER since I am using Apache to require login if the user is not coming from the local network. But I don't want to have them log in twice. Essentially in psuedocode;
if user is on a remote network: deny access without login (through htauth) prompt for login on success, pass login to MW else provide read only access make login for read-write possible
I don't think I can use both the remote auth module and ldap auth on the same MW instance without hacks.
David
On 7 September 2013 13:59, vitalif@yourcmc.ru wrote:
"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_Authenticationhttp://www.mediawiki.org/wiki/Extension:LDAP_Authentication ?
______________________________**_________________ 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
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:
- 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.
- 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
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)
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
mediawiki-enterprise@lists.wikimedia.org