HTTPModule invoqué sur la page principale mais pas sur la sous-page

Question

Je suis confronté à une erreur étrange dans MOSS 2007 s'exécutant sous Windows 2008. J'ai créé un module HTTP personnalisé qui se déclenche sur l'événement OnAuthenticate de l'application. Il crée essentiellement un cookie personnalisé qui est utilisé par une autre application pour authentifier l'utilisateur, créant un effet de connexion unique.

Tout s'est bien passé sous le serveur de développement exécutant Win2K3. Cependant, sur le serveur de mise en scène des choses bizarres suivantes se produisent:

a) Le module semble tirer sur la page de base, à savoir https://conn.test.com/Pages/Default.aspx, si Somone va dans une sous-page directement comme: https://conn.test.com/Operations/Pages/Operations%20Portal.aspx, il ne semble pas faire feu.

b) Le module est déclenché par IE mais pas par Firefox ou Chrome. La seule différence entre les deux semble être qu'une certaine partie Web charge et fonctionne dans IE mais ne semble pas charger ou fonctionner dans Chrome ou FF.

Quelqu'un peut-il aider à expliquer le comportement de ceci. HTTPMOdule remplace l'événement AuthenticateRequest de l'application.

Answer 1

Désolé, j'ai compris cela. Le problème est que la méthode Init du gestionnaire d'événements pour OnAuthenticate fonctionne avec les privilèges de l'utilisateur ASP.NET sous-jacent, mais le délégué du gestionnaire d'événement principal travaille avec les informations d'identification de l'utilisateur authentifié.

J'ai écrit du code t sur un journal d'événements et apparemment cela nécessite des privilèges de niveau supérieur. C'est la raison pour laquelle le délégué du module tirait, mais rien n'était consigné. Je suppose que le webpart sur la page principale fonctionnait avec les privilèges d'un autre utilisateur qui avait les droits d'accès nécessaires et donc les choses qui y fonctionnaient. Comme il ne fonctionne pas dans FF ou Chrome, le module ne fonctionne pas dans ces navigateurs. En outre, les sous-pages n'ont pas la partie Web, donc directement sur eux, provoque également le problème.

Le problème a été résolu après avoir ajouté SPSecurity.runWithElevatedPriviliges autour du code de journalisation.