setcookie ($name, $value, $expire, $path, $domain, $secure, $httponly)
If $path is set to “/directory/”, the cookie is only available here:
If $path is set to “/”, the cookie is good for the entire domain.
However, if $path is “”, the cookie is set for the current directory.
How do I set the path so that it’s good for
but not
if I can’t use “” (because it becomes “/”) or “/”?
You can’t set a cookie for a path and NOT its sub paths, exclusions like this don’t work.
That’s what I thought. Is there any workaround, like some way of knowing what path was set for the cookie? I mean, if I read the cookie from a script at
can I know that it was set for “/”?
You can’t pick and chose where to read cookies from, they are sent by the browser automatically. Very much a “you get what you are given” thing, you can control what you are given by setting paths / domains but not exclude or pick alternates.
I think your only option is to use sub-domain instead of directory for controlling where cookies have effect.
Ah, but if I knew that the cookie was set for “/” and not “/directory/”, I could ignore the cookie value in “/directory/”. Probably not a big deal, but my users need to know this side effect of installing the script in multiple directories in a single domain.
Good point, lampcms.com – that would be one workaround. (BTW, your server seems to be down.)
you dont’ know where a cookie is set for in the data that is returned - you only get the name and data, its up to the browser to gather the required cookies and and send them to the server.
Yes, the links in my signature are dead. I used to have this open source CMS, but it was never popular, so I stopped doing it, admitted it was a mistake to use XSLT as templating engine (it is cool, produces 100% valid html all the time, I still like XSLT, but in php it is slow or at least slower than other alternatives, it also has learning curve and most developers don’t want to learn XSLT scripting)
I have just started a new more interesting project which I will soon put up on lampcms.com, so that name and domain will be reused but the project is totally new - its an open source Stackoverlow-like Q/A site in php and mongodb, very fast and cool, using latest and greatest php 5.3 features like closures based Registry/Singleton pattern, new templating engine I wrote, very simple and fast for php, YUI3 for js library, use of namespaces and of cause many of the best features I wrote for Lampcms made it to the new project.
I just signed for github account, starting to put everything together to release beta.
Anyway, that’s the reason I keep my signature, it will be live soon.
If anyone is interested to join as developer, drop me a DM.
Still thinking out loud here: I usually use “.example.com” as the domain for a cookie, so that “www” and non-“www” URLs use the same cookie. That’s going to give me the same problem for sub-domains, isn’t it?
Well, you just have to use it differently and use specific sub-domain cookies instead of .example.com
Why do you need such a broad catch-all cookie coverage?
Actually, it’s the catch-all that I don’t want. It’s e-commerce software that handles sales and delievery of a single product. The user could install the software in multiple directories for multiple products.
There’s an affiliate program built in; the affiliates use a link that could have “www” prepended or not, so the software simple uses “.example.com” as the domain instead of "example.com.
If the user installs in “/” and in “/directory/”, an affiliate could get credit for sales of the product at “/directory/” if the vistor first went to “/”. Although some users may like that, that’s not the intended behavior – unless the affiliate directly refers a product, the software pays the user.
So, the cookie is path specific, unless the user installs in “/” – and then the affiliate cookie is global.
And, again, the use of “.example.com” is so the affiliate gets the credit for the product sale whether or not they use “www” in the link.
I guess the thing to do is add the caveat for my users: if you’ve got multiple products and install at root, your affiliates will get a global cookie until someone else refers the visitor directly to another product.
What you should be doing then, maybe, is setting a cookie and an ‘entry point’ in a local database, and working with that as the start of that cookie, rather than trying to rely on where the cookie is set - that way you can use one single global identifying cookie and still know where the affiliate credit should go.
Think about solving the problem another way.
Thanks, Tim. Although that complicates this product, it’s something I’ll do for another.