× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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 thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.