Echec de la connexion dans Testlink - Enregistrement de la session/cookies

Question

Je rencontre des problèmes lors du déploiement de Testlink sur un serveur client. Il semble que l'origine du problème est que il n'est pas enregistrement/récupération d'informations dans la session correctement, et cela provoque des erreurs lors de l'installation et la tentative de journalisation.

Lors de l'installation, une variable est stockée en session (installationType) indiquant s'il s'agit d'une nouvelle installation ou d'une mise à niveau. Cette variable prend la valeur 'new', mais lorsque vous passez d'un écran à un autre, cette valeur est perdue, supposons que j'effectue une mise à niveau et qu'il est impossible de continuer. Comme une solution de contournement j'ai apporté des modifications au code pour définir cette variable à «nouveau» sur chaque écran et de cette façon j'ai terminé le processus d'installation correctement. Mais quand j'essaie de me connecter, je trouve un autre problème: après avoir entré les données utilisateur et accès, l'écran se rafraîchit et réaffiche l'écran de connexion sans aucun message d'erreur (en fait le journal montre que la connexion a réussi). Ce comportement est identique à la désactivation des cookies dans le navigateur.

La même version de Testlink (1.9.14) a été installé sans problème sur un serveur local avec une configuration identique:

• Ubuntu: 14.04.1 (64 bits)
• Apache: 2.4.7
• PHP 5.5.9-1ubuntu4.16
• MySQL: 5.5.49

La différence est que notre Ubuntu est monté sur une machine virtuelle dans Debian, et le client Ubuntu est déployé dans Azure.

J'ai comparé la configuration de php.ini sur une machine et une autre et je n'ai pas trouvé de différences significatives. En comparant les informations montré par phpinfo ni moi rien trouvé pertinent() (pourrait joindre les deux ici si nécessaire), mais je vois que dans la section « Variables PHP » du serveur local je ce cookie:

COOKIE [ "TESTLINKUSERAUTHCOOKIE"]

Ce cookie n'apparaît pas sur le serveur client (je suppose qu'il n'est pas créé après la connexion). Je suppose qu'il y a quelque chose dans le panneau d'administration Azure (auquel je n'ai pas accès) à configurer, de la même manière que l'ouverture d'un port doit être faite sur les iptables et sur Azure.

Toute suggestion serait grandement appréciée.

Answer 1

Les problèmes de session PHP sont généralement liés aux dossiers temporels utilisés par Apache/Php pour fonctionner.

Je suppose que Testlink implémente un système de session basé sur les cookies assez classique. Suivez cet article pour être sûr de bien configurer la gestion des sessions.

https://support.qualityunit.com/021373-How-To-Enable-Session-Support-for-PHP

Vous pouvez être également intéressé par ce lien.Il est un guide étape par étape sur l'installation sur la machine Testlink Azure:

http://thusharapriyantha.blogspot.com.es/2015/04/install-testlink-1913-stormbringer-in.html?m=1

Get Lucky ... Amitiés

Answer 2

Mystère résolu. Le problème n'était pas lié à Azure, mais avec la propre configuration du serveur.

Après avoir comparé tous les fichiers de configuration d'Apache et PHP contre une nouvelle installation, j'ai trouvé ceci:

/etc/apache2/sites-enabled/000 default.conf

<IfModule mod_headers.c> 
    Header set X-UA-Compatible "IE=edge" 
    Header set X-Frame-Options "DENY" 
    # Commented out, because fcm4 use external JavaScript 
    # Header set Content-Security-Policy "script-src 'self'; object-src 'self'" 
    Header always set Strict-Transport-Security "max-age=16070400; includeSubDomains" 
    Header set X-Content-Type-Options "nosniff" 
    Header set X-XSS-Protection "1; mode=block" 
    Header unset X-Powered-By 
    Header unset ETag 
    Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate" 
    Header set Pragma "no-cache" 
    Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT" 
    Header set X-Permitted-Cross-Domain-Policies "master-only" 
    Header edit Set-Cookie ^(.*)$ "$1;HttpOnly;Secure" 
    <FilesMatch "\.(appcache|atom|bbaw|bmp|crx|css|cur|eot|f4[abpv]|flv|geojson|gif|htc|ico|jpe?g|js|json(ld)?|m4[av]|manifest|map|mp4|oex|og[agv]|opus|otf|pdf|png|rdf|rss|safariextz|svgz?|swf|topojson|tt[cf]|txt|vcard|vcf|vtt|webapp|web[mp]|webmanifest|woff2?|xloc|xml|xpi)$"> 
     Header unset X-UA-Compatible 
     Header unset X-Frame-Options 
     Header unset Content-Security-Policy 
     Header unset X-XSS-Protection 
    </FilesMatch> 
</IfModule> 

Les lignes qui étaient à l'origine de ce comportement étaient les suivants:

• tête set-options X-Frame "DENY"
• tête modifier Set-Cookie^$ de (*). "1 $, HttpOnly, Secure"

Après commenté, tout ce qu'il est correct.