Portail sur session

Bonsoir.
Tu devrais vérifier ta condition, elle n'est pas correcte.
Ensuite, je suppose que tu voulais dire CloudFlare, mais je ne vois pas le rapport entre ce que tu veux faire et le site de CloudFlare.

Bonsoir,
oui cloudfare, en gros c'est juste pour faire un genre de portail toutes les heures ^^
ma condition n'est pas bonne? :o

ma condition n'est pas bonne? :o

Non, car voilà la traduction partielle de ta condition :
Si le cookie nommé protection existe, tu définis le cookie nommé protection avec sa valeur NULL et tu fais un die de cookie mis ;), sinon (si le cookie nommé protection n'existe pas) tu fais un die de cookie déjà mis.
Ce ne serait pas plutôt l'inverse que tu devrais faire ?
Définir le cookie seulement s'il n'existe pas ?

En gros j'aimerais que si la personne est jamais venu sur le site, ça lui met le cookie comme quoi il déjà visiter le site

Depuis la documentation de PHP : isset — Détermine si une variable est définie et est différente de NULL.

@flan, oui je sais, de quoi veut tu en venir?

Au fait que tu donnes NULL comme valeur à ton cookie et que donc le isset ne fait pas ce que tu veux. Utilise array_key_exists, par exemple. Et dans tous les cas ta condition est inversée.

Note qu'un cookie peut se modifier / effacer par l'utilisateur, tu devrais en avoir conscience pour ton histoire de portail.

Je vois enfin, ou vous voulez en venir, j'ai utiliser les sessions ça marche niquel. Mais comment je pourrais supprimer $_SESSION['protection'] au bout d'une heure? merci

@flan,
tu dis

En stockant la date de création de la session justement dans la session et en vérifiant si cette valeur date d'il y a plus d'une heure

une question bête comme ça : tu stocks bien la date de création de la session côté serveur ?
Si je comprends bien, lors d'une création de session, tu récupères sur le serveur en bdd la session_id() du client et tu l'associe à sa date de création de session ̀$birth_date_session = new DateTime(); echo $_SESSION['birth_timestamp_session'] = $birth_date_session->getTimestamp();
Du coup lors d'une vérification de validité de session,

// on effectue au préalable une vérification d'id de session puis on peu vérifier le temps de validation :
$date_verif = new DateTime();
if ($date_verif >= $_SESSION['birth_timestamp_session] + 3600 {
    // on clos la session ou on fait ce que l'on veut !
}

Qu'en penses tu ?

Bonjour.

Si je comprends bien, lors d'une création de session, tu récupères sur le serveur en bdd

Pourquoi en base de données ?
Ce n'est pas nécessaire de stocker la session en base de données.

@Lartak

Ce n'est pas nécessaire de stocker la session en base de données.

et en cas d'artak ?
Imaginons que le pirate prenne un id de session et avec une valeur de vérification de date de création de session valide, ne pourra t'il pas réussir son attaque ?

EDIT :
En fait, ça n'a pas de sens ce que j'raconte puisque j'imagine (si quelqu'un pouvait me le confirmer avec arguments, ce serait sympa) qu'un id de session qui n'a pas été créé par le serveur ne peut pas être valide !?

session côté serveur

Les variables de session sont forcément côté serveur, sauf dans le cas d'un JWT ou d'une implémentation vraiment exotique.

Imaginons que le pirate prenne un id de session et avec une valeur de vérification de date de création de session valide, ne pourra t'il pas réussir son attaque ?

Cette valeur est stockée côté serveur, il ne peut donc pas y avoir accès (sauf dans les cas que j'ai évoqué ci-dessus). Il peut juste tenter des id de session différents jusqu'à en trouver un avec une date valide (ou le voler par XSS). Des cookies en httpOnly et une vérification de l'adresse IP liée à la session devrait permettre de pallier simplement à ces deux problématiques (dernière solution un peu pénible pour certains utilisateurs).

Un identifiant de session qui n'a pas été créé par le serveur est valide, mais dans tous les cas la personne ne peut pas contôler les valeurs stockées dans la session.
Si une personne a le même cookie (identifiant) de de session qu'une autre personne (après une XSS, avoir eu accès à son ordinateur, ou bien même par « chance »), elle peut se faire passer pour la seconde personne.
La session peut être stockée dans la base de données si tu le souhaites, par défaut PHP utilise des fichiers (cf https://github.com/sprain/PHP-MySQL-Session-Handler), mais tu n'as pas d'intérêt de mêler les deux techniques.

Merci flan d'éclairer ma lanterne.

Donc, lors de la création d'une session, un id est stocké sur le serveur, mais également dans le cookie de l'utilisateur afin que le serveur puisse faire le lien entre lui même et le client.
Dans le cas où du côté client, les cookies ne soient pas acceptés, est il possible de créer une session via session_start() ?

Donc, lors de la création d'une session, un id est stocké sur le serveur, mais également dans le cookie de l'utilisateur afin que le serveur puisse faire le lien entre lui même et le client.

C'est bien ça ! Sur la configuration par défaut, un fichier comprenant l'identifiant de session dans son nom est créé et cet identitant est donné dans le cookie PHPSESSID. Le client va joindre le cookie à chaque requête HTTP vers ce domaine (via les en-têtes) et le serveur pourra ainsi récupérer l'ensembles des valeurs de la session de l'utilisateur.

Si les cookies ne sont pas acceptés, il est toujours possible de gérer les sessions comme d'habitude, mais l'attribut PHPSESSID sera passé dans chaque URL pour pouvoir propager l'identifiant de session entre les différentes requêtes vers le domaine. Mais ça n'est vraiment pas très pratique, et si l'utilisateur a choisi de désactiver les cookies, c'est sûrement pour une bonne raison !

Ah mais oui, on peu comme tu le dis, toujours passer un identifiant par l'url, mais pour éviter cela, les sessions furent sortie d'un esprit vertueux :D !

Merci bien l'ami de ton éclairage qui me guide dans cette obscurité binaire.