Asked  7 Months ago    Answers:  5   Viewed   207 times

I must be missing some basic thing about cookies. On localhost, when I set a cookie on server side and specify the domain explicitly as localhost (or .localhost). the cookie does not seem to be accepted by some browsers.

Firefox 3.5: I checked the HTTP request in Firebug. What I see is:

Set-Cookie:
    name=value;
    domain=localhost;
    expires=Thu, 16-Jul-2009 21:25:05 GMT;
    path=/

or (when I set the domain to .localhost):

Set-Cookie:
    name=value;
    domain=.localhost;
    expires=Thu, 16-Jul-2009 21:25:05 GMT;
    path=/

In either case, the cookie is not stored.

IE8: I did not use any extra tool, but the cookie does not seem to be stored as well, because it’s not being sent back in subsequent requests.

Opera 9.64: Both localhost and .localhost work, but when I check the list of cookies in Preferences, the domain is set to localhost.local even though it’s listed under localhost (in the list grouping).

Safari 4: Both localhost and .localhost work, but they are always listed as .localhost in Preferences. On the other hand, a cookie without an explicit domain, it being shown as just localhost (no dot).

What is the problem with localhost? Because of such a number of inconsistencies, there must be some special rules involving localhost. Also, it’s not completely clear to me why domains must be prefixed by a dot? RFC 2109 explicitly states that:

The value for the Domain attribute contains no embedded dots or does not start with a dot.

Why? The document indicates that it has to do something with security. I have to admit that I have not read the entire specification (may do it later), but it sounds a bit strange. Based on this, setting cookies on localhost would be impossible.

 Answers

10

By design, domain names must have at least two dots; otherwise the browser will consider them invalid. (See reference on http://curl.haxx.se/rfc/cookie_spec.html)

When working on localhost, the cookie domain must be omitted entirely. You should not set it to "" or NULL or FALSE instead of "localhost". It is not enough.

For PHP, see comments on http://php.net/manual/en/function.setcookie.php#73107.

If working with the Java Servlet API, don't call the cookie.setDomain("...") method at all.

Tuesday, June 1, 2021
 
Smandoli
answered 7 Months ago
91

You're supposed to give a UNIX timestamp of when the cookie will expired (calculated since the epoch) as the third argument to the function call.

The time the cookie expires. This is a Unix timestamp so is in number of seconds since the epoch. In other words, you'll most likely set this with the time() function plus the number of seconds before you want it to expire. Or you might use mktime(). time()+60*60*24*30 will set the cookie to expire in 30 days. If set to 0, or omitted, the cookie will expire at the end of the session (when the browser closes).

I suggest you read the documentation for setcookie.

Saturday, May 29, 2021
 
samayo
answered 7 Months ago
76

Make sure you have a domain that is known by both server and client. echo $_SERVER['HTTP_HOST'] should tell you the exact same domain that your browser has. If not, cookie will not be accepted by the browser.

Make sure your server and client time is perfectly correct. Browser will reject a cookie with a wrong datetime.

Do not write any other code and just do:

<?php
$cookie_name = "user";
$cookie_value = "John Doe";
setcookie($cookie_name, $cookie_value, time() + (86400 * 30), "/"); // 86400 = 1 day 
// expiration
echo date("H:i:s d.m.Y")."<br>";
echo $_SERVER['HTTP_HOST']."<br>";
var_dump($_COOKIE);
?>

and refresh the page twice.

Also check out manual at: https://www.php.net/manual/en/features.cookies.php

Saturday, May 29, 2021
 
mattltm
answered 7 Months ago
11

@WilliamBZA's suggestion helped solve the initial problem, but then signout/session timeout bug that results in the cookie creating an implicit domain cookie has made me come to the conclusion that the solution is...

Don't use Explicit cookies in .NET... ever

There are far too many problems, sure they can be solved by being explicit on the Form/Domain, Cookie/Domain, etc. To ensure that the correct domain is used everywhere. But if your application hosts multiple domains or is multi tenant, then it just becomes too problematic.

Lesson is learnt. Don't use explicit cookies.

Tuesday, July 13, 2021
 
jedwards
answered 5 Months ago
67

The main difference is that when you use cookie[:foo] = 'bar' the user is able to see the value for the cookie, i.e. 'bar'. When you use session[:foo] = 'bar' the value will be encrypted by rails and stored in the _myapp_session cookie.

You would use the cookie[] format when the information you want to store is not bound to the session, e.g. when the users selects the preferred language.

You would use the session[] format when you want to store information that is related to the current session, e.g. the id of the the user.

Friday, September 3, 2021
 
Ramazan Polat
answered 3 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :  
Share