PC SOFT

FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile

|
|
|
FR
Accueil → WEBDEV 2025 → Site en mode session ne fonctionne pas
Site en mode session ne fonctionne pas
Débuté par Luc Rollinger, 22 juil. 2025 13:40 - 1 réponse
#1
Posté le 22 juillet 2025 - 13:40
Bonjour à tous,

J’ai un problème avec un site en mode session, qui une fois déployé sur le serveur de production ne fonctionne plus.
Pourtant tout fonctionne nickel sur mon poste de développement.
Le site est développé avec une version 2024, aussi sur mon poste que sur le serveur (Kalanda) les versions sont les même.
Les symptômes sont les suivants :
Après authentification, la page affichée proposent, entre autre, un menu. Lorsqu’on choisit l’une des options du menu, cela réaffiche la même page, mais avec un paramètre dont la valeur diffère pour que la page affiche une une page interne. Hors rien ne fonctionne sur le serveur, c’est toujours la même page interne qui est affichée.
Pourtant, le site utilise plusieurs variables, déclarées en synchronisation navigateur, mais rien n’est gardé dans ces valeurs. Et pourtant, en local, aucun problème.
J’ai regardé sur le serveur IIS, aucune différence entre la déclaration de ce site et un autre sur le même serveur.
J’ai passé une partie de la matinée au téléphone avec Kalanda, on a activé les logs, et aucune erreur n’est générée. Ils n’arrivent pas à comprendre.

Est-ce que quelqu’un aurait déjà rencontré ce genre de problème, et aurait une solution pour le résoudre ?
Ou, est-ce que quelqu’un aurait tout simplement une idée?

Merci à tous, d’avance, pour vos interventions.

Cordialement,
Luc Rol’inger
#2
Posté le 23 juillet 2025 - 13:03
Bonjour Luc,

Il est effectivement frustrant de rencontrer ce genre de problème où tout fonctionne parfaitement en développement mais pas en production, surtout sans erreurs dans les logs. Ce scénario pointe souvent vers des différences subtiles dans l'environnement ou la configuration.

Pistes de diagnostic et solutions potentielles
Voici quelques pistes basées sur les symptômes que vous décrivez (problèmes de session, variables non conservées) et des expériences similaires avec les déploiements :

Gestion des sessions :

État de session sur IIS : Même si vous avez vérifié la déclaration du site, assurez-vous que la gestion de l'état de session est correctement configurée sur votre IIS de production. Vérifiez le mode de session (InProc, StateServer, SQLServer). Si vous utilisez InProc (par défaut), un redémarrage du pool d'applications ou de l'application elle-même peut effacer les sessions. Si vous avez plusieurs serveurs web (ferme de serveurs), InProc ne fonctionnera pas correctement sans une solution de session partagée.

Permissions du répertoire temporaire de session : Le compte sous lequel votre pool d'applications IIS s'exécute doit avoir les permissions nécessaires (lecture/écriture) sur le dossier où les sessions sont stockées temporairement. Par défaut, il s'agit souvent d'un dossier sous C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files (ou similaire, selon votre version de .NET et architecture). Une restriction de permission peut empêcher la conservation des données de session.

Variables "Synchronisation Navigateur" : https://www.mycard-statement.com

Le fait que vos variables déclarées en "synchronisation navigateur" ne conservent pas leurs valeurs est un symptôme clé. Ces variables sont généralement gérées côté client (navigateur) ou dépendent de la session côté serveur.

Cookies : Les sessions s'appuient souvent sur des cookies. Vérifiez que les cookies de session sont bien émis par le serveur de production et acceptés par le navigateur.

Utilisez les outils de développement de votre navigateur (onglet "Application" ou "Stockage") pour inspecter les cookies après l'authentification et après avoir cliqué sur un élément du menu. Vérifiez si le cookie de session (généralement ASP.NET_SessionId ou similaire) est présent, s'il a une date d'expiration appropriée (pas expiré immédiatement), si son domaine et son chemin sont corrects, et si le flag Secure ou HttpOnly ne pose pas de problème inattendu (bien que moins probable pour ce type de symptôme).

Chemin de l'application dans IIS : Assurez-vous que le chemin virtuel de votre application IIS correspond bien à ce que votre application attend. Si l'application pense être à la racine mais est déployée dans un sous-répertoire virtuel, cela peut perturber les chemins des cookies et d'autres ressources.

Différences entre environnement de développement et de production :

Configuration Web.config : Bien que vous ayez mentionné que les versions sont les mêmes, y a-t-il des différences dans le fichier web.config entre votre environnement de développement et de production ?

Examinez les sections <sessionState>, <httpCookies>, et <machineKey>. Une <machineKey> différente peut causer des problèmes de déchiffrement des données de session ou d'authentification si elles sont partagées ou si l'application s'attend à une clé spécifique.

Vérifiez également les balises <compilation debug="true"> en développement vs. debug="false" en production. Bien que ce ne soit pas la cause directe, un mode debug désactivé peut parfois masquer des erreurs silencieuses.

Modules et Handlers IIS : Assurez-vous que tous les modules et handlers ASP.NET nécessaires sont activés sur IIS production. Il arrive qu'un module manquant (par exemple, pour la gestion des sessions) puisse provoquer des comportements inattendus.

Problèmes de cache : Parfois, un cache agressif côté serveur (IIS Output Caching) ou côté client peut faire que la page ne se rafraîchit pas correctement. Moins probable si les variables ne sont pas conservées, mais à vérifier.

URL Rewriting / Redirections : Si vous utilisez des règles de réécriture d'URL ou des redirections, assurez-vous qu'elles ne modifient pas involontairement les paramètres d'URL ou qu'elles ne causent pas une perte de contexte de session.

Prochaines étapes suggérées
Reproduire le problème avec les outils de développement du navigateur : La première étape la plus cruciale est d'utiliser les outils de développement de votre navigateur (F12 dans Chrome/Firefox/Edge) sur le site en production.

Allez dans l'onglet Network (Réseau).

Décochez "Disable cache" (ou "Désactiver le cache").

Reproduisez le scénario : authentification, puis clic sur l'option de menu.

Analysez la séquence des requêtes :

Quels sont les paramètres envoyés dans l'URL ou le corps de la requête après le clic sur le menu ?

Quelles sont les réponses du serveur (codes HTTP 200, 302, etc.) ? Y a-t-il des redirections inattendues ?

Examinez les en-têtes de requête et de réponse, en particulier les en-têtes liés aux cookies (Set-Cookie dans la réponse, Cookie dans la requête).

Ajouter de la journalisation granulaire : Puisque les logs actuels ne montrent rien, essayez d'ajouter une journalisation très spécifique à votre code pour tracer la valeur de vos variables "synchronisation navigateur" et l'état de la session à des points clés du cycle de vie de la requête (par exemple, au début de la page, après la récupération des paramètres, avant l'affichage). Écrivez ces informations dans un fichier texte sur le serveur, cela pourrait vous donner un indice sur le moment où les valeurs sont perdues.

Vérifier le "App Pool Identity" (Identité du Pool d'applications) : Assurez-vous que l'identité du pool d'applications sous lequel votre site s'exécute sur IIS de production a les droits suffisants pour accéder à toutes les ressources nécessaires (base de données, fichiers temporaires, etc.). Parfois, un pool d'applications configuré avec "ApplicationPoolIdentity" ou "NetworkService" peut avoir des restrictions inattendues. Essayez temporairement (pour test uniquement) de le changer en un compte avec plus de privilèges (comme "LocalSystem" ou un compte de domaine spécifique) pour voir si cela résout le problème (et si c'est le cas, vous saurez que c'est un problème de permission).

Test croisé avec un autre navigateur/ordinateur : Pour éliminer toute possibilité de cache ou de configuration locale sur votre poste, testez le site de production depuis un autre ordinateur ou un navigateur différent (mode navigation privée par exemple).

J'espère que ces pistes vous aideront à cerner l'origine du problème. Le fait que Kalanda ne trouve rien dans les logs est un signe fort que le problème n'est pas une erreur "crashante" mais plutôt un comportement inattendu dû à l'environnement.
→ Revenir à WEBDEV 2025