[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PHP and user login stuff



"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.

> 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.

> "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.

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.  :-)

> - 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
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.

> 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.

Remember, people don't need to log in to read articles - just to submit
them and rate them and make comments.