I am trying to deploy a Silverlight with WCF Service to a hosting. Basically, I have the same problem as this guy:
How to configure WCF services to work through HTTPS without HTTP binding?
Except the solutions don't work for me.
//edit: I've been pasting it wrong, but it still doesn't work.
I have tried Ladislav Mrnka's answer - changed this in the Web.config file:
<serviceMetadata httpGetEnabled="false" httpsGetEnabled="true" />
The dreaded error still appears when I navigate to the .svc file on the server:
The HttpsGetEnabled property of ServiceMetadataBehavior is set to true and the
HttpsGetUrl property is a relative address, but there is no https base address.
Either supply an https base address or set HttpsGetUrl to an absolute address.
Now it should be all correct, I just changed the httpGetEnabled and
httpsGetEnabled in the proper place (it's already in the config file).
But I still get the error. Should I perhaps specify the HttpsGetUrl
somewhere? Where?
Yes, see here.
Should be:
<behaviors>
<serviceBehaviors>
<behavior name="NewBehavior">
<serviceMetadata httpsGetEnabled="true"
httpsGetUrl="https://myComputerName/myEndpoint" />
</behavior>
</serviceBehaviors>
</behaviors>
This error happened because the setting is logically wrong. If you enable the httpsGetEnabled means, you allow clients to retrieve metadata via https. And if you don't provide a URL about https, how can clients retrieve metadata from https. So the error message alert you to provide a URL.
Either supply an https base address or set HttpsGetUrl to an absolute address.
You have three options.
Provide httpsGetUrl as other answers showed above
Binding an address via IIS
(if you are still developing in visual studio then you only need to degug with SSL Enabled mode )
Set httpsGetEnabled to false
In configuration, under behaviour where you have set httpsGetEnabled="true",
Set httpsGetUrl="https://UserSystemName/EndPointName" too and problem resolved.
<behaviors>
<serviceBehaviors>
<behavior name="mexBehaviour">
<serviceMetadata httpsGetEnabled="true" httpsGetUrl="https:///UserSystemName/EndPointName"/>
</behavior>
</serviceBehaviors>
</behaviors>
Related
I am writing a system where we do not want to expose the metadata on a WCF service. When setting up the service we get our clients to browse the .svc files in order to determine if they have hosted the service correctly.
Where does his page come from, is it an IIS contsruct? Is it generated by WCF?
Is it possible to replace the html page that comes up with our own custom html page?
httpHelpPageUrl lets you move the default WCF help page to another location from serviceDebug element. Make sure you turn off httpGetEnabled.
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="false"/>
<serviceDebug includeExceptionDetailInFaults="false"
httpsHelpPageEnabled="true"
httpHelpPageEnabled="true"
httpHelpPageUrl="myhelpPage.html"
httpsHelpPageUrl="myhelpPage.html"/>
</behavior>
</serviceBehaviors>
</behaviors>
More information SO How can I change an html output of wcf service with my own content?
I have hosted a WCF service on Azure at http://voraservice.cloudapp.net/MyPushService.svc. The problem is when I connect through client, it gives me that no endpoint found at the given address:
http://rd00155d3425e0/MyPushService.svc
I dont know how this random servername came here and am trying to figure out since few hours how to remove this random server name and put the actual location of the WCF hosted on the cloud. Any pointers to solutions are appretiated!
Update: I saw this KB article - http://support.microsoft.com/kb/971842/
But when I try to update for Win7 its says hte update is not for my computer.
Initially I was redirected to this KB - http://support.microsoft.com/kb/971842/ but this dint help me on my Windows 7 machine.
Finally I was able to resolve this by adding useRequestHeadersForMetadataAddress tag inside serviceBehaviors tag.
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="ShoutboxWebRole.ShoutsBehavior">
<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="false"/>
<useRequestHeadersForMetadataAddress/>
</behavior>
</serviceBehaviors>
</behaviors>
<services>
...
</services>
</system.serviceModel>
May sound like a manual instruction, but please check the config of consuming application. Often it is pointing to wrong direction. Here is a similar problem discussed in this blog post http://junooni.wordpress.com/tag/azure-incorrect-address-no-endpoint-listening/
All the best.
I have created wcf service and planning to make it accessible from the internet. The page 'You have created a service' seems to be some stub which should be replaced before putting service on production. Is it a bad practice to have this welcome page on production? What do you do with that welcome page when you publish wcf services on the internet?
Thanks
On production you can turn off this page by adding:
<behaviors>
<serviceBehaviors>
<behavior name="ProductionService">
<serviceDebug includeExceptionsInDetail="false" httpHelpPageEnabled="false" />
</behavior>
<serviceBehaviors>
</behavirs>
Also think about publishing WSDL / Metadata. If you don't want to publish WSDL but you want to use mex endpoint use following configuration:
<behaviors>
<serviceBehaviors>
<behavior name="ProductionService">
<serviceMetadata httpGetEnabled="false" />
<serviceDebug includeExceptionsInDetail="false" httpHelpPageEnabled="false" />
</behavior>
<serviceBehaviors>
</behavirs>
Your services must use those behavior in their behaviorConfiguration attribute.
Yes, it's bad. It says potential attackers that the system is non-configured completely, so they would try to attack it. Also, it's not very professional.
Well, print something useful there or hide it:-)
WCF allows you to specify an external WSDL file that should be published with the service rather than WCF's generated WSDL. In a WSDL-first design approach, it makes a lot of sense to publish the source WSDL rather than the generated WSDL.
This is set using the externalMetadataLocation:
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="true" externalMetadataLocation="path_to_my_wsdl.wsdl"/>
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
The problem I'm encountering is that when I do this, it serves the WSDL straight-up, which has the wrong endpoint address. I want the endpoint address to be replaced at run-time with the real endpoint address of the service (which will differ depending on where it is deployed).
Is there an easy way to do this?
I'm in no way a WCF expert but can't you do this by specifying it on the endpoint in the config file (web.config), for example:
<system.serviceModel>
<services>
<service>
<endpoint
listenUri="https://yourdomainname.com/servicename.svc"
address="https://yourdomainname.com/servicename.svc">
Note: "listenUri" is the physical address and the endpoint "address" is the logical address. Ie. "listenUri" is where the service really is and endpoint is what the client will be asking for.
If they are the same you don't need listenUri I believe.
I'm modifying my WCF API to include a new service that should be exposed to internal IP addresses only. All of the services in my API are available in SOAP, POX and JSON. What I'm looking for is a behavior or something that allows me to implement a simple IP address filter, to process requests from internal IP's and deny everything else. I'd like it to work in configuration, because all the other services in the API should remain available to the Internet. I did some googling but can't find anything like this built into WCF. Am I missing something?
Ok, I figured it out, and its kind of slick, in my opinion.
I implemented an IP Filter system as a service behavior, then added it to my service in the web.config. Here's my new web config behaviors section:
<serviceBehaviors>
<behavior name="ServiceBehaviour">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
<behavior name="RestrictedServiceBehaviour">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
<IPFilter filter="172.*.*.* 127.0.0.1" />
</behavior>
</serviceBehaviors>
The IPFilter class implements IDispatchMessageInspector to catch the request as soon as possible, inspect the client IP and throw an exception if it doesn't match the filter. If anyone's interested I can post my code.
If your service is hosted in IIS, then you can do this with IIS, on a per-website basis (maybe per-application, but I don't know).