web-dev-qa-db-fra.com

Hébergement d'une API Web à l'aide d'OWIN dans un service Windows

J'ai une API Web auto-hébergée utilisant OWIN (dans un service Windows). D'après ce que j'ai compris, cela suffit pour que les demandes HTTP parviennent au service Windows. Je peux accéder à l'URL WebAPI (http://localhost/users) localement (à partir du même ordinateur), mais pas à partir d'autres ordinateurs. J'utilise le port 80, IIS est arrêté . Les autres sites Web (hébergés dans IIS, sur le port 80) fonctionnent correctement lorsque IIS est en cours d'exécution.

// Dans le service Windows:

public partial class Service1 : ServiceBase
{
    ...
    ...

    protected override void OnStart(string[] args)
    {
        Console.WriteLine("Starting service...");
        string baseAddress = "http://localhost:80/";
        WebApp.Start<Startup>(baseAddress);  //This is OWIN stuff.
    }
    ...
    ...
}

public class Startup
{
    // This code configures Web API. The Startup class is specified as a type
    // parameter in the WebApp.Start method.
    public void Configuration(IAppBuilder appBuilder)
    {
        // Configure Web API for self-Host.
        var config = new HttpConfiguration();
        WebApiConfig.Register(config);
        appBuilder.UseWebApi(config);
    }
}

Dois-je faire quelque chose de plus pour que cela fonctionne avec d'autres machines? (J'ai l'impression que les demandes http entrantes ne sont pas transférées au service Windows, mais uniquement à IIS. Lorsque vous appuyez en local, cela ne passe probablement pas par le module du système d'exploitation qui écoute les demandes http. deviner.)

44
Narayana

Le pare-feu de votre machine pourrait bloquer les demandes entrantes. Vous pourriez faire:

Vous pouvez exécuter la commande wf.msc pour ouvrir le Pare-feu Windows avec sécurité avancée et ajouter une nouvelle règle entrante pour le port 80 TCP.

(Vous devriez remarquer quelques règles entrantes commençant par World Wide Web Services.... Celles-ci sont destinées à IIS. Je ne sais pas si l'activation de ces règles suffirait pour permettre même à votre service Windows de recevoir les demandes ... vous pouvez essayer de voir si cela fonctionne sinon comme suggéré précédemment, vous pouvez créer une nouvelle règle entrante ..)

Mettre à jour:
D'après votre commentaire, il est possible qu'en raison de vos inscriptions à l'URL, vous ne puissiez pas accéder au service. Voici quelques exemples d’enregistrement de plusieurs URL avec HttpListener.

StartOptions options = new StartOptions();
options.Urls.Add("http://localhost:9095");
options.Urls.Add("http://127.0.0.1:9095");
options.Urls.Add(string.Format("http://{0}:9095", Environment.MachineName));

using (WebApp.Start<Program>(options))
{

Vous pouvez en savoir plus sur l'enregistrement d'URL dans les liens suivants:
http://technet.Microsoft.com/en-us/library/bb630429.aspx
http://technet.Microsoft.com/en-us/library/bb677364.aspx

51
Kiran Challa

Il y a 2 choses qui vous empêcheront d'utiliser autre chose que "localhost" dans le service Owin:

  1. L'application doit être exécutée en tant qu'administrateur pour ouvrir un port avec un nom d'hôte différent, "localhost". Vous pouvez résoudre ce problème en exécutant l'application avec des privilèges d'administrateur ou en ajoutant une exception pour un port donné à l'aide de: netsh http add urlacl url=http://*:9000/ user=<your user>
  2. Le pare-feu Windows peut bloquer le trafic d'autres ordinateurs. Dans mon cas, le pare-feu ne bloquait pas le trafic local (je pouvais accéder à http://localhost:9000 ou http://127.0.0.1:9000 ou http://192.168.1.193:9000 - qui était mon adresse IP locale du même ordinateur, mais il fallait ajouter une exception de port au pare-feu pour pouvoir accéder à ce service depuis un autre ordinateur) 
17
bart59

Je faisais face à un problème similaire. La solution ci-dessous a fonctionné pour moi.

StartOptions options = new StartOptions();
options.Urls.Add("http://localhost:9095");
options.Urls.Add("http://127.0.0.1:9095");
options.Urls.Add(string.Format("http://{0}:9095", Environment.MachineName));

using (WebApp.Start<Program>(options))
{
    ...
}
6
Maggie

C’est en fait un simple oubli sur lequel j’ai également trébuché: si vous n’écoutez que les requêtes sur localhost, 127.0.0.1, etc. - personne ne le verra jamais car seul VOUS (le soi-disant) vous comprend comme cette cible. Sur ma machine, je suis localhost, si je demande votre adresse IP sur n’importe quel port, ce service verrait get http: // your_ip: 80 , pas localhost. Tout ce que vous avez à faire est de servir sur "http: // *: {0}", et de cette façon, vous pouvez passer le port onStart ().

4
Nathan Teague

Problème similaire. J'avais écrit un service ServiceStack et l'avais hébergé dans un service Windows à l'aide d'une implémentation AppSelfHostBase. Remarque: ceci a été écrit en tant qu'application Net Core compilant en tant qu'application console mais, grâce à la magie de PeterKottas.DotNetCore.WindowsService (disponible via NuGet), peut être installé en tant que service Windows. 

J'ai défini l'adresse baseAddress sur http: //*.8088/ et je l'ai transmise à mon implémentation AppSelfHostBase, mais je ne pouvais accéder au service qu'à partir du même ordinateur sur lequel il avait été installé, comme le vérifie l'ouverture de la page de métadonnées ( http: // [machine]: 8088/api/metadata ) dans un navigateur. La solution consistait à ajouter le fichier .exe de mon application console à la liste des applications autorisées dans le Pare-feu Windows sur le serveur sur lequel il était installé. Ouvrez simplement la boîte de dialogue "Application autorisée" du pare-feu dans le panneau de configuration du serveur, cliquez sur le bouton "Autoriser une autre application ...", puis accédez au fichier exécutable du service Windows:

 Windows Firewall Allowed App dialog

1
Phoeniceus Agelaius