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