Aaron Trevena wrote:
[...]
http://www.bytemark-hosting.co.uk do some good deals and discounts for
free software author and seem nice people.
Please submit ISPs that support mod_perl and/or virtual servers. so we can add
them to:
http://perl.apache.org/help/isps.html
I've added the one mentioned
Perrin Harkins wrote:
On Wed, 2003-06-11 at 12:58, Mike Zelina wrote:
I couldn't find any documentation on how a host *could* provide mod_perl
and do it in a way that would be safe for his server and usable for a
client.
I was just talking about this with my co-workers. Here's one way:
Set up
On Wed, 2003-06-11 at 12:58, Mike Zelina wrote:
> I couldn't find any documentation on how a host *could* provide mod_perl
> and do it in a way that would be safe for his server and usable for a
> client.
I was just talking about this with my co-workers. Here's one way:
Set up a front-end apache
On Wed, 2003-06-11 at 18:09, Sidharth Malhotra wrote:
> Not quite a manual, but read some of these discussions on PerlMonks:
>
> http://www.perlmonks.org/index.pl?node=mod+perl+isp+host&go_button=Search
> "mod_perl shared hosting"
> "ISPs supporting mod_perl"
> "mod_perl: the bane of share webhost
answers (not a lot of hope, though)
-Sidharth.
-Original Message-
From: Mike Zelina [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2003 12:59 PM
To: [EMAIL PROTECTED]
Subject: security with mod_perl
I have a local hosting provider who has mod_perl installed
on the server, but will
ve a local hosting provider who has mod_perl
installed
on the server, but will not enable it for security
reasons. After doing
some digging on the mod_perl site and thinking about how
many ways a
renegade mod_perl program could bring down a site (large
modules using
a lot of memory means larger
I have a local hosting provider who has mod_perl installed
on the server, but will not enable it for security reasons. After doing
some digging on the mod_perl site and thinking about how many ways a
renegade mod_perl program could bring down a site (large modules using
a lot of memory means
I, rather blindly, put a reference to a hash of the HTTP headers and hash of
the CGI params in pnotes for most requests.
Technically, a poorly formed loop might DOS a child if the number of params
or headers is evilly large.
For instance, someone silly could write
my $params = $r->pnotes('param
=?iso-8859-1?Q?=22Fa=DFhauer=2C_Wolfgang=2C_FCI3=22?= <[EMAIL PROTECTED]
ads.net> wrote:
>>>Hi,
>>>
>>>I want to build a database application based on mod_perl and Apache::DBI.
>>>The goal of Apache::DBI is to get persistent database connections using
>only
>>>one database user because of resource
Blowfish_PP would cut my danglies off
> for that one.
Which is why you copied him in the first place? :-) In general, though, there
isn't a good way to get any security from any system that has to be able to
access sensitive data in an automatic way.
MBM
--
Matthew Byng-Maddick
On Fri, 15 Nov 2002, [iso-8859-1] "Faßhauer, Wolfgang, FCI3" wrote:
>>Hmm. I think that the guy who wrote Blowfish_PP would cut my
> danglies off
>>for that one.
>
>This is an interesting idea.
Cutting my danglies off? hmm. Sounds painful.
>Many thanks to you, Rafiq!
s'ok, although I wouldn't
>>Yes, that's our plan, too. But the risk still remains that someone
will get a look to the script. I think, there is a golden rule: Never put
clear text passwords in files. Those files are stored in archives by backup
for example. There maybe a lot >>of people (sysadmin, developer, ...)
c
On Fri, 15 Nov 2002, [iso-8859-1] "Faßhauer, Wolfgang, FCI3" wrote:
> > Have you thought of running your webserver as some 'www' user? You can
> > then make your scripts readonly by a 'dev' group which the www user and
> > the developes are members of.
> >CORRECT:
> >'readonly' should be 'only rea
>>Hi,
>>
>>I want to build a database application based on mod_perl and Apache::DBI.
>>The goal of Apache::DBI is to get persistent database connections using
only
>>one database user because of resource limits. The problem I see is that
the
>>password for connecting to the database is clear readab
On Fri, 15 Nov 2002, Rafiq Ismail (ADMIN) wrote:
> On Fri, 15 Nov 2002, [iso-8859-1] "Faßhauer, Wolfgang, FCI3" wrote:
> > one database user because of resource limits. The problem I see is that the
> > password for connecting to the database is clear readable in the perl
> > script.
> > Does anyb
On Fri, 15 Nov 2002, [iso-8859-1] "Faßhauer, Wolfgang, FCI3" wrote:
> one database user because of resource limits. The problem I see is that the
> password for connecting to the database is clear readable in the perl
> script.
> Does anybody know how to hide that password?
Have you thought of run
Hi,
I want to build a database application based on mod_perl and Apache::DBI.
The goal of Apache::DBI is to get persistent database connections using only
one database user because of resource limits. The problem I see is that the
password for connecting to the database is clear readable in the pe
>
>
>So, question is: How do I protect my data files from being accessed by
>anything else than my own perlhandler? Can I set another uid for all that
>has to do with my specific perlhandler? Hints are most welcome.
>
> // Joel
>
>
Maybe you are facing the same problem, that I asked earlier
[...]
> So, question is: How do I protect my data files from being accessed by
> anything else than my own perlhandler? Can I set another uid for all that
> has to do with my specific perlhandler? Hints are most welcome.
You can't. The only solution is run a dedicated server for each user.
Cur
I'm developing an online survey system under mod_perl (with a homemade
perlhandler, not under Apache::Registry). Since I've had as a goal to
avoid as many dependencies as possible, I store results in local plaintext
files. By nature, these files has (?) to be writable by the uid apache
runs as.
heers!
-klm.
-Original Message-
From: Ask Bjoern Hansen [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 05, 2002 4:18 PM
To: Ken Miller
Cc: Modperl
Subject: Re: Doing security for backend applications
On Tue, 4 Jun 2002, Ken Miller wrote:
[...]
> So, php application reques
ing the php server forward authentication requests
to the mod_perl server; but support the same cookie format would be
relatively simple.
> This is all related to a single sign-on environment - once the user has
> signed on an encrypted cookie will contain the application security
> informati
t;Ken Miller" <[EMAIL PROTECTED]>
To: "Modperl" <[EMAIL PROTECTED]>
Sent: Tuesday, June 04, 2002 3:56 PM
Subject: Doing security for backend applications
> Let's say I have the following configuration:
>
> 1. Front end proxy server (no mod_perl)
> 2. Bac
Let's say I have the following configuration:
1. Front end proxy server (no mod_perl)
2. Back end application server (mod_perl)
3. Back end application server (php)
Now, *all* application requests are passed to the mod_perl server (yes,
including the php requests). Performing security c
> I am in front of a security issue. We are running several site using
> modperl. Last days, a hacker used a script to call some script of our
sites
> for bad purpose. He needed to be authenticated, but we are only using
> session cookies. Then, once he was loged in, he could retrieve
Try this.
http://www.snert.com/Software/mod_throttle/
Tor.
fred wrote:
> Hi,
>
> I am in front of a security issue. We are running several site using
> modperl. Last days, a hacker used a script to call some script of our sites
> for bad purpose. He needed to be authenticated,
I've had people run password guessing scripts and stuff.
I've handled it on a case by case basis, ie, limit the number
of wrong guesses.
There are a bunch of modules that can set limits as well which
can come in handy against very brutish sorts of misuses of your site,.
I used mod_throttle.c, t
Hi,
I am in front of a security issue. We are running several site using
modperl. Last days, a hacker used a script to call some script of our sites
for bad purpose. He needed to be authenticated, but we are only using
session cookies. Then, once he was loged in, he could retrieve this id and
Philip Mak wrote:
> Recently, I've been using Apache::ASP to program a new version of an
> existing website that gets over 5 million page views per month. This
> website will have to fit on a RaQ4i (450MHz) server, so I'm pretty
> conscious about performance. Security is
Philip Mak:
> This website runs off a MySQL database. Although all the webpages
> are generated dynamically, they don't change often (unless the
> webmaster explicitly updates them).
Do you generate reliable Last-Modified and Expires headers? This could
help bandwidth usage for you and your user
Recently, I've been using Apache::ASP to program a new version of an
existing website that gets over 5 million page views per month. This
website will have to fit on a RaQ4i (450MHz) server, so I'm pretty
conscious about performance. Security is also important due to the
popularity o
Hi all,
On Mon, 16 Apr 2001, darren chamberlain wrote:
> Thomas K. Burkholder ([EMAIL PROTECTED]) said
[snip]
> > my $input = IO::File->new("http://perl.apache.org/guide). It can help to
include the system error string (from the Perl special variable $!) in
the error message which you print
darren chamberlain wrote:
>
> Be sure to check that $line is defined:
>
Even better:
> >
> > use IO::File;
> > my $input = IO::File->new("getline() || 'some safe default value, like
""';
> die "\$line is not defined" unless (defined $line); # <-- Now not really needed
> >
It's defined all right, it gets printed to STDERR.
The problem was that the file I was actually using was a perl file '/tmp/foo.pl', just
because it didn't matter what was in the file while I tried to make it work. But,
wait, it
does matter, because the first thing in the file was "use Data::Du
Be sure to check that $line is defined:
Thomas K. Burkholder ([EMAIL PROTECTED]) said something to this effect on
04/16/2001:
> Note, /tmp/tmppswd is read-only by the installer of the product, but I should
> be root in access.conf (right?) so I should be able to read it anyway.
>
>
> use
t; uid & gid of the entire process. This would seem slightly better then the
> below alternative as you can set MaxRequestsPerChild to 1 and just have one
> parent process spawning children with different uid/gids, instead of having
> to start up an entire server for each uid/gid pair...
ve as you can set MaxRequestsPerChild to 1 and just have one
parent process spawning children with different uid/gids, instead of having
to start up an entire server for each uid/gid pair... Of course, there's
the security problem of everything that happens in the child until it gets
to the s
On Sun, 15 Apr 2001, Thomas K. Burkholder wrote:
> Thanks again for the help - I have another one-
>
> My application consists of perl modules with file permissions set only
> to a particular user 'burkhold'. The database password is kept in
> plaintext in one of those modules. I use the User:
Thanks again for the help - I have another one-
My application consists of perl modules with file permissions set only
to a particular user 'burkhold'. The database password is kept in
plaintext in one of those modules. I use the User: and Group:
directives in access.conf to cause the uid of th
anyone know of a way around this? i have a site that depends heavily on
anchors for delivering reports. exploder chops off the uri at the
arguments,
which is not what mod_auth_digest (nor RFC 2617) expect.
anyone know of a way to force exploder to use the full uri for the
digest
authorizati
gging,
> notes/pnotes, etc. I realise a lot of this would be tricky and would
> require RPC (thus opening up a security hole in its own right) but
> I think it would be worthwhile.
This is off-topic, pretty much, but interesting nonetheless.
I just stumbled across Apache DSSI http:/
On Thu, 1 Mar 2001, [EMAIL PROTECTED] wrote:
> > I used to believe that too, but now that I've developed
> > applications that make rather extensive use of the Apache API, I would
> > actually love to have an environment similar to CGI but
> > providing the full
> > Apache API, including logging
> > And forking a new process under mod_perl
> > really defeats the purpose.
>
> Does it?
Well I confess I just assumed.
> I used to believe that too, but now that I've developed
> applications that make rather extensive use of the Apache API, I would
> actually love to have an environment s
> >
> > > This is a general Unix webserver issue and not specific to
> > > mod_perl, so I've marked your message [OT] for off-topic.
> >
> > Well, workarounds are available for specific webserver environments, so I
> > don't believe it's an inappropriate question.
> >
> > With CGI, you use the
ealise a lot of this
would be tricky and would require RPC (thus opening up a security hole in
its own right) but I think it would be worthwhile.
I certainly don't like the way we're all assuming mod_perl 2.0 is going to
solve all our problems. It won't. It will just give us some fresh o
> This is a general Unix webserver issue and not specific to
> mod_perl, so I've marked your message [OT] for off-topic.
Well, workarounds are available for specific webserver environments, so I
don't believe it's an inappropriate question.
With CGI, you use the suexec mechanism to start execu
orse.
GR>May some here confirm me that if i am a security concious admin, i
GR>should not make modperl+embperl available to my user?
If you are a security conscious admin, and you cannot trust your users,
you should not make mod_perl available to them. In fact you should not
make any dynamic HTTP f
Stas Bekman wrote:
> On Wed, 28 Feb 2001, Gustavo Vieira Goncalves Coelho
Rios wrote:
> > the key user\password are kept inside this file, so
anyone can uses an
> > editor to retrieve the user mysql account. I resolve
this problem
> > running php on secure mode and chgrping the php file
th
Vladimir Ivaschenko wrote:
>
> Take a look at http://www.freevsd.org. I haven't used it personally, but
> it looks like something that you need..
> This system is a based on making a chroot environment for each user with
> his own apache and everything.
>
i can vouch for this approach to develo
Take a look at http://www.freevsd.org. I haven't used it personally, but
it looks like something that you need..
This system is a based on making a chroot environment for each user with
his own apache and everything.
Gustavo Vieira Goncalves Coelho Rios wrote about "security!"
apped by apache suexec
mechanism, is it currently done this way? Why not?
May some here confirm me that if i am a security concious admin, i
should not make modperl+embperl available to my user?
ags file access (g-rwx). So nobody
> > besides the owner of the file (or the http process) will be able to read
> > it.
> >
> > since php have some security facilities, like: if the file owner id !=
> > the file the script is trying to open => fails.
> >
On Thu, 1 Mar 2001, Gunther Birznieks wrote:
> mod_perl 2.0
>
> At 10:33 PM 2/28/2001 -1000, Kee Hinckley wrote:
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA1
> >
> >At 9:44 AM +0800 3/1/01, Stas Bekman wrote:
> > >At this moment anybody who has an access to mod_perl server can read any
> >
mod_perl 2.0
At 10:33 PM 2/28/2001 -1000, Kee Hinckley wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>At 9:44 AM +0800 3/1/01, Stas Bekman wrote:
> >At this moment anybody who has an access to mod_perl server can read any
> >data which is accessible by the same server. suexec is not an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At 9:44 AM +0800 3/1/01, Stas Bekman wrote:
>At this moment anybody who has an access to mod_perl server can read any
>data which is accessible by the same server. suexec is not an option
>because of process persistance.
I suspect this is why it is v
s and removing other flags file access (g-rwx). So nobody
> besides the owner of the file (or the http process) will be able to read
> it.
>
> since php have some security facilities, like: if the file owner id !=
> the file the script is trying to open => fails.
> My problem
php have some security facilities, like: if the file owner id !=
the file the script is trying to open => fails.
My problem is with perl: how to solve such a problem in a perl
environment?
Does mod perl allows any kind of security, to prevent ones writing
script to read others files?
PS: All
Hi folks!
I have just seted mod_perl with apache and i am using embperl too.
I am worried about security concerns for mod_perl.
How can i limit, for instance, the amount of memory used for embperl?
the ammount of time allowed for a perl code to spend. With php is easy,
there is directives like
On Fri, 17 Nov 2000, mgraham wrote:
> Maybe another approach would be to explicitly list the handlers that
> are allowed to be used in any given context. Kind of
> like 'Options', but for perl handlers. Something like 'PerlOptions',
> perhaps?
>
>
> PerlOptions "My::AuthHandler My::C
han
> exposing access to mod_perl from a shared web server security standpoint
> especially if CGI's are suexec'ed.
>
> So I would advocate an ExecModPerl option or something like that so that
> user's could not arbitrarily install their own Perl Handlers.
>[snip]
> 1
privileges he or she can commandeer the most important
> part of the request cycle (the response phase), so I'm not sure we get
> better
> security or control by having a separate ExecModPerl option.
>
> NB: If we re-use ExecCGI for mod_perl, people will feel as though they'
rl option or something like that so that
> > user's could not arbitrarily install their own Perl Handlers.
>
>Some thoughts:
>
>If a user has ExecCGI privileges he or she can commandeer the most important
>part of the request cycle (the response phase), so I'm not
If a user has ExecCGI privileges he or she can commandeer the most important
part of the request cycle (the response phase), so I'm not sure we get
better
security or control by having a separate ExecModPerl option.
NB: If we re-use ExecCGI for mod_perl, people will feel as though they'
In the context of what you are talking about, I think giving ExecCGI
permissions should not allow them to change mod_perl handlers or do
anything to adjust mod_perl either. ExecCGI is a lot less problematic than
exposing access to mod_perl from a shared web server security standpoint
on't care whether the thing that's loaded runs amok. It
is my responsibility (if I allow access to a module) to make sure that
module will behave itself.
Those more versed in security issues will perhaps want to think this
through.
I've been receiving a steady trickle of off-list mail,
I think Randal was making a similar point I was making last night (SG
time). That as long as you execute Perl code, you can manipualte the memory
space of Perl (and hance change the behavior of Apache::Registry).
But you explained it in your reply to me. Basically you want explicit
handlers th
"Randal L. Schwartz" wrote:
> I think y'all are missing it. As soon as I have any Perl code access
> via Apache::Registry or anything like that, I can do this:
>
> *Apache::Registry::handler = \&my_trojan_horse;
Can you explain in what server-configuration context the above directive
w
e.
So mod_perl is inherently unsafe. Either you have access to Perl, or
you don't. And when you don't, you might as well invent a meta-API,
like the one I suggested with Template Toolkit. You can't use the
generic tools... they're too powerful.
--
Randal L. Schwartz -
mgraham wrote:
> Maybe another approach would be to explicitly list the handlers that
> are allowed to be used in any given context. Kind of
> like 'Options', but for perl handlers. Something like 'PerlOptions',
> perhaps?
>
>
> PerlOptions "My::AuthHandler My::ContentHandler My::Tran
> I'd have no problem if mod_perl was set up to turn off
> PerlSetEnv, lit-
> eral 'sub { ... }' handlers, Perl sections, and the use of
> Perl modules
> in non-system paths (except where ExecCGI is turned on).
Maybe another approach would be to explicitly list the handlers that
are allowed to
point.
I'm just not familiar enough (yet) with its internals to be able to
think and speak creatively about the security possibilities.
--
Richard Goerwitz[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
hen they
want your added functionality, all they can do is call your interfaces
using the mini-Toolkit language embedded in their files.
And they get a slick templating system for free!
Best of both worlds.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL
Gunther Birznieks wrote:
> It seems to me that mod_perl wasn't really designed for safety against your
> own developers
I accept this point. But it's really beside _my_ point, which was that
mod_perl modules can offer critical added functionality to run-of-the-mill
web publishers (whether i
I think these are good points.
However, to some degree, if this is an attempt to allow an ISP protection,
it's not because most ISPs offer CGI access to their customers.
In addition, the moment you give mod_perl access to a developer they have
the rights to do a LOT of stuff that goes beyond p
d.
or would it? bad/uncompilable code in .htaccess would just affect the requests that
invoked it, not the parent process...
as long as the server is running as an unpriveledged nobody-user or SetUID as the
~/user who is owns it, the security concerns should be minimal. if a mod_perl pro
d.
or would it? bad/uncompilable code in .htaccess would just affect the requests that
invoked it, not the parent process...
as long as the server is running as an unpriveledged nobody-user or SetUID as the
~/user who is owns it, the security concerns should be minimal. if a mod_perl pro
Adam Prime <[EMAIL PROTECTED]> wrote:
>The servers that had apache on them for users when i was at school didn't
>even allow normal cgi, so i have no idea how one would approach doing
>something like this with mod_perl.
Even more convoluted is when a user can ExecCGI, but only via suexec.
mod_p
> -Original Message-
> From: Adam Prime [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 16, 2000 11:46 AM
> To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
> Cc: Geoffrey Young
> Subject: RE: security suggestion
>
>
> The servers that had a
> The thing is, though, that as a web administrator I don't want those
> same developers (or at least all of them) to be able to create and in-
> stall _arbitrary_ handlers or arbitrary perl code. Sometimes the de-
> velopers just don't know enough. And sometimes I just don't trust
> them enough
Maybe it's just me, but it seems that the responses richard has gotten
haven't really touched on the core of the problem. That mod_perl isn't
exactly friendly to sysadmin's who want to run apache on a (i'm guessing),
student accessed server, with user dir's and all that other stuff. I'm
pretty s
Geoffrey Young wrote:
> maybe it would be possible to limit
>
> PerlAuthenHandler 'sub {do something desctructive};'
>
> via a directive, but this is mod_perl - I can't see how you would be able to
> allow good activity without there being some way around it for destructive
> types...
That's w
Perhaps you ought to gfind a way to use Safe; then?
>-Original Message-
>From: Richard L. Goerwitz [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, November 16, 2000 9:09 AM
>To: mod_perl list
>Subject: security suggestion
>
>
>At Doug's suggestion I'm mov
> -Original Message-
> From: Richard L. Goerwitz [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 16, 2000 10:11 AM
> To: [EMAIL PROTECTED]
> Cc: Geoffrey Young
> Subject: Re: security suggestion
>
>
> Following up on the security suggestion (I'm
Following up on the security suggestion (I'm actually responding to
private mail, so I'll just quote the person who wrote to me without
giving a name) -
> Of course you can do this in an .htaccess file, too:
>
>
> arbitrary perl code...
>
I'd argue that peopl
At Doug's suggestion I'm moving a brief conversation we've had in private
to this list so others can get involved.
I've been following out the security implications of mod_perl here at
Brown University, and from what I can see, enabling it gives people the
same basic ac
Would it make sense to allow anonymous subroutines as handlers only if
ExecCGI is turned on for a given directory? (Likewise, allow handlers
only in modules residing in system directories unless ExecCGI is turned
on?)
--
Richard Goerwitz[EMAIL PROTECTED]
On Tue, 19 Sep 2000, Richard Goerwitz wrote:
> I can certainly understand why someone would want to keep Registry
> or Embperl-enabled scripts in directories reserved for trusted sys-
> tems people.
>
> But it shouldn't be a tremendously big deal to allow people to use
> pre-written modules usin
I can certainly understand why someone would want to keep Registry
or Embperl-enabled scripts in directories reserved for trusted sys-
tems people.
But it shouldn't be a tremendously big deal to allow people to use
pre-written modules using directives like 'PerlHandler', right?
Trouble is that p
the best?
> I am open for any comments and help... I plan to set up some package or at
> least a web page to explain to others how to do it once it is working
> perfectly for me. I noticed that perl security (along with shell security)
> is one of the worst seucirty/privacy treat in almo
e. I noticed that perl security (along with shell security)
is one of the worst seucirty/privacy treat in almost all web hosting
companies... and I intend to solve this. :)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Félix C.Courtemanche . Head Designer
Co-Administrator . Can-Host Net
ull for me and others.
>
> Please don't tell me to monitor the user's scripts, since that is almost
> impossible to do when you have more than 10 sites to monitor, wich will
> happen quickly :)
>
> Any other tips and tricks to improve the security of mod_perl
Felix,
There's not much available that is efficient and does per-resource
throttling based upon CPU, RAM, and time of which I know. I looked around
for such things about 8 months ago.
I instead decided that, for my needs, limiting simultaneous client access
to resource hogs was good enough. I wr
at is completed and working well.
Please keep in mind that security and optimization are the top 2 priorities
in this adventure :)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Félix C.Courtemanche . Head Designer
Co-Administrator . Can-Host Networks
http://www.can-host.com
[
gather the tools to make it as effective as possible, it would be really
> usefull for me and others.
>
> Please don't tell me to monitor the user's scripts, since that is almost
> impossible to do when you have more than 10 sites to mo
On Wed, 6 Sep 2000, Félix C.Courtemanche wrote:
> Hello,
>
> I couldn't find any occurance of this question in the archives, but if it
> does exists, please forward me to it.
>
> I have been working on a set of Administration Tools for commercial web
> hosting companies for quite some times. L
s to make it as effective as possible, it would be really
usefull for me and others.
Please don't tell me to monitor the user's scripts, since that is almost
impossible to do when you have more than 10 sites to monitor, wich will
happen quickly :)
Any other tips and tricks to improve th
On Thu, 3 Aug 2000, Rob Giseburt wrote:
> Are .htaccess files secure? I don't want users to be able to use
> ... sections or any other mod_perl constructs (setting scripts
> to run via the Registry, for example) in .htaccess files. However, I need
> .htaccess files turned on so users can passwo
On Thu, 3 Aug 2000, Ken Williams wrote:
> [EMAIL PROTECTED] (Rob Giseburt) wrote:
> >Are .htaccess files secure? I don't want users to be able to use
> >... sections or any other mod_perl constructs (setting scripts
> >to run via the Registry, for example) in .htaccess files. However, I need
>
[EMAIL PROTECTED] (Rob Giseburt) wrote:
>Are .htaccess files secure? I don't want users to be able to use
>... sections or any other mod_perl constructs (setting scripts
>to run via the Registry, for example) in .htaccess files. However, I need
>..htaccess files turned on so users can password p
On 8/3/2000 9:54 AM, Erich L. Markert at [EMAIL PROTECTED] wrote:
> Damn good question...
>
> I know the default apache config has a rule that prevents .htaccess
> files from being accessed via a URL but not from within an embedded.
>
> One way around this would be to use a database to handle a
1 - 100 of 158 matches
Mail list logo
