un WebServiceHost peut être modifiée pour éviter l'utilisation de HttpListener?

Question

Je cherche un moyen d'utiliser un WebServiceHost WCF sans avoir à compter sur la classe HttpListener et il est associé à des problèmes d'autorisation (voir cette question pour plus de détails).

Je travaille sur une application qui communique localement avec une autre application (tiers) par l'intermédiaire de leur API REST.

À l'heure actuelle, nous utilisons WCF comme un serveur HTTP embarqué. Nous créons un WebServiceHost comme suit:

String hostPath = "http://localhost:" + portNo;
WebServiceHost host = new WebServiceHost(typeof(IntegrationService), new Uri(hostPath));

// create a webhttpbinding for rest/pox and enable cookie support for session management
WebHttpBinding webHttpBinding = new WebHttpBinding();
webHttpBinding.AllowCookies = true;

ServiceEndpoint ep = host.AddServiceEndpoint(typeof(IIntegrationService), webHttpBinding, "");

host.Open()

ChannelFactory<IIntegrationService> cf = new ChannelFactory<IIntegrationService>(webHttpBinding, hostPath);
IIntegrationService channel = cf.CreateChannel();

Tout fonctionne bien aussi longtemps que notre application est exécutée en tant qu'administrateur. Si nous courons notre application sur une machine sans privilèges d'administrateur du host.Open () lancera une HttpListenerException avec ErrorCode == 5 (ERROR_ACCESS_DENIED).

On peut contourner le problème en exécutant httpcfg.exe de la ligne de commande, mais ceci est une application de bureau en un seul clic et ce n'est pas vraiment comme solution à long terme pour nous.

On pourrait fossé WCF et écrire notre propre serveur HTTP mais je voudrais éviter que, si possible.

Quelle est la meilleure façon de remplacer HttpListener avec une prise standard TCP tout en utilisant tous les échafaudages HTTP reste que WCF fournit?

Answer 1

Vous pouvez facilement composer votre propre pile via CustomBinding, en utilisant les trucs de protocole de niveau supérieur « tel quel », et rouler votre propre version de HttpTransport qui n'est pas soutenu par HttpListener ou IIS. Faisables, bien sûr, mais il est beaucoup de travail. Prenez part avec Reflector- les bits HttpTransport existants il y a beaucoup de pièces mobiles là-dedans. Vous pourriez probablement pirater simple PoC sur Socket dans un jour ou deux si vous n'avez pas besoin de rien de fantaisie comme HTTPS ou Chunking, mais en le rendant robuste sera difficile de trouver. est un bon wrapup d'un groupe de ressources (peut être un peu daté maintenant).

Answer 2

Votre problème est pas lié à HttpListener.

Votre problème est

: * Vous avez une application oneClick avec des autorisations limitées * Tente d'ouvrir un port du serveur.

Ceci est une contradiction. Une demande d'autorisation limitée non fiable ne devrait pas ouvrir un port SERVER. Voilà pourquoi ce n'est pas autorisée par définition.

Avez-vous essayé d'ouvrir un port de prise normale? Il ne faut pas travailler non plus.

En général, les applications de l'utilisateur final de la confiance limitée ne devrait pas héberger un service Web;)

Cela dit, j'ahve été dans une situation similaire en essayant d'utiliser WCF dans un scénario de communication pilote -. Dieu merci! Mon application fonctionne avec la permission complète

Answer 3

Vous pouvez aussi regarder à déchirer assez en dehors de Cassini pour le rendre hébergeable dans votre application, et le chargement du pipeline de WCF là-dedans (via des fichiers .SVC et le gestionnaire d'activation de service) - il avait besoin d'écrire très peu de nouveau code de cette façon, mais quand même vous donner un serveur Web assez robuste et testé.