[PHP] Cookies..

[Joe]

Here's my three-hour's worth of work on cookies. I never really figured out how to delete a cookie so ?logout won't work. You have to redirect yourself to ?info manually, and for some reason the cookie explode function won't work. Anyhow, here it is (test).

[Warrior]

You use set_cookie(blah, "", time);

[iago]

x86] link=topic=6119.msg72804#msg72804 date=1149678173]
You use set_cookie(blah, "", time);

Isn't that what he's doing?

[rabbit]

No, he does nothing:

Code Select Expand

        case "logout":        // logging out, duh
            break;

Secondly, md5 blows.  Change them to SHA1.
You should also call error_reporting(E_ALL) and do an isset() check on your get variables.  You should also set a cookie expiration date.  Setting cookies good until the browser closes is a stupid thing to do, and can be replaced by the $_SESSION superglobal (that's what it was made for).

Nextly, you should return all of your strings, and never print from functions, unless you're doing OOP (which you're not).

Furthermore, hange the password box to a password type.  Also, "Translate"?  WTF?

You have a problem:

Cookie: a722c63db8ec8625af6cf71cb8c2d939 test1
Logged in as test1
Account doesn't exist.

I can't be logged in with a non-existant account.  It doesn't make sense.  You could be tracing these problems out with error_reporting(E_ALL);

[iago]

You're being overly picky for no reason. 

No, he does nothing:

Code Select Expand

        case "logout":        // logging out, duh
            break;

I thought he meant in general, I didn't realize he was talking about the logging out.

Secondly, md5 blows.  Change them to SHA1.

In this context, md5 vs sha1 makes absolutely no difference.

You should also call error_reporting(E_ALL) and do an isset() check on your get variables.

Useful advice for developing, in general, but he's releasing the software so setting it to E_ALL would be annoying for others.

  You should also set a cookie expiration date.  Setting cookies good until the browser closes is a stupid thing to do, and can be replaced by the $_SESSION superglobal (that's what it was made for).

That's true, but then this wouldn't be a demonstration of cookies, would it?  There's nothing wrong with a login cookie expiring at close, even if session is better.  It's definitly not "stupid". 

Nextly, you should return all of your strings, and never print from functions, unless you're doing OOP (which you're not).

Both ways are fine. 

Furthermore, hange the password box to a password type.

Again: demonstration. 

You have a problem:

Cookie: a722c63db8ec8625af6cf71cb8c2d939 test1
Logged in as test1
Account doesn't exist.

I can't be logged in with a non-existant account.  It doesn't make sense.  You could be tracing these problems out with error_reporting(E_ALL);

You don't have to be an asshole when you report a bug. 

[Joe]

As for E_ALL, I was expecting the programmer who implements a changed version of this to add their own error checking, etc. Also, printing from functions was just the quick-and-sloppy approach I took to this, trying to get the concept to work even if it required breaking coding style (which can always be fixed later).

Also, you can very well be logged in from a nonexistant account. Hack your cookies file and put in "ffffffffffffffffffffffffffffffff acct_that_doesnt_exist".

[Warrior]

You're mutilating PHP..stop it.

[rabbit]

You're being overly picky for no reason. 

I'm criticizing his code and trying to help him learn how to better implement his ideas in PHP.  I'm not trying to be mean or anything.

Secondly, md5 blows.  Change them to SHA1.

In this context, md5 vs sha1 makes absolutely no difference.

md5 is infitely easier to collide than sha1, and if someone hijacked an admin cookie, they could easily log in as the superuser.

You should also call error_reporting(E_ALL) and do an isset() check on your get variables.

Useful advice for developing, in general, but he's releasing the software so setting it to E_ALL would be annoying for others.

I keep E_ALL on on all of my projects, and trap the errors, though it is just personal preference.

  You should also set a cookie expiration date.  Setting cookies good until the browser closes is a stupid thing to do, and can be replaced by the $_SESSION superglobal (that's what it was made for).

That's true, but then this wouldn't be a demonstration of cookies, would it?  There's nothing wrong with a login cookie expiring at close, even if session is better.  It's definitly not "stupid". 

I'm just saying it would be a more effective demonstration of cookies if he did something that only cookies could do, like carrying a login over multiple sessions.

Nextly, you should return all of your strings, and never print from functions, unless you're doing OOP (which you're not).

Both ways are fine. 

Gah..I supposed, but it bugs me.

Furthermore, hange the password box to a password type.

Again: demonstration. 

It's what the "password" type is for.

You have a problem:

Cookie: a722c63db8ec8625af6cf71cb8c2d939 test1
Logged in as test1
Account doesn't exist.

I can't be logged in with a non-existant account.  It doesn't make sense.  You could be tracing these problems out with error_reporting(E_ALL);

You don't have to be an asshole when you report a bug. 

Wasn't trying to be.  I was just pointing out that something went wrong and conflicting messages were printed.  Anyway, that "could" is should*, my bad.

[Sidoh]

Tip: use <?php.  I think I've told you that before.

[rabbit]

Yeah, I completely overlooked that.

<? is used by XML as well, so you should always do <?php and <?xml, instead of just plain old <?.  Also, though it's not *required*, php?> works just as well, but isn't all that helpful unless you're mixing XML and PHP

[Warrior]

Nextly, you should return all of your strings, and never print from functions, unless you're doing OOP (which you're not).

Both ways are fine. 

I strongly suggest learning to seperate core code from display code. It applies in almost every programming language and is a plus for organization. It's a bitch to upgrade code which is riddled with a bunch of HTML. Please, do yourself a favor. Both ways are not fine. I'm warning you.

[Joe]

This was a demonstration of how cookies can be used, not how to write PHP.

[Warrior]

You should always write good PHP. That's a bad demonstration at most.

[Sidoh]

That's like writing an English paper on how to use semicolens, but failing to use other aspects of the language correctly.  It's just stupid.

[Chavo]

<insert generic comment about poor programming habits here>

actually, I'm sure I would be saying more than that if it was in a language that I knew better :)