[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PHP and user login stuff
-----BEGIN PGP SIGNED MESSAGE-----
On Fri, 12 Feb 1999, Micah Yoder wrote:
> "Aaron D. Turner" wrote:
>
> > Sounds like a good reason not to use cookies. :-) There are easy ways to
> > keep state once someone logs in that doesn't require cookies. And if you
> > have a single point of login it becomes easy to track. Once they leave
> > our site, they'll have to log in.
>
> Actually, I think I just did think of a decent way that DOES use
> cookies. Set permanent cookies for the user's handle/password, and a
> temporary cookie (expiring in, say, 3 hours) when he logs in. If the
> temp cookie isn't set, send him to the login form!
>
> But without using cookies, I don't see how it would be easy.
Each form is a cgi. This is actually very cool way to do forms, since
Perl has a really nice way of creating forms with CGI.pm. It also allows
us to create morphing forms which change depending on the need. Each page
will read the following values and re-imbed them.
<INPUT TYPE="hidden" NAME="login" VALUE="aturner@pobox.com">
<INPUT TYPE="hidden" NAME="passwd" VALUE="crypt("somepass")">
If your interested in seeing the advantages of forms in Perl check out:
http://www.best.com/~aturner/RedHat-FAQ/ADDMGR/
Select "Aaron Turner"->Add Email to FAQ->Select a record->Edit this email
for the FAQ
Then in another browser window look at:
http://www.best.com/~aturner/RedHat-FAQ/CGI/editfaq.cgi
Notice that both are the same URL, but the page is dramatically different.
Not only does the first one have content (from the email) automatically
inserted in the proper fields, but both forms have different
fields/options to procede.
You're probably wondering why I'd do it this way. Simple:
1) Single code base to maintain
2) I can guarantee that all entries get processed the same way
3) Provides flexibility not inherient in static forms
> > We definately can't count on people allowing cookes. Even if a machine
>
> Right. It will just complicate things for THEM if they don't.
The problem is that if you don't detect the permament cookie with the
user/pass you're going to force them to re-create their user. Oops! It's
already in the database. Now the user has to create a NEW userid. Yes
there are ways around this, but now we're doing workarounds because we
can't guarantee that cookies will work.
> > "appears" to accept cookies, doesn't mean you'll be able to read them
> > later. I know people (such as myself) who symlink their cookie file to
> > /dev/null.
>
> Frankly, I dunno why people do that. Cookies *are* reasonably secure,
> at least on OSs that have file ownership and permissions. :-) And
> they're only sent to the site that issued them. But to each his own.
Simple. I don't want people tracking my movements. Where I go, and what
I browse is my business, not some corporations. Also I have no control
what some idiot programmer puts in my cookie file. What if Amazon put my
credit card # in my cookie? And there have been security concerns over
Netscapes/IE's implimentation of cookies.
> And, even Lynx supports them. Is there ANY semi-modern browser that
> doesn't? The biggest problem is users disabling them, and that's sort
> of their problem. :-)
Not modern, but people are still running 386's.
> > - From the sound of it, we're going to have them login via a form, not HTTP
> > auth. Of course then as you point out, static pages become a problem.
> > So, now you have to have every page generated dynamically. That's not
> > actually a problem with mod_perl. Sure, an all dynamic site has
> > performance problems with lots of people, but we already know we can get
> > more hardware when we need it. Besides right now our biggest problem is
>
> I dunno if I like that logic. I think we should write this to be as
> efficient as possible, so we don't have to beg for more hardware. I
I believe cross-platform and not forcing a user to do things our way is
more important. People tend to not care about cookies or feel very
strongly against them. IMHO, if you're a techie, you're more likely to no
like them, and techies are the ones that will write the entries.
> think we already decided that the articles should be static pages. With
> a big user load, that could be significant. Cookies and HTTP auth are
> the ONLY ways I know of around this.
No, you forget, Jason is putting a pre-processor wrapper. It should be
simple to add two lines of HTML such as I have above to keep state. Each
entry would have a comment line :
<!-- Begin PHP includes
- -->
for PHP to scan on to find where to put non-header information. Keeping
user login state is just one thing that could take advantage of that.
> > Basically we need a system that works for *everyone* on any browser. Some
> > browsers don't even support cookies, and many people dislike them and
> > hence turn them off. So why bother with writing the code to support
> > cookies when another solution is more cross platform. IMHO cookies just
> > mean more work and don't buy us much; if anything.
>
> I think they buy us plenty. But I agree there needs to be SOME way to
> access the system without them.
That's the point. You have to impliement a cookie way and a non-cookie
way. Why do both?
> Remember, people don't need to log in to read articles - just to submit
> them and rate them and make comments.
Exactly. :-)
- --
Aaron Turner | Either which way, one half dozen or another.
aturner@pobox.com | Check out the Red Hat Linux User's FAQ Online!
www.pobox.com/~aturner | http://www.pobox.com/~aturner/RedHat-FAQ/
All emails from this account are PGP signed. Lack of a signature is "bad".
PGP Key fingerprint = FB E1 CE ED 57 E4 AB 80 59 6E 60 BF 45 1B 20 E8
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNsXUxzM3jpXy1kJtAQEZ7QP/anL2/ghBEy7Cu/jjbuU2mV9cIfQ2OSOw
WrpK13uD+h03MSVDvrC9U3lNfjz1GaJXFZpeI4K2fLb5+nlJLK1FDgZzb5HnOzaG
4FdiWg29RFC+4cp/iU6hIbZfcYTxwIfxpP/247Ne6K7xpKpk4Hg3wDCSKd2KtPPo
cPXN1g7XuvY=
=RFq6
-----END PGP SIGNATURE-----