J'ai une application WCF que je codise. Je commence et arrête plusieurs fois au fur et à mesure que je change de choses, puis exécutez l'appel de service à nouveau.
Étant donné que j'ai besoin d'informations de session, j'utilise Avant de passer à Maintenant, il me dit: Le message n'a pas pu être traité. C'est très probablement parce que l'action ' http://tempuri.org/imyservice/myoperation ' est incorrect ou parce que le message contient un jeton de contexte de sécurité non valide ou expiré ou parce qu'il y a une inadéquation entre les fixations. Le jeton de contexte de sécurité serait invalide si le service a aborqué le canal en raison de l'inactivité. Pour empêcher que le service d'abandonner les sessions inactives augmente prématurément le délai de réception sur la liaison du point d'extrémité de service.
Cela signifie que je dois actualiser ma connexion et ré-configurer mon appel de service (qui devient gênant après plusieurs centaines de fois.). J'ai lu que le délai de sécurité est de 10 minutes. Je suis relancé en moins que 2 minutes, donc je ne pense pas que ce soit une question de temps d'époque. Je suppose que le jeton expire pour la raison évidente que j'ai tué et redémarré le service . La chose est que Je n'ai pas besoin des trucs de sécurité sur tout (je n'ai besoin que de la séance de session ou j'utiliserais BasichttpBinding < Strong> est là quand même faire que mon service WCF ne se soucie pas des jetons de contexte de sécurité? choses que j'ai essayé: J'ai essayé une configuration similaire à ce que j'ai trouvé ici
Mais je ne sais pas vraiment ce que cela signifie ou si c'est ce dont j'ai besoin (ce qui n'est pas de sécurité (pour l'instant)). Cela n'a pas supprimé le problème. wshttpbinding . WSHTTPTPLINDING J'utilisais BasichttpLinding et je pourrais arrêter le service, apporter des modifications et le redémarrer. Ensuite, je pourrais exécuter mon client de test WCF (tempête WCF) contre le point final et il fonctionnerait toujours bien.
4 Réponses :
Vous pouvez utiliser la liaison HTTP de base avec < TransportCredentialy Mode de sécurité
Cela ne donne aucune information de session cependant ... Toute la raison pour laquelle je suis allé à la liaison plus avancée consiste à obtenir des informations sur la session.
Mode de sécurité Aucune ne devrait faire le travail.
<bindings>
<wsHttpBinding>
<binding name="WsEventLogBinding">
<security mode="None" />
</binding>
</wsHttpBinding>
</bindings>
activé par défaut . Essayez d'utiliser ceci sur votre configuration de liaison pour désactiver la sécurité:
<security mode="None">
<transport clientCredentialType="None" />
<message establishSecurityContext="false" />
</security>
Au début, vous êtes vrai: BasichttpLinding ne supporte pas cela en raison de la nature sans connexion / apatride du protocole HTTP.
Mais je pense qu'il y a quelque chose qui ne va pas dans votre compréhension de la WCF.
La session est un concept générique dans WCF. Il peut être session basée sur la sécurité , dans lequel les deux extrémités de la communication ont convenu d'une conversation sécurisée spécifique ou d'une session réalisable dans laquelle les messages peuvent être configurés pour être livrés dans l'ordre Et exactement une fois, assurant des messages sont reçus même lorsque des messages parcourent plusieurs nœuds pendant la conversation. Les deux modes vous permettent de sélectionner InstanceContextMode.Persession. Est-ce vraiment que voulez-vous? Security WCF s'appuie sur une authentification mutuelle; Si les deux parties font confiance aux informations d'identification des autres (sur la base des réclamations), un contexte sécurisé peut être établi dans lequel tous les messages sont échangés dans la confidentialité, et tous les messages sont signés pour protéger leur intégrité. La session de sécurité est unique et vous ne pouvez pas la réutiliser dans une autre conversation. Voici le problème avec votre contexte: le problème n'est pas sur côté serveur mais sur côté client . Parce que quelque chose doit être conservé sur le client et sur le service, la reconstruction du service affleurera tout le contexte de la WCF sur le service (toutes les instances et les sessions seront disposés). Il n'y a pas de magasin de données générales associé aux sessions WCF (une différence avec ASP. session nette), donc un redémarrage va tout laisser tomber. Cependant, le client croit toujours être authentifié en raison de son contexte "invalide". Pour résoudre ce problème, il existe une case à cocher pour ce scénario sur le client de test WCF par défaut: "Démarrer un nouveau proxy". Sur la tempête WCF, il existe une configuration générale sous la hotte / divers "Créer toujours de nouveaux proxy". Remarque: sur la production, vous n'aurez jamais ce scénario car votre service sera toujours en place. Si vous me suivez, vous voudrez peut-être essayer une session fiable. Vous pouvez tester mais je ne suis pas sûr que cela fonctionnera. Note importante : Je ne connais pas votre niveau de WCF, mais dans WCF , Les clients et les services doivent avoir des configurations synchronisées (même sécurité, paramètres de session, ...)
Seriez-vous capable de poster la solution à un site de partage de fichiers? De cette façon, nous pouvons tenter de répliquer le problème et d'essayer un certain nombre de solutions différentes. THX
Aussi, avez-vous regardé cela: Stackoverflow.com/Questtions/4767102/...