Discussion :

[Neilime05]

Bonjour,

J'ai une application X qui effectue des requêtes Ajax (JSONP) sur une autre application Y (domaine différent) .

La première requête ajax (JSONP) envoyée par X permet de s'identifier. En retour, Y retourne l'id de la session session_id();

Ensuite toutes les requêtes envoyé par X (toutes les heures) ont en paramètre l'id de la session.

Voilà le code coté Y : (j'ai mis en place cette procédure pour éviter les problèmes de cross domain et Internet Explorer)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?php
 
//Fichier appelé par la requête ajax (JSONP)
 
if(!isset($_GET['session_id'])){
    //On régénère la session
    session_regenerate_id(true);
 
    //On démarre la session
    session_start();
}
else{
    session_id($_GET['session_id']);
    session_start();
    if(!isset($_SESSION['APP_Y'])){
        error_log('APP_Y : Session Invalide');
        die();
    }
}
 
?>

Cependant, de temps en temps j'ai des erreurs log 'APP_Y : Session Invalide',
mais les fichier de session sont existant sur le serveur.

Je ne comprend vraiment pas pourquoi, de plus que ces erreurs erreur apparaissent pour n'importe quel navigateur, à n'importe quelle heure.
Je précise que les requêtes Ajax sont envoyées toutes les heure, donc théoriquement la session ne doit pas être expirée (valeur par défaut d'expiration à 180min).

Voilà la problématique, si quelqu'un à une idée sur son origine, je suis preneur.

Merci d'avance pour les réponses.

[guigo]

Salut,
effectivement si tu lui passe l'id de la session en cours il n'y a pas de raison que ca ne marche pas. Essaye un phpinfo() pour confimer ton php.ini.
As tu rebooter ton serveur apache ?
es tu sur qu'il faille un session_start apres session_id($_GET['session_id']);
Quand tu fait des echo de ton session_id tu as bien les identifiants=id de session stocke sur ton serveur (meme au moment ou ca plante )?

Guigo

[RunCodePhp]

Salut

Regarde au niveau de la doc pour la fonction session_regenerate_id, l'exemple de code fourni.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
//Fichier appelé par la requête ajax (JSONP)
 
if(!isset($_GET['session_id'])){
    ... etc ...
}
else{
    session_id($_GET['session_id']);
}

Théoriquement, tu ne peux pas procéder ainsi.
Il faudrait en 1er démarrer la session, donc session_start(), car le tableau $_SESSION (et ses données) sera dispo qu'après avoir démarrer la session justement, et c'est la même chose pour régénérer un nouvel identifiant, il pourra être changé qu'après démarrage de la session.


Ensuite, ça dépend de ce que tu veux faire, mais ré-initialiser par exemple l'ID de session avec $_GET['session_id'], c'est théoriquement un trou de sécurité, car quelque part, n'importe qui aura l'occasion de pointer vers ce fichier en rajoutant en paramètre un "session_id", donc de potentiellement récupérer une session d'une autre personne.

C'est théoriquement plus simple que ça, il suffit de démarrer la session, et théoriquement, si une session existe, l'ID de session sera la bonne.
Bon, on peu toujours renforcer tout ça, mais c'est un autre débat.


Théoriquement, toujours, on n'a pas besoin de transmettre l'ID de session, normalement il est déjà transmit dans l'entête, c'est le cookie, il fait partie de la requête HTTP, et c'est justement sa valeur (son ID) qui doit correspondre à un fichier de session coté serveur.
Si l'un des 2 est manquant, ou erroné, ou encore expirée, lors du session_start(), une nouvelle session sera accordée, et c'est là qu'il y aura perte de session.


En résumer, ceci seulement devrait fonctionner :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
session_start();
 
if (isset($_SESSION['APP_Y'])) {
    // A voir s'il est nécessaire de régénérer l'ID de session
}
else {
    // ERREUR
}

[Neilime05]

Théoriquement, toujours, on n'a pas besoin de transmettre l'ID de session, normalement il est déjà transmit dans l'entête, c'est le cookie, il fait partie de la requête HTTP, et c'est justement sa valeur (son ID) qui doit correspondre à un fichier de session coté serveur.

Le problème est que ce n'est pas toujours le cas... Internet Explorer par exemple, en Cross Domain, ne passe pas l'identifiant de la session via l'entête HTTP.

C'est pour ça que j'ai mis en place ce script. Pour pouvoir récupérer la session même si celle-ci n'est pas spécifier par le header de la requête http.

[RunCodePhp]

Le problème est que ce n'est pas toujours le cas... Internet Explorer par exemple, en Cross Domain, ne passe pas l'identifiant de la session via l'entête HTTP.

Tu est sûr que que tu te trouve dans un cas de cross domaine, qui veut dire qu'on interroge un domaine (ou serveur) B alors que l'origine de la requête HTTP vient d'un domaine A ?
Est ce vraiment le cas ? (j'ai plutôt tendance à dire que non).

Si c'est le cas, et bien la perte de session devrait être systématique quelque soit le navigateur, pas seulement d'Internet Explorer, car théoriquement, quand on intérrogera pour la 1ère fois le domaine B (1ère requête HTTP), la session n'aura pas encore été créé, donc le cookie envoyé (du domaine A) ne correspondra jamais à une session du domaine B.
Une nouvelle session sera automatiquement accordée, du coup, une incohérence existera entre les 2 domaines au niveau des sessions.
Enfin, c'est ainsi que je le perçois, je peux me tromper.


Ce ne serait pas dû au format JSON plutôt ?
As tu essayé de rajouter la valeur du cookie de session dans le JSON par exemple ?
J'ai jamais eu l'occasion de faire des essai en JSON malheureusement (un de ces 4 faudrait que j'essaye d'ailleurs), je ne pourrais en dire plus.
As tu fais des essai sur IE justement mais pas au format JSON, un simple fichier php qui retournerai un echo, et regarder si la session est conservée, est la même?

En faite ici, la question que je me pose, c'est est ce qu'il ne serait pas nécessaire de définir le type/format de fichier qu'on a affaire, soit du JSON dans l'entête, faire un header('... je ne sais pas trop quoi ... /json') avant de démarrer la session.
Fausse piste peut être, mais c'est on jamais.


Ou alors, il faudrait peut être voir comment le cookie est créé, à quel domaine domaine il appartient, son chemin plus exactement, etc ...
Tu peux le vérifier du coté du ou des navigateurs que tu utilise.

[Neilime05]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Tu est sûr que que tu te trouve dans un cas de cross domaine, qui veut dire qu'on interroge un domaine (ou serveur) B alors que l'origine de la requête HTTP vient d'un domaine A ?

Oui les requêtes sont effectuées à travers deux domaines différents...

Je re-explique le problème, la première requête (App X domaine A) sert à instancier la session sur l'app Y (domaine B).

Ensuite les requêtes effectuée depuis l'app X (toutes les heures), sont censées utiliser la session instanciée lors de la première requête.

Le problème est qu'IE ne passe passe pas l'identifiant de la session naturellement, il faut donc le préciser.