Hi All
I Have a service project that hosted it in local IIS and within this project i have a refrence to another service in an IIS on another server in this Domain but when i want calling this service I get an exception:
{System.ServiceModel.Security.SecurityNegotiationException: The caller was not authenticated by the service.
How I Can Solve It?
thanks
Check with hosing by console.
Check Domain access for user or port restriction.
when you host then try checking whether it is generating wsdl by just typing http://.. in IE
Related
I'm working on a wcf hosted inside a windows service. It works like a charm but now I need to reserve a specific hostname for this wcf just as IIS does.
To be more clear, my hosted wcf runs on a windows server machine which response to multiple dns name, but I need to let the wcf reachable only from one of these dns. If I was using IIS it would be achievable by setting a specific hostname within the http-bindings settings, but unfortunately, I can't manage my wcf like that.
To your knowledge, is there any way to reserve a specific hostname for a hosted wcf outside IIS?
Thanks in advance!
yes, you could do it by register the http endpoint at kernel level(http.sys) using the following commands
cmd: ***netsh http add urlacl url=http://fqdn:port/urlpath user=serviceaccount***
Then only on that specific dns/hostname, your http service will listen.
I'm trying to get my windows service working and running into a bit of a conundrum. IIS has a UCC cert installed with a host name, but I want to have my OWIN self-host windows service host share the host name.
However, if the IIS site is on and the windows service is started, the IIS site trumps the windows service and I get 404's calling the windows service's endpoints. If I shut off the IIS site, I can then access the windows service.
If the IIS site is on and the windows service isn't started, and I try to start it, I get an Access Denied error (ostensibly because IIS has already claimed all the things with that host name (all ur endpoints r belong to us)).
So is there a way to get IIS to not immediately swallow all services for that host name? Is there an exception or something that I can put in so https://host/api method calls won't be absorbed by IIS?
I have renamed a WCF service and everything works just fine on my test/development environment. However, the service is not accessible on my production environment, which is IIS. When trying to access the service the client receives roughly the following error:
The request failed with the error: The type Old_Service_Name.Some_Type could not be found.
In other words, IIS should be informed about the renaming of the service. How do I tell IIS, preferably using IIS Manager, that the service has a new name?
In the service.svc file, change the Service attribute of the ServiceHost tag so that it suits your new service name. Namely, replace Old_Service_Name.Some_Type with New_Service_Name.Some_Type.
Just finish my first WCF service.
I check it on my local network and all work fine.
Now, I want to give access to the web service from any where in the word.
How can i do it ?
Do i need just to add the web service to IIS as web site ? and with this way anyone in the word will be able to access the web service ?
Publish your service on a public IP address. It's the same concept as publishing a public web site.
You would have to host the webservice on a server that is accessible to the public.
I am running a self-hosted WCF service. In the service configuration, I am using localhost in my BaseAddresses that I hook my endpoints to. When trying to connect to an endpoint using the WCF test client, I have no problem connecting to the endpoint and getting the metadata using the machine's name. The problem that I run into is that the client that is generated from metadata uses localhost in the endpoint URLs it wants to connect to. I'm assuming that this is because localhost is the endpoint URL published by metadata. As a result, any calls to the methods on the service will fail since localhost on the calling machine isn't running the service.
What I would like to figure out is if it is possible for the service metadata to publish the proper URL to a client depending on the client who is calling it. For example, if I was requesting the service metadata from a machine on the same network as the server the endpoint should be net.tcp://MYSERVER:1234/MyEndpoint. If I was requesting it from a machine outside the network, the URL should be net.tcp://MYSERVER.mydomain.com:1234/MyEndpoint. And obviously if the client was on the same machine, THEN the URL could be net.tcp://localhost:1234/MyEndpoint.
Is this just a flaw in the default IMetadataExchange contract? Is there some reason the metadata needs to publish the information in a non-contextual way? Is there another way I should be configuring my BaseAddresses in order to get the functionality I want?
Thanks,
Mike
What .NET version are you using? If you're using .NET 4.0, add the UseRequestHeadersForMetadataAddressBehavior to your service host:
UseRequestHeadersForMetadataAddressBehavior urh =
new UseRequestHeadersForMetadataAddressBehavior();
serviceHost.Description.Behaviors.Add(urh);
Obviously, this needs to be done prior to opening the service host.
If you're using .NET 3.5, there's a hotfix that adds this behavior: support.microsoft.com/kb/971842.