How would I go about protecting a whole directory, e.g.
http://www.example.com/members/ and all sub-directories with login
protection? I wouldn't like to put a .php script in each directory and
I'd like to protect all file-types
rogerjames1@googlemail.com wrote:
> How would I go about protecting a whole directory, e.g.
> http://www.example.com/members/ and all sub-directories with login
> protection? I wouldn't like to put a .php script in each directory and
> I'd like to protect all file-types
>
Hi,
If you use Apache, have a look at .htaccess.
Google around, many articles.
Regards,
Erwin Moller
On Aug 23, 6:42 pm, Erwin Moller
> Hi,
>
> If you use Apache, have a look at .htaccess.
> Google around, many articles.
>
> Regards,
> Erwin Moller
Was going to use .htaccess but I'd require a better user management
with MySQL database, registeration page, admin page, forgot password
feature.
Would coding a script that runs every minute and dumps user/pass to
a .htpasswd file be too taxing on a high traffic site?
On Aug 23, 1:00 pm, rogerjam...@googlemail.com wrote:
> On Aug 23, 6:42 pm, Erwin Moller
>
>
> > Hi,
>
> > If you use Apache, have a look at .htaccess.
> > Google around, many articles.
>
> > Regards,
> > Erwin Moller
>
> Was going to use .htaccess but I'd require a better user management
> with MySQL database, registeration page, admin page, forgot password
> feature.
>
> Would coding a script that runs every minute and dumps user/pass to
> a .htpasswd file be too taxing on a high traffic site?
One thing you might think about is this: since .htaccess, .htpasswd
files are already in a fairly strict format, you can pretty easily
parse it, and simply update entries in the .hpasswd file when the
database updates. Basically, keep the .htpasswd file and the database
concurrent.
On Aug 23, 2:08 pm, "burgermeiste...@gmail.com"
> On Aug 23, 1:00 pm, rogerjam...@googlemail.com wrote:
>
>
>
> > On Aug 23, 6:42 pm, Erwin Moller
>
> >
> > > Hi,
>
> > > If you use Apache, have a look at .htaccess.
> > > Google around, many articles.
>
> > > Regards,
> > > Erwin Moller
>
> > Was going to use .htaccess but I'd require a better user management
> > with MySQL database, registeration page, admin page, forgot password
> > feature.
>
> > Would coding a script that runs every minute and dumps user/pass to
> > a .htpasswd file be too taxing on a high traffic site?
>
> One thing you might think about is this: since .htaccess, .htpasswd
> files are already in a fairly strict format, you can pretty easily
> parse it, and simply update entries in the .hpasswd file when the
> database updates. Basically, keep the .htpasswd file and the database
> concurrent.
..htaccess/.htpasswd is going to give you "true" directory security in
comparison to a php solution. PHP authentication/authorization is
great, but only works on files that have php on it, or goes through
php, etc. For example, I have a page with dynamics data pulled from
the database...that data is protected from access by my controls. The
page itself could be protected using sessions. However, if I have
my_special_pic.jpg in there...all they have to know is the address and
they got it. With .htaccess, however, they will be prompted during
connection. The difference is between HTTP authentication and
whatever you implement in PHP.
rogerjames1@googlemail.com wrote:
> How would I go about protecting a whole directory, e.g.
> http://www.example.com/members/ and all sub-directories with login
> protection? I wouldn't like to put a .php script in each directory and
> I'd like to protect all file-types
>
You can use mod_rewrite to redirect every request to index.php, e.g.
RewriteRule .* index.php?file=$0 [L,QSA]
--
gosha bine
extended php parser ~ http://code.google.com/p/pihipi
blok ~ http://www.tagarga.com/blok
rogerjames1@googlemail.com wrote:
> Was going to use .htaccess but I'd require a better user management
> with MySQL database, registeration page, admin page, forgot password
> feature.
> Would coding a script that runs every minute and dumps user/pass to
> a .htpasswd file be too taxing on a high traffic site?
Well i guess you would want to have login in a nice page instead of that
popup box that is used for HTTP authentication. While HTTP auth would be
pretty secure, it might give your users the impression that something is
wrong. So i guess the mod_rewrite thing would be closest to that and still
pretty secure.
Best regards,
Jan
--
____________________________________________________________ _____________
insOMnia - We never sleep...
http://www.insOMnia-hq.de
rogerjames1@googlemail.com escribió:
> Was going to use .htaccess but I'd require a better user management
> with MySQL database, registeration page, admin page, forgot password
> feature.
>
> Would coding a script that runs every minute and dumps user/pass to
> a .htpasswd file be too taxing on a high traffic site?
There're several modules that provide HTTP authentication in Apache. I'm
not sure of which ones are usually available in hosting services but
I've used mod_auth_mysql for several years and it works fine:
http://modauthmysql.sourceforge.net/
However, you must be aware that you won't be able to use a custom login
form if you use HTTP authentication. Even if you validate an user using
a form, the browser won't know about it and will open its own prompt and
ask for credentials. I've never found an acceptable workaround.
--
-+ http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
++ Mi sitio sobre programación web: http://bits.demogracia.com
+- Mi web de humor austrohúngaro: http://www.demogracia.com
--
Álvaro G. Vicario wrote:
> rogerjames1@googlemail.com escribió:
>> Was going to use .htaccess but I'd require a better user management
>> with MySQL database, registeration page, admin page, forgot password
>> feature.
>>
>> Would coding a script that runs every minute and dumps user/pass to
>> a .htpasswd file be too taxing on a high traffic site?
>
> There're several modules that provide HTTP authentication in Apache. I'm
> not sure of which ones are usually available in hosting services but
> I've used mod_auth_mysql for several years and it works fine:
>
> http://modauthmysql.sourceforge.net/
>
> However, you must be aware that you won't be able to use a custom login
> form if you use HTTP authentication. Even if you validate an user using
> a form, the browser won't know about it and will open its own prompt and
> ask for credentials. I've never found an acceptable workaround.
>
>
>
There isn't. HTTP authentication comes into play before any calls to
the files themselves. Unfortunately, there's no way to tell the browser
what to send for authentication credentials except through the HTTP
authentication mechanism (i.e. no PHP or Javascript code can force it).
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
mod_auth_mysql developer/administrator
==================
On Aug 23, 2:15 pm, gosha bine
> rogerjam...@googlemail.com wrote:
> > How would I go about protecting a whole directory, e.g.
> >http://www.example.com/members/and all sub-directories with login
> > protection? I wouldn't like to put a .php script in each directory and
> > I'd like to protect all file-types
>
> You can use mod_rewrite to redirect every request to index.php, e.g.
>
> RewriteRule .* index.php?file=$0 [L,QSA]
>
> --
> gosha bine
>
> extended php parser ~http://code.google.com/p/pihipi
> blok ~http://www.tagarga.com/blok
Now you're kinda getting into the realm of a front controller and,
while it will give him the security...I'm not sure exactly what will
happen with things like /.(jpg|gif|png|css)$ this could work, but
would reak havok on a lot of other parts of your code, and will likely
increase complexity unnecessarily. Unless you're already going with
an MCV design...I'm not sure this would be the best way to tackle it.
Jerry Stuckle wrote:
> Álvaro G. Vicario wrote:
>> rogerjames1@googlemail.com escribió:
>>> Was going to use .htaccess but I'd require a better user management
>>> with MySQL database, registeration page, admin page, forgot password
>>> feature.
>>>
>>> Would coding a script that runs every minute and dumps user/pass to
>>> a .htpasswd file be too taxing on a high traffic site?
>>
>> There're several modules that provide HTTP authentication in Apache.
>> I'm not sure of which ones are usually available in hosting services
>> but I've used mod_auth_mysql for several years and it works fine:
>>
>> http://modauthmysql.sourceforge.net/
>>
>> However, you must be aware that you won't be able to use a custom
>> login form if you use HTTP authentication. Even if you validate an
>> user using a form, the browser won't know about it and will open its
>> own prompt and ask for credentials. I've never found an acceptable
>> workaround.
>>
>>
>>
>
> There isn't. HTTP authentication comes into play before any calls to
> the files themselves. Unfortunately, there's no way to tell the browser
> what to send for authentication credentials except through the HTTP
> authentication mechanism (i.e. no PHP or Javascript code can force it).
>
>
>
Might want to read this
http://www.php.net/manual/en/features.http-auth.php
--
gosha bine
extended php parser ~ http://code.google.com/p/pihipi
blok ~ http://www.tagarga.com/blok
ELINTPimp wrote:
> On Aug 23, 2:15 pm, gosha bine
>> rogerjam...@googlemail.com wrote:
>>> How would I go about protecting a whole directory, e.g.
>>> http://www.example.com/members/and all sub-directories with login
>>> protection? I wouldn't like to put a .php script in each directory and
>>> I'd like to protect all file-types
>> You can use mod_rewrite to redirect every request to index.php, e.g.
>>
>> RewriteRule .* index.php?file=$0 [L,QSA]
>>
>> --
>> gosha bine
>>
>> extended php parser ~http://code.google.com/p/pihipi
>> blok ~http://www.tagarga.com/blok
>
> Now you're kinda getting into the realm of a front controller and,
> while it will give him the security...I'm not sure exactly what will
> happen with things like /.(jpg|gif|png|css)$ this could work, but
> would reak havok on a lot of other parts of your code, and will likely
> increase complexity unnecessarily. Unless you're already going with
> an MCV design...I'm not sure this would be the best way to tackle it.
>
Sorry, I don't understand what you tried to say here... Maybe it's just
Friday. ;)
--
gosha bine
extended php parser ~ http://code.google.com/p/pihipi
blok ~ http://www.tagarga.com/blok
gosha bine wrote:
> Jerry Stuckle wrote:
>> Álvaro G. Vicario wrote:
>>> rogerjames1@googlemail.com escribió:
>>>> Was going to use .htaccess but I'd require a better user management
>>>> with MySQL database, registeration page, admin page, forgot password
>>>> feature.
>>>>
>>>> Would coding a script that runs every minute and dumps user/pass to
>>>> a .htpasswd file be too taxing on a high traffic site?
>>>
>>> There're several modules that provide HTTP authentication in Apache.
>>> I'm not sure of which ones are usually available in hosting services
>>> but I've used mod_auth_mysql for several years and it works fine:
>>>
>>> http://modauthmysql.sourceforge.net/
>>>
>>> However, you must be aware that you won't be able to use a custom
>>> login form if you use HTTP authentication. Even if you validate an
>>> user using a form, the browser won't know about it and will open its
>>> own prompt and ask for credentials. I've never found an acceptable
>>> workaround.
>>>
>>>
>>>
>>
>> There isn't. HTTP authentication comes into play before any calls to
>> the files themselves. Unfortunately, there's no way to tell the
>> browser what to send for authentication credentials except through the
>> HTTP authentication mechanism (i.e. no PHP or Javascript code can
>> force it).
>>
>>
>>
>
> Might want to read this
>
> http://www.php.net/manual/en/features.http-auth.php
>
>
Yes, I'm familiar with it. And all you can do is send an "401
Authentication Required" header.
Additionally, you can get the authentication information from the
$_SERVER variables.
But there is no way you can force the browser to send authentication
information from either PHP or javascript. And nothing in this
contradicts my statement.
I've been developer/admin of mod_auth_mysql for several years, and
thoroughly understand how it works. I suggest you reread the article
and learn how HTTP authentication works.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
On Aug 23, 11:08 am, rogerjam...@googlemail.com wrote:
> How would I go about protecting a whole directory, e.g.http://www.example.com/members/and all sub-directories with login
> protection? I wouldn't like to put a .php script in each directory and
> I'd like to protect all file-types
I didn't read the whole thread in detail, but I glanced at every
post. I (think) I have a way to do this that didn't yet come up.
How secure the protection needs to be is important.
If you're talking about financial transactions
or trade secrets, then perhaps my method isn't such a good idea.
I sell digital information. So If I do get hacked the only thing
I lost was a transaction that never would have happened legitimately
anyway.
I sell subscriptions to how-to-do-it boat building instructions.
I make every file underneath some directory point a .php file, even
though it's largely static html.
At the top of each such file (they are all machine genertated, from
mysql tables) I put a few lines of code that looks for a $_SESSION
variable. If that session variable is not set to the right value,
I redirect the page to a login screen. The session variable that
serves
as the key to the secure area only gets set if the user passes a
password test in the login screen. My customers frequently complain
how inconvenient it is........that they can't bookmark the pages.
So this system seems to work just fine for me. .htaccess and mod-
rewrite
don't play a role.
salmobytes wrote:
> On Aug 23, 11:08 am, rogerjam...@googlemail.com wrote:
>> How would I go about protecting a whole directory, e.g.http://www.example.com/members/and all sub-directories with login
>> protection? I wouldn't like to put a .php script in each directory and
>> I'd like to protect all file-types
>
> I didn't read the whole thread in detail, but I glanced at every
> post. I (think) I have a way to do this that didn't yet come up.
> How secure the protection needs to be is important.
> If you're talking about financial transactions
> or trade secrets, then perhaps my method isn't such a good idea.
> I sell digital information. So If I do get hacked the only thing
> I lost was a transaction that never would have happened legitimately
> anyway.
>
> I sell subscriptions to how-to-do-it boat building instructions.
> I make every file underneath some directory point a .php file, even
> though it's largely static html.
>
> At the top of each such file (they are all machine genertated, from
> mysql tables) I put a few lines of code that looks for a $_SESSION
> variable. If that session variable is not set to the right value,
> I redirect the page to a login screen. The session variable that
> serves
> as the key to the secure area only gets set if the user passes a
> password test in the login screen. My customers frequently complain
> how inconvenient it is........that they can't bookmark the pages.
> So this system seems to work just fine for me. .htaccess and mod-
> rewrite
> don't play a role.
>
That works fine for html/php files. But it doesn't work for images,
pdf's, etc.
And the original op indicated he didn't want to put a PHP file in every
directory, and wanted to protect all file types.
When the "all file type" requirement comes up and the customer doesn't
wish to use http authentication, I use a combination of .htaccess and
PHP. When someone request access to a protected file, Apache redirects
to a PHP script which checks the credentials. If they are logged in, it
retrieves the file (from a directory outside the webserver's document
root directory, applies the appropriate content-type header and delivers
it. If they aren't logged in yet, I present the login screen, and after
logging in, they are presented with the file.
They can also bookmark these pages.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Jerry Stuckle wrote:
> gosha bine wrote:
>> Jerry Stuckle wrote:
>>> Álvaro G. Vicario wrote:
>>>> rogerjames1@googlemail.com escribió:
>>>>> Was going to use .htaccess but I'd require a better user management
>>>>> with MySQL database, registeration page, admin page, forgot password
>>>>> feature.
>>>>>
>>>>> Would coding a script that runs every minute and dumps user/pass to
>>>>> a .htpasswd file be too taxing on a high traffic site?
>>>>
>>>> There're several modules that provide HTTP authentication in Apache.
>>>> I'm not sure of which ones are usually available in hosting services
>>>> but I've used mod_auth_mysql for several years and it works fine:
>>>>
>>>> http://modauthmysql.sourceforge.net/
>>>>
>>>> However, you must be aware that you won't be able to use a custom
>>>> login form if you use HTTP authentication. Even if you validate an
>>>> user using a form, the browser won't know about it and will open its
>>>> own prompt and ask for credentials. I've never found an acceptable
>>>> workaround.
>>>>
>>>>
>>>>
>>>
>>> There isn't. HTTP authentication comes into play before any calls to
>>> the files themselves. Unfortunately, there's no way to tell the
>>> browser what to send for authentication credentials except through
>>> the HTTP authentication mechanism (i.e. no PHP or Javascript code can
>>> force it).
>>>
>>>
>>>
>>
>> Might want to read this
>>
>> http://www.php.net/manual/en/features.http-auth.php
>>
>>
>
> Yes, I'm familiar with it. And all you can do is send an "401
> Authentication Required" header.
No, just read it. You can send "WWW-Authenticate" and specify realm and
authentication type (basic, digest). You can also send the text that
will be shown if authentication fails.
>
> Additionally, you can get the authentication information from the
> $_SERVER variables.
>
> But there is no way you can force the browser to send authentication
> information from either PHP or javascript. And nothing in this
> contradicts my statement.
Your statement is fairly unclear. I fail to see the browser can "send"
anything "from PHP". Php is not something the browser is aware off (I
know, you're familiar with that fact).
>
> I've been developer/admin of mod_auth_mysql for several years, and
> thoroughly understand how it works. I suggest you reread the article
> and learn how HTTP authentication works.
>
Noone questions your skills. You take it too personally. ;)
--
gosha bine
extended php parser ~ http://code.google.com/p/pihipi
blok ~ http://www.tagarga.com/blok
> If they are logged in, it
> retrieves the file (from a directory outside the webserver's document
> root directory, applies the appropriate content-type header and delivers
> it. If they aren't logged in yet, I present the login screen, and after
> logging in, they are presented with the file.
>
> They can also bookmark these pages.
>
Thank you. That's a good idea. In my case (boat building manuals)
clever boat builders don't need the text, they just need to
see the images (which have dimensions). I'll rewrite my
page generation stuff so it works that way. Of course, in
my case I'm lucky, because boat builders tend not to be
thieves :-)
gosha bine wrote:
> Jerry Stuckle wrote:
>> gosha bine wrote:
>>> Jerry Stuckle wrote:
>>>> Álvaro G. Vicario wrote:
>>>>> rogerjames1@googlemail.com escribió:
>>>>>> Was going to use .htaccess but I'd require a better user management
>>>>>> with MySQL database, registeration page, admin page, forgot password
>>>>>> feature.
>>>>>>
>>>>>> Would coding a script that runs every minute and dumps user/pass to
>>>>>> a .htpasswd file be too taxing on a high traffic site?
>>>>>
>>>>> There're several modules that provide HTTP authentication in
>>>>> Apache. I'm not sure of which ones are usually available in hosting
>>>>> services but I've used mod_auth_mysql for several years and it
>>>>> works fine:
>>>>>
>>>>> http://modauthmysql.sourceforge.net/
>>>>>
>>>>> However, you must be aware that you won't be able to use a custom
>>>>> login form if you use HTTP authentication. Even if you validate an
>>>>> user using a form, the browser won't know about it and will open
>>>>> its own prompt and ask for credentials. I've never found an
>>>>> acceptable workaround.
>>>>>
>>>>>
>>>>>
>>>>
>>>> There isn't. HTTP authentication comes into play before any calls
>>>> to the files themselves. Unfortunately, there's no way to tell the
>>>> browser what to send for authentication credentials except through
>>>> the HTTP authentication mechanism (i.e. no PHP or Javascript code
>>>> can force it).
>>>>
>>>>
>>>>
>>>
>>> Might want to read this
>>>
>>> http://www.php.net/manual/en/features.http-auth.php
>>>
>>>
>>
>> Yes, I'm familiar with it. And all you can do is send an "401
>> Authentication Required" header.
>
> No, just read it. You can send "WWW-Authenticate" and specify realm and
> authentication type (basic, digest). You can also send the text that
> will be shown if authentication fails.
>
Yes, but you can't force the browser to provide a list of credentials in
lieu of the popup box you get when accessing a restricted directory.
>>
>> Additionally, you can get the authentication information from the
>> $_SERVER variables.
>>
>> But there is no way you can force the browser to send authentication
>> information from either PHP or javascript. And nothing in this
>> contradicts my statement.
>
> Your statement is fairly unclear. I fail to see the browser can "send"
> anything "from PHP". Php is not something the browser is aware off (I
> know, you're familiar with that fact).
>
No, my statement is perfectly clear. When a request for ANY protected
resource is made, the browser must send the appropriate authentication
data. For instance, if you have a web page with seven images, all in a
protected directory, the browser will make eight requests, and have to
send eight sets of credentials. There is no way for PHP or Javascript
to bypass this, but the browser handles it automatically. You should be
able to do it with a browser extension, but that would require everyone
using the site to download the extension.
And PHP can't do anything about it (other than redirect the user)
because if the user doesn't authenticate, the page is never loaded.
And this doesn't work for non-PHP files.
>>
>> I've been developer/admin of mod_auth_mysql for several years, and
>> thoroughly understand how it works. I suggest you reread the article
>> and learn how HTTP authentication works.
>>
>
> Noone questions your skills. You take it too personally. ;)
>
>
No, I'm just pointing out that I understand how HTTP authentication works.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Before we get too far off course here - I'd like to describe how I
handled jobs like this:
1- You need $_SESSION-Handling and some kind of Session-Based
Userlogin
2- You create an empty directory like /protected that has a .htaccess-
File with
Deny to All
and the abovementioned mod_rewrite line (slightly modified)
RewriteRule .* ../get_protected.php?file=$0 [L,QSA]
3- you put all the stuff to be protected in a 'data' directory OUTSIDE
the webserver path (you can leave it in /protected, but outside it's
even safer)
4- in get_protected.php you
- authenticate the user from his $_SESSION-data
- find the file by inspecting $_GET['file'] and checking if it
exists in your 'data' directories
- set the mimetype in the Header according to the filetype
- use readfile() to send the file to the user
*- expect webserver processing time to be higher than normal for
session handling and php in places where it usually isn't used (like
displaying images)
as said before: there's no way to do http-authentication (.htpasswd/
mod_auth_mysql) by setting the Authentication headers without
presenting the user with a browser-password-form. I had it working
once (by creating a meta-refresh to an URL that used the
http://user:password@www.myserver.com-Scheme) but that was rather
dirty, presented passwords in cleartext and was removed when IE6 no
longer accepted this password/URL scheme.
Hope this helps
Phil