Discussion :

[vg33]

J'ai un problème complexe pour lequel je cherche en vain une solution depuis 2 jours.
Je cherche à insérer une image dynamique générée avec Artichow dans un pdf généré avec FPDF.
J'ai donc une action display qui affiche un pdf ; dans sa vue, j'insère une image (méthode $fpdf::Image() ) pointant vers mon action graph (url absolue).
Le problème, c'est que je suis sur une application web sécurisée, avec authentification par serveur ldap distant en https. Et quand Fpdf appelle mon image (fopen), cela provoque une requête d'authentification vers le serveur ldap, ce qui bien entendu échoue. En effet, le serveur ne reconnait pas que je suis déjà authentifié.
C'est un problème de fopen, puisque la même action (url absolue ou relative) mais avec affichage à l'écran (donc sans fopen) fonctionne parfaitement.
Une idée ?

[mathieu]

si j'ai bien compris tes actions se passent comme ça :
image :
1) identification avec LDAP
2) génération de l'image
3) affichage de l'image
et pareil pour le PDF :
1) identification avec LDAP
2) génération du fichier PDF
3) affichage du fichier PDF

si c'est ça, pour ton image tu ne dois pas utiliser l'action en entier mais uniquement le code qui génère l'image (partie 2)) pour ensuite mettre le résultat dans un fichier temporaire, l'intégrer dans le PDF puis supprimer le fichier

[vg33]

si j'ai bien compris tes actions se passent comme ça :
image :
1) identification avec LDAP
2) génération de l'image
3) affichage de l'image
et pareil pour le PDF :
1) identification avec LDAP
2) génération du fichier PDF
3) affichage du fichier PDF

si c'est ça, pour ton image tu ne dois pas utiliser l'action en entier mais uniquement le code qui génère l'image (partie 2)) pour ensuite mettre le résultat dans un fichier temporaire, l'intégrer dans le PDF puis supprimer le fichier

Oui, c'est la méthode :
1) identification avec ldap (une seule fois pour toute la session)
2) stockage de l'identification en session
3) autant d'actions que je veux (tout se passe sans nouvel appel au serveur ldap)
4) génération du pdf
=> appel à fread() de l'image par FPDF
=> fread() ne reconnait pas que je suis déjà loggué (il démarre une nouvelle session)
=> renvoi vers le serveur ldap
=> échec de l'insertion de l'image.

Je me suis donc dis comme tu le suggères que j'enregistrerais les images dans des fichiers temporaires dans le répertoire web (non protégé par le ldap).
Je me heurte là à un casse-tête avec le contextSwitch. Mes images sont des png, j'utilise donc le contextSwitch.
Pas de problèmes pour un affichage à l'écran. Par exemple, si j'affiche 3 graphiques sur la même page XHTML dans des balises <img>, j'ai 3 appels à la vue graph.png.tpl
Mais dans mon pdf, c'est la cata :
1er appel en utilisant le viewHelper action => appelle le script de vue graph.png.pdf.tpl
2e appel => graph.png.png.pdf.tpl...
Et ainsi de suite !
Et si à la brute je crée les scripts de vue demandés, il me soulève une erreur plus loin encore plus incompréhensible : il ne trouve pas un viewHelper perso (forcément, il cherche dans le module courant alors que mes viewHelpers sont paramétrés dans le module par défaut), alors qu'une ligne avant, dans le même script, il trouve sans problème le viewHelper perso pourtant situé au même endroit !
Je m'arrache les cheveux depuis 2 jours !

Pour synthétiser, comment faire pour que fread tienne compte de la session en cours ?
Et je ne peux même pas suspendre provisoirement l'authentification pendant la génération du pdf, car c'est une nouvelle session qui a été démarrée...

[vg33]

J'ai trouvé une solution en passant par cUrl.
Problèmes : cUrl ne peut pas s'approprier la session d'un user => refus d'Apache qui à raison restreint l'accès de la session au navigateur de l'user. Or cUrl initialise une autre session comme un navigateur virtuel.
Voici la solution que j'ai trouvée (c'est complexe, mais je n'ai pas trouvé mieux ) :
Je crée une classe qui gère les sessions cUrl.
1) A l'instanciation, j'accède par cUrl à un script qui affecte à la session cUrl le contenu de la session de l'user connecté ; ce script est sécurisé par login/mdp inclus dans un fichier hors répertoire web.
2) Je peux ensuite appeler autant de fois que je veux curl_exec : mon applic croit que c'est l'user connecté (les infos de connexion sont en session).
3) Dès que j'ai fini avec cUrl, je clos la session cUrl => le cookie cUrl est automatiquement effacé.

Il ne me semble pas qu'il y ait une faille. En effet, si on attaque directement le script d'initialisation, il faut envoyer le bon login (40 caractères aléatoires) et le bon mot de passe (40 autres caractères aléatoires)... + un grain de sel aléatoire généré à chaque connexion et le tout hasché en md5... ainsi que les bonnes données de l'user...

[vg33]

Il n'empêche que ça n'explique pas les bizarreries de contextSwitch.

[SphynXz]

as tu essayé de regarder du coté de :

stream_context_create();

en créant un contexte pour ton fopen du style :

Code php :

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
$nom = "login";
$pass = "pass";
 
$auth = base64_encode("$nom:$pass");
$header = "Proxy-Authorization: Basic $auth";
 
$opts = array('http' =>
				array(
						   'proxy' => '',
 
							'header' => $header,
 
						   'request_fulluri' => True
				)
);
$context  = stream_context_create($opts);