[colug-432] virtual hosts based on ip

[Angelo McComis]

Honestly, I think you have set yourself down a path where this will be difficult to support and maintain. 
Give each client a unique sub-url and still authenticate them by IP if you want. But don't make it complicated by trying to auto route them. 



    _____________________________
From: Keith Larson <klarson at k12group.net>
Sent: Wednesday, October 14, 2015 12:56 PM
Subject: Re: [colug-432] virtual hosts based on ip
To:  <colug-432 at colug.net>


                      The reason for the different "sites" is so that I can authenticate back to their local ldaps and verify that it is a user within their system and authorized to use the site.  This actually underscores the need for me to validate that the request is actually coming from within their network and not somewhere else.                     I understand your concerns about them making changes without me knowing about it, but that will break other services anyway that are related to this process, so I'm actually ok with that part.              >>> Rick Hornsby <richardjhornsby at gmail.com> 10/14/2015 10:12 AM >>>
         
                          On Oct 14, 2015, at 08:11, Keith Larson <        klarson at k12group.net> wrote:              
                                                                is it possible to present a different instance of a page based on the source ip address?  ie.  two customers A and B.  i want customer A to see a different version of a webpage than customer B.  they have different ip ranges that they would be coming from based on their external nat.  i would think that this can be done, but i'm not exactly sure how.  i've done named virtual hosts with no problems.                                                               i also don't want customer A to be able to see customer B's version or even know that it exists.                                                     
                   This is going to seem harsh, but my suggestion comes from experience.  I've begged clients not to go down this road because it inevitably comes back to bite them, and usually me as well.                                                         is it possible to present a different instance of a page based on the source ip address?                                                     
                   "Can it be done" is a different question than "should it be done".                   
           The answers are yes and no, respectively.  An IP address, or even a range of addresses, is not a great way to handle authorization.  IP addresses - especially source addresses - are subject to change without warning.  Chances are the customer that's using your site won't even know about the change.  The site will just break for them.  Unless you're acting as the customer's ISP, you don't know or control the source address range.  In a very simple example along the same lines, what happens when the customer is on the road, and wants to pull up your site from his phone?  What will he see?           
                There are a couple of alternative approaches, one you've already hit on - named virtual hosts.  Give each customer a different site name.  It adds administrative overhead (you have to keep a list, and customers have to remember a unique site name), but it's something in your control and does not depend on external information (source address) you don't control.                
                Another alternative is authentication.  If the content of the site is really proprietary to a customer (or might be in the future), you probably want to protect it.  You could use the same login page for everyone, and then present them with distinct content after they have been identified/authenticated based on who they are.  In the edu space, the site content may now or in the future (depending on what customers put on their site) be subject to FERPA, so setting up authentication now might be a good long-term investment.                
                
                
                -rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.colug.net/pipermail/colug-432/attachments/20151014/e18ccebb/attachment.html