I was wondering if it's possible to delete a cookie in PHP, meaning re-setting it's time to a time in the past, for a specific subdomain from another subdomain.
For example:
say I am executing the following code on one.myserver.com, which is meant to delete a cookie on two.myserver.com
setcookie("ACOOKIE", 0, time() - 3600, "/", "two.myserver.com");
Currently doing it this way is not working for me. Is there any way I could get something like this to work?
Nope, you can only do that from the other subdomain.
You dont even know that they exist because they will only be sent(by the client browser) while accessing the domain where they were originally meant for.
Not possible. Cookies can only be set and unset from the same fully qualified domain.
Related
I need to set the PHPSESSID coockie for just two domains:
www.domain.tld
sub.domain.tld.
Other subdomains should not share the same PHPSESSID.
I can use session_set_cookies_param(), but as far as I can see, this can only set it for one domain or all subdomains.
But in my case, subdomain anothersub.domain.tld should not have this PHPSESSID.
I want this because we have images on a subdomain, and setting the PHPSESSID for all subdomains causes the browser to send the PHPSESSID cookie with the request. This has slight performance issues for static resources and it is recommended to use cookieless domains
This can't be done this way, this is unrelated to PHP. This is how cookies works in general. Only one domain (or a domain with a dot in front) can be set.
You have to use different domain for image hosting.
While as was already explained, this is not technically possible, due to the cookie “syntax”, I think you should be able to work around that, if you simply set a second cookie yourself.
Use session_set_cookies_param to have it set the cookie for www.domain.tld only.
Add your own code after session_start, that sets the “same” cookie again, just for sub.domain.tld this time.
session_name and session_id help your figure out the necessary name and value; if you want, you can also use session_get_cookie_params to match other parameters (like lifetime and maybe path, if the latter makes any sense in the given setup) as well if you like.
Edit: Keep in mind though, that if the session id might change at any other point within your app after session_start, for example if session_regenerate_id is used anywhere, you will of course have to update your second cookie there as well.
I'm trying to get Laravel 5.1 to delete my cookie, however it will not delete even though i'm returning it with my redirect.
return redirect('/voucher')->withCookie(Cookie::forget($cookie));
Have I done something wrong?
Maybe I am wrong, but you are probably using cookie object in place of cookie name when calling Cookie::forget($cookie). Unless $cookie is a string containing cookie name, you should try something like this:
return redirect('/voucher')->withCookie(Cookie::forget('cookie_name'));
I know this is already an old and answered question but I got here recently and if I'm correct, the cookie needs to be 'queued' for the next response.
You can do that by adding the cookie manually to the response as #Jan.J already described in his answer. But if you need to do it inline, this might also work for you:
Cookie::queue(
Cookie::forget('cookieName')
);
The CookieJar will pass all queued cookies to the next response.
In my case there was an array stored in the cookie, so none of provided methods has worked. Array should be deleted providing exactly pair of array:
Cookie::queue(Cookie::forget('array_name[provide_key]'));
First, make sure you've imported Cookie class with use keyword, like below :
use Cookie;
Next, create a function and delete a cookie by name
Cookie::queue(
Cookie::forget('cookie_name_first')
);
Cookie::queue(
Cookie::forget('cookie_name_second')
);
public function funname(CookieJar $cookie)
session()->flush();
$cookie->queue(cookie()->forget('user_email'));
$cookie->queue(cookie()->forget('user_password'));
return redirect('/');
Unfortunately none of the above worked for me, I'm not sure if it's a specific issue with this version of Laravel (5.1).
I did manage to get it working using raw PHP instead, by overwriting the existing cookie with an already expired one, I also had to specify a path to get this working. It's not as elegant as using a facade however.
setcookie('COOKIE_NAME', time() - 3600, '/');
You can also do it this way:
redirect('/')->cookie(cookie()->forget('my_super_cookie_name'));
Recently I faced this issue while still on localhost but the issue was that I have written some code which weren't normal in my process of trying to overwrite the session config file.
Therefore
The default laravel
Cookie::queue(
Cookie::forget('name')
) ;
Should work perfectly fine if you have not done any changes on your
session.php config file.
Check it out and you should be good to go.
If you have made some changes try to ensure that your code conforms to standard and everything should work fine.
Your code is perfect, so there's some other issue.
Cookies are tricky little ^##$$ and to make things worse are dependent on the client's implementation; various browsers may well handle cookie edge cases differently, or may even have had long-standing bugs relating to their cookie handling.
The "removal" of a cookie actually involves sending an update to the cookie but with an expiration date in the past. From RFC 6265:
Finally, to remove a cookie, the server returns a Set-Cookie header
with an expiration date in the past. The server will be successful
in removing the cookie only if the Path and the Domain attribute in
the Set-Cookie header match the values used when the cookie was
created.
If your Laravel code looks fine, as in the original question, I would suggest inspecting your cookies in your browser's dev tools. For example, Chrome's "Network" tab has a "Cookies" tab which shows you the Request Cookies and the Response Cookies. You may find there is a subtle difference between the original cookie and the cookie being sent to unset it. As per the RFC above, a difference in the domain (even just a leading dot) will break the cookie removal.
If I belong to the no-www camp, cookies I have set in http://example.com would be read by http://sub-domain.example.com,
And regardless of the language I use (perl / asp.net / php / JSP) there is no way I could ever work around this issue because it is a fundamental architecture of HTTP itself, true or false ?
What I'm concerned here is, is there any DNS config that would prevent http://sub-domain.example.com from reading the cookies set in http://example.com ?
I have a domain name http://qweop.com
I have a subdomain at http://sd.qweop.com
Now, the problem is that even though I've not set any cookies on http://sd.qweop.com, when I read the cookies, there are cookies there. They are reading cookies from http://qweop.com.
How do I fix the problem so that the cookies from the main domain would not be read by (a request to) the sub-domain?
I've tried altering the 5th parameter of the php setcookie function but it doesn't seem to do anything. Basically that parameter is like useless. I'm suspecting it's a limitation of the HTTP infrastructure.
DETAILS:
http://qweop.com/set.php (try to use incognito to allow easy cookie removal)
<?php setcookie("testcookie","testvalue",time()+60*60*24*30,"/","qweop.com");?>
cookies set
http://sd.qweop.com/read.php
<?php print_r($_COOKIE); ?>
// No one had set any cookies in http://sd.qweop.com but we can see cookies here! Error!
Answer: Yes
I had better catalog the answer here after 500 hours of google research.
Basically we should always use www if we're planning to use any other sub-domains and we want them cookie-free. This is because there are different browser behaviors with regards to top-level domain cookies.
We can try our best to tell the browser "Hey's set it to just the domain and not to it's sub-domains" but as long as the url is non-www, they won't be nice and behave the way we want them to.
In fact, even if the url is not non-www, they can still do whatever they want to, there is currently no record of any browser that does that (and most likely so too into the future).
I believe you cannot do anything about it. You might try to set the cookie as:
setcookie('some_name', 'some_val', 0, '/', 'yourdomain');
but it will be set to all subdomains of yourdomain even though RFC 2109 says if the cookie is to match the subdomains it should be set with a dot as .yourdomain. All major browsers are sending it to the subdomains. I checked it with IE, FF and Chrome.
Unfortunately, DNS config has absolutely nothing to do with cookies (as long as they belong to the same 2-nd level domain, of course).
You still can have a practical answer if you ask a practical question though.
I have been losing my session variables rather consistently when I click on the link from our websites notification email. After breaking my head for a long time on this, I today realized that www.domain-name.com does not contain the session variables while domain-name.com does!!
Why does this happen? And what do I do to set things right(php-apache)?
Sessions are based on cookies, which are per-domain.
www.domain.com is a different domain than domain.com, so their cookies are kept separate.
Standard practice is to choose one variant and 301 redirect the other variant to the preferred one.
The session ID is stored in a cookie, and in the cookie can be specified how it should react over domain names.
Take a look at PHP's setcookie documentation.
You can change PHP's session cookie configuration with:
ini_set("session.cookie_domain", ".mydomain.com");
There's nothing technically special about ‘www’. The domain ‘domain.com’ is distinct from ‘www.domain.com’; if you want to associate them, that needs to be explicit somewhere, usually in the HTTP server configuration.
How to redirect with .htaccess file:
http://papermashup.com/useful-htaccess-techniques/
http://perishablepress.com/press/2006/01/10/stupid-htaccess-tricks/#red2
I'm building an autologin system using cookies, but one fundamental part of the functionality of the cookies fails: they are non-persistent over different sessions - or even pages!
In my login script, I set the cookies like this:
setcookie('userID', $userID, time()+86400); // (edited after replies)
$userID has a value.
Then I print the $_COOKIE variable and it says array(['base_usid'] => 1); So that's good, but when I click the home page and print the $_COOKIE variable there, it says NULL.
Does anyone see the problem?
Cookies should have a time value for how long they should stay... Check http://php.net/manual/en/function.setcookie.php
In other words, change it to: setcookie('userID', $userID, time()+86400);
to make it stay for a day for example.
Aah, I've learned something new about cookies :) They have a path and they are only available on that path (the directory they were created in). I created the cookies on /user/login, and then tried to read them on /news/index. Won't work.
In the past I used to build websites with all files in just one folder (I know it's bad), so I didn't know of this cookie property. Sorry, I should have read the manual better...
Thanks for your help!
P.s.: Typing print_r($_COOOKIE); won't speed up debugging. :(
Cookies need an expiration time. Otherwise they are by default destroyed when a user closes his browser.
Try this instead
setcookie("userID", $userID, time()+3600);
This will last for an hour. Make the number bigger to have it last longer.
To unset / remove it, change the plus + to a minus -
:)
If its still not working after you've set an expiry time (and you've checked the clocks on server and client are correct) then have you checked that the cookie is being sent? Sounds like the problem with 'headers already sent'. Which would also imply you have a problem with error reporting / logging.
C.
Do you want to learn how to build CMS systems and login managers, or do you want to build an app... ?
Hate to do this, but my answer is : don't build your own login system. Instead, go grab some framework like CodeIgniter, Kohana, or even drupal or Joomla. If you are building a login system as a learning experience to understand how cookies work/etc, then fine.. go ahead.. as long as you don't plan on putting it into some production site. Otherwise, grab a well tested framework and use it.