Re: htaccess and a login "page"

    Hi David,
    Just thought I'd mention/remind you of the prying eyes that read our
e-mail. You may or may not be aware that our fine government has a super
computer that reads all e-mail & picks out key phrases - the use of a
particuliar name would be a huge red flag right now.......  I know of one
case where a woman said her son "bom*ed" at a school play & she was listed
as a known you-know-what. Now, I don't usually care what they list me as (&
they probably have), I just don't want to give them extra work right now so
I watch what I send - I'm sure they're pretty busy..... ;^ )
    So we all need to watch what we send at least for now. :-)
    Some of you may think this is rumor or hearsay, but hey I saw it on
TV......
      Paul Angel

http://valuewebinc.com
http://v-firms.com
http://webcomnow.com
http://sitesense.com
http://DigitalRescue.org
----- Original Message -----
From: "David Sharp" <David.Sharp(at)sharp-words.com>
To: <hwg-techniques(at)hwg.org>
Sent: Thursday, September 27, 2001 12:50 AM
Subject: Re: htaccess and a login "page"


> At 11:30 -0400 26/09/01, Jeniffer C. Johnson wrote:
>
> >.../...When a member clicks on a "login now" link, I would like the
> >user to be presented with a nice tidy html page with the login form
> >and a "submit" button, rather than the popup dialogue box for
> >entering username and password. Is this doable?
>
> I'm coming in a bit belatedly on this one. This is my take on the
> type of method suggested by Hank Marquardt in his reply.
>
> I've done something similar on my http://www.sharp-words.com/ site,
> but without using .htaccess to protect the "private" directory.
> Instead it uses PHP and cookies.
>
> As the material I'm protecting is just family pictures and documents
> (and my family contains nobody called "******"), I haven't thought
> it necessary to provide a very high level of security.
>
> However I'm pretty sure there's a way to both provide the kind of
> form you want, and protect the directories where your sensitive stuff
> is at the .htaccess level.
>
> I've a form at the bottom of each page which allows registered users
> to sign on. When they do so, the page script sets a session cookie,
> which is tested for on each access.
>
> All the pages on the site are generated as the same index file at the
> root, with individual directories containing only flat text files and
> PHP table files.
>
> Pages are built on the fly via PHP inclusions. This means that
> accesses to individual subdirectories are made not via http, but via
> PHP.
>
> If what I'm writing here is correct (and I have clear memories that
> it is, although I haven't time to test it right now), the difference
> is crucial.
>
> The only way anyone could get at the actual files in the directories
> on my site is if they were to work out the architecture.
>
> It's true that this shouldn't be too difficult for someone to work
> out, if they reckoned it was worth the bother, although if I really
> wanted to, I could make it less than intuitive by using weird names
> for my data tables, and weird file extensions for the data that would
> take some guessing.
>
> Now I'm pretty certain that placing a ban on http access to a file or
> directory at the .htaccess level *doesn't* prevent PHP from accessing
> the material in question. I seem to remember doing this on a regular
> basis a few years ago.
>
> This means that if you use my method (which as far as I know is
> pretty common, as regards site architecture), you should be able to
> protect your membership information from prying eyes via .htaccess,
> while at the same time letting registered users get to it via a PHP,
> or other server-side, inclusion script.
>
> Any smart Alec who happened to know the name and path data of a file
> in your protected directory - such as the file containing your
> members' names, addresses and bank account numbers - would be unable
> to do so.
>
> Of course, the corollary is that your registered users need to have
> cookies enabled in their browsers, but you can warn them of that.
> (The "session" gizmo in PHP might even avoid using cookies, but I've
> never tried using it, so I'm not sure).
>
> Note, however this method *won't* work if the files you're trying to
> protect are images, or other downloadable files, because the client
> requests those via http.
>
> Hope this makes sense - and is of some use.
> --
> David Sharp, journaliste, France <mailto:david.sharp(at)sharp-words.com>
> Site et forum ("Tuyaux")  / Press site & mailing list:
> http://www.presse-en-ligne.com/
> Site personnel / Personal home page http://www.sharp-words.com/
>
>

HWG hwg-techniques mailing list archives, maintained by Webmasters @ IWA