On Thu, 29 Nov 2012 15:36:51 -0800 Grant <emailgr...@gmail.com> wrote:
> > > I want users jack and jill to be able to access the web content > > > from any IP address, and I want users john and jacob to be able > > > to access the web content only if they are coming from a certain > > > IP address. I don't want anyone else to have access. > > > > > > - Grant > > > > Run two vhosts that deliver the same content from the same > > DocumentRoot > > > > One has jack and jill as users in htpasswd with no acls in place > > The other has john and jacob as users in a different htpasswd with > > IP acls in place > > > > Trying to specify access rules to a group of users and not to other > > users all in the same context is a problem that will drive you nuts > > in a day. Rather side-step it entirely by applying your rules > > globaly to two different things. > > So I'm sure I understand, if I want to keep the IP address which > accesses the web content the same, this means setting up a vhost for > a port other than 80 and 443 which the other vhosts are already set > up on? No need for that, use name-based vhosting: the same IP, port and Apache instance, with different names in DNS the return the same IP. Apache can tell them apart based on the site name in the HTTP request and keeps the config separate with the <NameVirtualHost> directive. I don't know what sort of scale you are working at, if it's two users or many more. I have to deal with the same sort of thing in a corporate setting (not necessarily web sites) often for 50 or more users and that's how I would do it. Just a tip though: many times when I ponder complex access control systems I find out at the end that I'm just being really silly and don't actually need it. If I can't trust a user to behave outside of office hours that often means I can't trust them at all and they get no access :-) By all means continue with your original post if that's what you need but in your shoes I'd first be proving to myself it really is what I need (rather than what I think I want) -- Alan McKinnon alan.mckin...@gmail.com
