Or you could tell your webserver to deny everything except access to
redirect.php, this saves you from moving everything to some obscure place...
> -----Original Message-----
> From: Michael Mehlmann [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 07, 2001 10:18 AM
> To: Stefen Lars
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP] Insecurity with PHP authorization
>
>
> If you don't have a very high load, then you could move all not-php-files
> out of htdocs-root and use a pseudo-root directory
> htdocs/../rawfiles as root
> for redirect.php.
> For example image.jpg is placed in htdocs/../rawfiles/images then
> access it
> with /redirect.php?/images/image.jpg !
> redirect.php only checks for authorization and then does a fpassthru!
> that won't cost much!
>
> hth
> Michael
>
> > Hello all
> >
> > I have just implemented a mySQL authorization: each html and php page
> > checks
> > to see whether a user is logged in by checking a cookie in the user
> > browser.
> > The user can log out and edit her profile (including password).
> If a page
> > is
> > called without the user being logged in, he is presented with a log in
> > form.
> > This works very well. There is an SSL connection to the server. Only a
> > hash
> > value of the password is stored in the database.
> >
> > However, if I directly request a graphic (or a ZIP file etc) from the
> > site,
> > by entering:
> > https://www.myserver.com/photo.jpg for example, I can download
> that file
> > without being logged in (naturally).
> >
> > In the particular *intranet* project that I am working on, this is
> > particularly undesirable, as only personnel at the company’s four
> > locations
> > may have access to the intranet. And there certainly will be a lot of
> > ‘confidential’ ZIP and graphic files placed on the server.
> >
> > I do realize that if I were to place a .htaccess file in the
> root of the
> > intranet server, I could prevent the above from happening, but then I
> > loose
> > the advantage of having the users profile in a database, where
> a user can
> > easily change her password. Allowing a web user to edit a
> password in the
> > .htaccess file poses more problems than it solves, especially as it
> > certainly could occur that more than one persons wants to edit his
> > password
> > simultaneously.
> >
> > Could anyone suggest a method to allow a user to easily edit
> his password,
> >
> > but at the same time, not allow direct access to specific
> non-PHP files on
> >
> > the intranet server?
> >
> > Perhaps one method would be to restrict access to the
> company’s four
> > gateway
> > servers (IP addresses). However, I feel this is not to secure, and these
> > IPs
> > could be spoofed (and this does not really solve the problem).
> >
> > Any enlightenment on this subject would be well received.
> >
> > TIA
> >
> > S.
> >
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp
> >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
>
> --
> Aufgepasst - jetzt viele 1&1 New WebHosting Pakete ohne
> Einrichtungsgebuehr + 1 Monat Grundgebuehrbefreiung!
> http://puretec.de/index.html?ac=OM.PU.PU003K00736T0492a
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
