Jim, looks good to me, but I’ll want to test drive a bit.
I’d change the $secure type though, it should not use a bool, but rather 1 for true and 0 for false.
The php manual says:
Because setting a cookie with a value of FALSE will try to delete the cookie, you should not use boolean values. Instead, use 0 for FALSE and 1 for TRUE.
EDIT: Jim, would’nt be the first time a manual was wrong.
Because setting a cookie with a value of FALSE will try to delete the cookie, you should not use boolean values. Instead, use 0 for FALSE and 1 for TRUE.
Oscar, I found that page and read through it. The quote is indeed in the manual as you say, but it is referring to the value of a cookie, not any of its flags. If I had a cookie that I needed to set with a BOOL value, the PHP folks are recommending I use 1 or 0 as the value instead.
Also please take note, I have edited my earlier post to remove the cookie helper code and post a link to my site where it is now hosted with a modified user guide page.
Well crap…it is working well for me. I don’t know 100% that this is a straight-forward drop in replacement for the original, though…and that could be a bad thing as far as getting an update out there. Maybe if you give the modified user guide page a good look through you can see what is different…?
Nothing at this point is committed. Yes, I will be happy to commit the changes after everyone’s had a chance to vet them. In fact, I’d be willing to look at the complete library replacement as well.
Gives this :
Message: Cookie names can not contain any of the folllowing ‘=,; \t\r\n1314’ (ccookie name)
I kid you not. Notice the extra ‘c’ in ccookie name.
I get this when I look at the cookie via tamper, it has things like cpath=c and so on.
In FF, It appears the cookie is not set (options, view cookies)
I am going to leave this until tommorow, maybe I’ll be sane again
OK, I will leave this as an exercise in “I-am-a-php-guru-cause-i-can-answer-this-question”
I noticed that the problem occurs if I pass an array, but not if I use discrete parameters.
So then, if the order of parameters in the foreach is changed to have ‘name’ last, it works!!!
Oscar, that makes perfect sense that ‘name’ would have to be the last parameter. I had reordered the array indexes to match the order of the function parameters. But I forgot that if an array is passed, its name IS $name, and each of its indexes (one of which is also named ‘name’) is turned into a variable of the same name. So if ‘name’ is anywhere but last, $name is over written by ‘name’ being converted into a variable leaving portions of the array having not be processed.
@ Jim : Yup, everything is fine now with latest update to modCookieHelper.zip
@Derek : I have tested this pretty exhaustively as regards the functionality: That is, setting, getting and
deleting cookies using the modified helper, with and without defaults, via array or discrete params.
I have however only tested on windows with FireFox so far. I think Jim is using FF on Linux.
Jim has done a great job, both on the helper and the User guide page. I don’t think the change to the config
will cause any problems, but perhaps best to revert to the original defaults viz empty prefix, domain and
path = “/”. The new cookie_lifetime config should default to zero.
I’m happy to sign off on this commit. You should be able to grab the helper and user guide page from Jim’s site
as is and commit. If there’s anything else you can think of, let us know, be happy to help.
EDIT: Ozone is at his parade ground best this Sunday The user guide refers to
“discreet parameters”, that means modest or unobtrusive, it should be “discrete” meaning
distinct or seperate.
Wow, Oscar, thanks for that input and your testing (again!). Tomorrow I will do some heavy stand alone testing on this myself with Fx, IE, and perhaps Opera. I am confident with this as it is right now, but we wouldn’t want to miss anything.
I changed the user guide page to use ‘discrete’ vice ‘discreet’. Good catch!
I’d like to see some of the others who were involved in this thread do some testing too since it seems they are likely using cookie helper…
I have added one more piece to this based on something I ran into with a custom session handler.
When deleting a cookie, it still exists in the $_COOKIE super global. I added an argument to delete_cookie() which defaults to TRUE. If it is set to TRUE, delete_cookie() calls for the cookie to be set to the browser with a negative expiration date AND it calls unset() on it in the $_COOKIE array.
If you were to want to hold that cookie value in the $_COOKIE array for some reason making it usable there until the script ends (and only until then because you are sending the negatively expiring cookie to the browser) you could set this flag to FALSE and it would not be explicitly unset() from $_COOKIE.
@JAAulde : That change looks fine to me, tests ok.
Can you confirm something for me please? Using the set_cookie / get_cookie, can you set a cookie where
the name contains spaces, eg ‘The Cookie Name’.
The cookie spec states that name=value must not contain spaces (among other things) and that it should
be encoded if needed. On my setup I get a PHP error as expected when setting a cookie like “Cookie Jar”.
What’s bugging me is some other strange things that are happening (nothing to do with your changes). But
I don’t want to go into all that until I’m sure of this behaviour.
Thanks, Oscar.
Oscar I will take a look at that. Cookies should definitely be encoded—I do that myself in my JavaScript Cookie Library. It will probably be Monday that I look more closely at it.
Ok, here is a question based on preference—please, everyone weigh in.
PHP has two methods of handling URL style encoding—urlencode() and rawurlencode(). These two are exactly the same in that they “return a string in which all non-alphanumeric characters except -_. have been replaced with a percent (%) sign followed by two hex digits” EXCEPT that the first translates spaces as ‘+’ whereas the second translates spaces as ‘’.
Points of discussion:
1) I would prefer we used rawurlencode(). While urlencode() more closely matches what a browser does with POSTed data, it is not what JavaScript does when escaping or encoding URI strings. Since many cookies are set via JavaScript, we would want to use an encoding/decoding method which will match its methods.
2) I would suggest we add the encoding to set_cookie() for all cookies being set via the cookie helper, as well as adding decoding to get_cookie() for all cookies being retrieved via the cookie helper. The logic here is that we are assuming someone who is getting cookies via the cookie helper is probably setting them via the cookie helper as well, so we would want to decode all cookies on retrieval.
I did not read that carefully enough
I’m probably doing something strange here.