|
Mark, If they have to VPN in to connect to it, why would you treat that any different from someone else physically connected to it? You can also set up host names for IP addresses that aren't Internet routable (we do it for all of our systems here) to make life easier on your people. I'd never recommend using just an IP address for a website. That being said, Apache can examine the headers and determine if the IP address of the request is internal or not (you'll have to determine what makes it internal) and rewrite the URL to something else that is password protected which would make the URL the same for both internal and external people. There may be some examples of doing this on the Apache website (http://httpd.apache.org -- make sure you look at the version 2 documentation) since the syntax is exactly the same. I know for a fact that the book "Professional Apache 2.0" has examples of doing this (and a ton more) in it. I would say that there's nothing in the book that couldn't be found elsewhere but it's very well organized and will save you a bunch of time. Also, the archives here and at http://www.ignite400.org have a lot of posts on configuration issues (including why I despise the Migration Wizard, let's just say I feel the same way about it that Wiley Coyote feels about Road Runner). It looks like your configuration was generated by the Migration Wizard (I'm basing this on the xxxMatch directives shown -- those directives have their place but given the context I have of your configuration, this isn't the place for them). This "wizard" produces some truly nasty and overly complicated configurations that will eventually cause you grief. I'd suggest starting over with a clean configuration and building it up from hand. The new server wizard produces a very nice bare bones configuration that's easy to build upon. Here's a simplified (and less resource intensive) version of the directives you posted below: Alias /myreports /intranet/reports <Directory /intranet/reports> order allow,deny Allow From all </Directory> <Location /myreports> PasswdFile %%SYSTEM%% AuthName "Enter AS/400 User Id and Password" AuthType Basic UserID %%SERVER%% Require valid-user </Location> The Alias maps the URI to the physical directory. The <Directory> controls HTTP server access to the directory. The <Location> protects the URI (I've found this much easier to follow and far more flexible than protecting the actual directory). You also want to make sure that you have this in your configuration (put it at the global level if you do virtual hosting): <Directory /> order deny, allow Deny From all </Directory> This prevents someone from being able to get access to your entire machine. Finally, if you're going to password protecting more than one directory, you can copy everything out of the middle of your Location container and put it in a separate file. Here's an example of that: Create a file called myprot.txt and put it in your /server root/conf directory. That file will contain: PasswdFile %%SYSTEM%% AuthName "Enter AS/400 User Id and Password" AuthType Basic UserID %%SERVER%% Require valid-user You'd then change you Location container to this: <Location /myreports> Include conf/myprot.txt </Location> When you're protecting more than a couple of URI's, this makes the configuration go quicker and you're less likely to make a typo that would cause someone to be prompted to log in multiple times. You can also do this with other parts of the configuration but so far, this is the only thing I've found repetitive enough to do this with. I may change my mind on that if the number of virtual hosts I have goes up much (I have one instance with 15 virtual hosts in it right now, will have another soon). Matt -----Original Message----- From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]On Behalf Of MWalter@xxxxxxxxxxxxxxx Sent: Thursday, April 07, 2005 2:32 PM To: Web Enabling the AS400 / iSeries Subject: RE: [WEB400] AliasMatch, and MapMatch Sorry, The problem is it doesn't redirect. I want to be able to require a password from someone connecting from the internet, but not from within my network. Maybe I'm a bit confused between <Location> and <Directory>. What we do is send email links do documents on the IFS. Most are sent within the network, but we do have a few remote folks. My boss thought you should need a password to be able to connect from the internet, and get the documents. Thanks, Mark Mark D. Walter Senior Programmer/Analyst CCX, Inc. mwalter@xxxxxxxxxx http://www.ccxinc.com R Bruce Hoffman <bruce.hoffman@is eries-admin.net> To Sent by: Web Enabling the AS400 / iSeries web400-bounces+mw <web400@xxxxxxxxxxxx> alter=hanoverwire cc .com@xxxxxxxxxxxx Subject RE: [WEB400] AliasMatch, and 04/07/2005 02:26 MapMatch PM Please respond to Web Enabling the AS400 / iSeries <web400@midrange. com> hmmm.. you didn't say what the problem was... but... I have never used the location and the aliasmatch in this way. For system passwords I have always secured the target directory with the Directory directive and not the Location directive. Don't know if that makes a difference, but probably worth the try. Also, you should only need the AliasMatch, not the MapMatch. The MapMatch is iSeries specific. Lastly, what about UserID %%SERVER%%? On Thu, 2005-04-07 at 13:15, MWalter@xxxxxxxxxxxxxxx wrote: > I'm having a problem matching a location to a directory on my IFS. > > Here is my Location directive > > > > > 21 <Location /myreports/> > > 22 Order Allow,Deny > > 23 Allow From All > > 24 Require valid-user > > 25 PasswdFile %%SYSTEM%% > > 26 AuthType Basic > > 27 AuthName "Enter AS/400 User Id and Password" > > 28 </Location> > > > > > > Here are the Alias and Map directives > > > > > > > 108 MapMatch ^/myreports/(.*) /intranet/reports/$1 > > 109 AliasMatch ^/myreports/(.*) /intranet/reports/$1 > > > > > What did I miss? > > > > Thanks, > > Mark > > Mark D. Walter > Senior Programmer/Analyst > CCX, Inc. > mwalter@xxxxxxxxxx > http://www.ccxinc.com -- "Bigamy is having one wife too many. Monogamy is the same." -- Oscar Wilde
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
