Hallo allerseits. Erst kürzlich habe ich ein Thema eröffnet, um über UNIX-Timestamps zu diskutieren und war am Ende fest entschlossen diese zu vermeiden (Y2K38 betreffend). Nun habe ich beim durchforsten der php.de Seite festgestellt, dass beim Setzen eines Cookies beim dritten Parameter (expire) ein UNIX-Timestamp gefordert wird. Und jetzt bin ich deprimiert. Kann man das nicht normal mit Datumsangaben lösen? Oder wie machen die Experten unter euch das?
Ankündigung
Einklappen
Keine Ankündigung bisher.
[Erledigt] Cookie expire date
Einklappen
Neue Werbung 2019
Einklappen
X
-
Stichworte: -
-
Wo ist das Problem? Deine Cookies werden sowieso keine 25 Jahre lang überleben. Und auch sonst können Cookies ja jederzeit gelöscht werden, sodass du dich nicht darauf verlassen kannst das welche da sind.
Verstehe die Problematik nicht.
-
Phpyton
Ja wenn ich schon davon weiss, dann bau ich doch die Applikation gleich so, dass sie zukunftssicher ist, indem ich UNIX time so gut es geht vermeide. Ausserdem nur ein theoretisches Gedankenspiel: Angenommen wir sind ein paar Jährchen in der Zukunft. Und dann läuft der Code unserer Freunde so weiter wie er heute läuft, dann erleben wir Chaos pur. Ich kenne genug, die frohen Mutes den expire ihres cookies auf 10 Jahre setzen und nicht wissen, was ab 2038 los ist. Ausserdem spricht Wikipedia (ob übertrieben oder nicht kann ich nicht beurteilen) vom Ausfall sämtlicher Haushaltsgeräte, die mit UNIX Zeit funktionieren ab dato.
Kommentar
-
1. Das Jahr 2038 ist ein Problem von 32-Bit Systemen. Ich denke das wir in 25 Jahren davon nicht mehr viele sehen werden.
2. Wenn du glaubst das deine Anwendung 25 Jahre unverändert übersteht lebst du weit weg von der Realität. Vor 25 Jahren gabs PHP noch nicht mal, und ich behaupte in den nächsten 25 Jahren wird sich da ähnlich viel tun.
Kommentar
-
Phpyton
Ich sprach davon, dass, wenn man mit UNIX Zeit seinen Cookie expire übertrieben gesagt auf 100 Jahre setzen würde, man schon Probleme erleben würde. Und sowas darf nicht sein. Und mir mangelnden Realitätsbezug zu unterstellen können wir als zivilisierte Leute gerne unterlassen. Ich schreibe nach bestem Wissen und Gewissem und versuche dir respektvoll gegenüberzutreten.
Kommentar
-
Wie gesagt, das ist theoretische Haltbarkeit. Das ist genauso als hättest du 100 Jahre Mindesthaltbarkeit auf Gummibärchen - bis dahin hast du doch ohnehin längst alle aufgegessen, also kann dir egal sein was in 100 Jahren mit denen passieren würde.
Kommentar
-
Phpyton
Ich würde gern hören, was Tr0y dazu sagt. Dann kann ich sicher sein, nicht das Falsche zu tun.
@Tropi: Dann müsstest du in deinem Vergleich allerdings auch der Vollständigkeit halber ergänzen, dass alle Gummibärchen, die nach 2038 produziert werden, automatisch ungenießbar sind.
Kommentar
-
-
Phpyton
Ich würde aber gern jetzt wissen, wie ich optimal verfahren muss. So lange kann ich nicht warten.
Kommentar
-
RFC: http://tools.ietf.org/html/rfc6265
Header Field Value zusammen bauen: https://github.com/symfony/HttpFound...Cookie.php#L82
Bei dem konkreten Cookie-Objekt von Symfony:
Das Objekt müsstest du aber auf DateTime umbauen.PHP-Code:header('Set-Cookie: '.((string) $cookieObject), false, 200);
Kann dann so aussehen:
Symfony Response
Symfony Cookie:PHP-Code:public function sendHeaders()
{
if ( headers_sent() ) {
return $this;
}
// status
header(sprintf('HTTP/%s %s %s', $this->version, $this->statusCode, $this->statusText), true, $this->statusCode);
// headers
foreach ( $this->headers->allPreserveCase() as $name => $values ) {
foreach ( $values as $value ) {
header(sprintf('%s: %s', $name, $value), false, $this->statusCode);
}
}
// cookies
foreach ( $this->headers->getCookies() as $cookie ) {
header('Set-Cookie: '.((string) $cookie), false, $this->statusCode);
}
return $this;
}
Reicht dir das als Beispiel ?PHP-Code:public function __construct($name, $value = null, $expire = 0, $path = '/', $domain = null, $secure = false, $httpOnly = true)
{
if ( preg_match("/[=,; \t\r\n\013\014]/", $name) ) {
throw new \InvalidArgumentException(
sprintf('The cookie name "%s" contains invalid characters.', $name)
);
}
if ( empty($name) ) {
throw new InvalidArgumentException(
'The cookie name cannot be empty.'
);
}
if ( $expire === 0 ) {
$expire = null;
}
else if ( ! $expire instanceof \DateTime && ! is_numeric($expire) ) {
$expire = date_create($expire);
if ( false === $expire ) {
throw new \InvalidArgumentException('The cookie expiration time is not valid.');
}
}
else if ( ! $expire instanceof \DateTime && is_numeric($expire) ) {
$expire = date_create_from_format('U', $expire);
}
$this->name = $name;
$this->value = $value;
$this->domain = $domain;
$this->expire = $expire;
$this->path = empty($path) ? '/' : $path;
$this->secure = (bool) $secure;
$this->httpOnly = (bool) $httpOnly;
}
public function getExpiresTime()
{
throw new \LogicException('This Cookie is not compatible with unix time based cookies');
}
public function getExpiresDateTime()
{
return $this->expire;
}
public function isCleared()
{
return $this->expire < date_create();
}
public function __toString()
{
$str = urlencode($this->getName()).'=';
if ( '' === (string) $this->getValue() ) {
$str .= 'deleted; expires ='.date_create('-1 year')->format(\DateTime::RFC1123);
}
else {
$str .= urlencode($this->getValue());
if ( $this->getExpiresDateTime() instanceof \DateTime ) {
$str .= '; expires='.$this->getExpiresDateTime()->format(\DateTime::RFC1123);
}
}
if ( $this->path ) {
$str .= '; path='.$this->path;
}
if ( $this->getDomain() ) {
$str .= '; domain='.$this->getDomain();
}
if ( true === $this->isSecure() ) {
$str .= '; secure';
}
if ( true === $this->isHttpOnly() ) {
$str .= '; httponly';
}
return $str;
}
Ist soweit auch Laravel-Kompatibel.
Kommentar
-
Phpyton -
Ich hab das grad mal durchgetestet, Die Cookie-Klassen-Modifikation verwendet ein Falsches Datums-Format, ich besser das grad mal aus.
Man soll es nicht glauben aber das Format hinter COOKIE ist nicht RFC-treu und funktioniert nicht, das Format der Konstante RFC1123 allerdings schon ( wie auch in der RFC angegeben ).
Kommentar

Kommentar