J'essaie d'héberger un point d'extrémité ASP.NET WebAPI sur un rôle de travailleur Azure à l'aide du nouveau package Microsoft.aspnet.Webapi.Selfhost NuTet. Le code de mon travailleur () est à peu près comme ceci:
<Endpoints> <InputEndpoint name="Endpoint" protocol="http" port="8080" localPort="8081" /> </Endpoints>
3 Réponses :
Par défaut, le rôle de rôle est exécuté sous un compte d'utilisateur très minime de l'autorisation de la sécurité. Comme l'indique l'erreur, il est incapable de réserver ce port en raison de ces autorisations. Vous avez deux options ici:
- Créer un script de démarrage qui fonctionne élevé et se réserve ce port pour vous.
pour jouer autour (et dépannage s'il s'agit d'un problème de permission), le fait de faire n ° 1 est un moyen rapide de le tester.
Edit: Je semble rappeler un problème de permission avec WCF et Windows Azure lors de réservations génériques. Il utilisait bien pour utiliser le nom d'hôte complet E.g. xxx
Hey Ryan - Merci beaucoup! J'ai pensé que c'était une question de permission. # 1 est un joli gros marteau ... je le ferai si j'en ai besoin, mais j'espérais faire quelque chose d'un peu plus chirurgical ... comme courez Netsh dans un script de démarrage élevé - quelque chose comme "netsh.exe http Ajouter urlacl url = "http: // +: 8080" Mais je dois accorder la permission à un utilisateur, et je ne connais pas vraiment le nom / Sid du compte que Azure dirigera le rôle de travailleur sous ... y a-t-il un façon de constater cela ou d'exécuter netsh.exe d'une manière qui permet d'accéder à ce port à tous les utilisateurs?
Hmm ... maintenant que je regarde plus près, je pense que c'est parce que vous faites une réservation générique. Si vous venez de mettre à jour le code pour cibler l'adresse IP et le port exacts, je pense que vous pouvez contourner le problème de l'autorisation. IIRC, ce n'est que des réservations génériques qui doivent être élevées à ACL. Voir la réponse mise à jour.
Lorsque je trace la valeur de "baseaddress" dans le code ci-dessus, il ressort comme suit: 10.115.210.79:8080. Donc, je suis en train d'utiliser une correspondance exacte ... En outre, la chose étrange est que même si j'ajoute une ligne au script de démarrage qui fait "NetSh.exe http Ajouter URLACL URL =" http: // +: 8080 "utilisateur = Tout le monde "et vérifie qu'il s'exécute correctement (et que les autorisations ont raison lorsque je fais une" émission Urlacl HTTP NetSH "), je toujours obtenir la même erreur.
Après une demi-journée d'expérimentation de Dev-Day avec invoquant NetSh.exe à partir d'un script de démarrage élevé en vain, j'ai abandonné et avons fini par utiliser le grand marteau et prenant la suggestion initiale de Ryan d'exécuter tout le rôle travailleur élevé:
netsh.exe http add urlacl url=http://+:%ENDPOINTPORT%/api user=everyone listen=yes delegate=yes
J'ai couru le script une fois dans la cmd, mais je devais courir en tant qu'administrateur: qui gérez-vous votre script de démarrage comme? Un autre ref ici < / a>
Par défaut Azure n'exécute pas ses rôles dans des comptes élevés, mais dans des comptes d'utilisateurs assez restreints qui ne disposent pas de noms prévisibles (ce sont des GUID qui sont créés lorsque le contrôleur de tissu prépare la machine virtuelle). Azure permet d'exécuter des scripts de démarrage dans un compte surélevé (admin) - ce qui est ce que le
Oups, désolé, j'ai sauté sur le détail "Azure"!
Ajouter une référence 'system.servicemodel' à votre projet et avec "config.hostnamecomparisonmode = system.servicemodel.hostnamecomparisonmode.exact; ' Vous n'obtenez pas l'exception des privilèges d'administrateur (accès refusé).
Un petit commentaire s'il vous plaît?