If I host a publicly available WCF web service in IIS, how should I configure the endpoint address? I think I can use either:
<endpoint address="http://localhost/MyService" ... />
or
<endpoint address="http://example.com/MyService" ... />
In both cases, a client on another machine must use the second option for its client binding.
If I use Visual Studio to create the client, both server bindings seem to work fine. However, I think I had trouble using new-webserviceproxy in Powershell with the first option.
Does it matter which one I use on the server?
MSDN: Specifying an Endpoint Address:
you must use relative endpoint addresses for IIS-hosted service endpoints. Supplying a fully-qualified endpoint address can lead to errors in the deployment of the service. For more information, see Deploying an Internet Information Services-Hosted WCF Service.
From that link:
When hosted in IIS, endpoint addresses are always considered to be relative to the address of the .svc file that represents the service. For example, if the base address of a WCF service is http://localhost/Application1/MyService.svc with the following endpoint configuration.
<endpoint address="anotherEndpoint" .../>
This provides an endpoint that can be reached at http://localhost/Application1/MyService.svc/anotherEndpoint
Related
I've setup WSO2 API Manager on Ubuntu and everything seems to be working, except, when I go into the API Store and under API Console. When I want to "Try It Out", it doesn't work.
But more specifically, when it fails, it shows the curl command, and it is showing the incorrect IP address for my server. It is showing the default address of: 172.17.0.1
My Question is how to change this.
I have gone into /repository/conf directory and updated the carbon.xml file to change the HostName and MgtHostName settings to reflect my server's IP address.
Is there another place to set something so that 172.17.0.1 is no longer used or referenced?
Change the <GatewayEndpoint> URLs with the correct hostname, in api-manager.xml
<APIGateway>
<!-- The environments to which an API will be published -->
<Environments>
<!-- Environments can be of different types. Allowed values are 'hybrid', 'production' and 'sandbox'.
An API deployed on a 'production' type gateway will only support production keys
An API deployed on a 'sandbox' type gateway will only support sandbox keys
An API deployed on a 'hybrid' type gateway will support both production and sandbox keys. -->
<!-- api-console element specifies whether the environment should be listed in API Console or not -->
<Environment type="hybrid" api-console="true">
<Name>Production and Sandbox</Name>
<Description>This is a hybrid gateway that handles both production and sandbox token traffic.</Description>
<!-- Server URL of the API gateway -->
<ServerURL>https://localhost:${mgt.transport.https.port}${carbon.context}services/</ServerURL>
<!-- Admin username for the API gateway. -->
<Username>${admin.username}</Username>
<!-- Admin password for the API gateway.-->
<Password>${admin.password}</Password>
<!-- Endpoint URLs for the APIs hosted in this API gateway.-->
<GatewayEndpoint>http://${carbon.local.ip}:${http.nio.port},https://${carbon.local.ip}:${https.nio.port}</GatewayEndpoint>
<!-- Endpoint of the Websocket APIs hosted in this API Gateway -->
<GatewayWSEndpoint>ws://${carbon.local.ip}:9099</GatewayWSEndpoint>
</Environment>
</Environments>
</APIGateway>
showing the incorrect IP address for my server. It is showing the default address of: 172.17.0.1
it show an IP address found as local IP (so it may be a docker container or another of your IP addresses)
As already answered, the address can be changed as GatewayEndpoint parameter
When I want to "Try It Out", it doesn't work
Now I will assume that the default certificate is not trusted for the url. Though you may try to open the dev console in the browser and find out more information about it doesn't work
Please note the service port (8243) is different that the management port (9443) so the ssl certificate may not be trusted by the browser for the url
When having a self-signed ssl certificate, try to put the URL in the curl command to your browser and trust the certificate. Then try to call the API again
According to this thread, the endpoint is the URL where your service can be accessed by a client application.
But, it sounds to me like a kind of server. In that case, an endpoint will be always an URL? what is the difference between an endpoint and a server?
An endpoint is a URL which allows you to access a (web) service running on a server. A server(program) may actually host multiple such services exposing them through different endpoint.
e.g. To access twitter search API, https://api.twitter.com/1.1/search/tweets.json is the endpoint. But the same server also has another endpoint https://api.twitter.com/oauth/authenticate for authentication. Both the endpoints are hosted on the same server which runs on a machine with domain name twiter.com
server is something who host your side/data or run multiple services, like php, mysql, etc
end point is where something points like we say end point of phpmyadmin, and might be its a end point of some api.
api.example.com/getusers
I have generated a JAX-WS web service with RAD 8.5 which automatically generated an endpoint for the service at "http:endpoint". I generated a client for the web service from the WSDL and added transport security (SSL) to the web service and added a secure endpoint using the following line of code in my client:
proxy._getDescriptor().setEndpoint("https:endpoint");
Everything seems to work fine. My question is do I need to do anything about the existence of the original endpoint ant "http:endpoint". This is an in-house web service so all of the apps which use it in house will use the secure endpoint, but is the availability of the unsecure endpoint a security risk for the web service? If so, what do I need to do to fix it? Any help would be appreciated.
I am not familiar with the Framework you are using, but there should be a configuration in your proxy to not allow http calls at all. If you have that option, turn it on so that your service only listens on port 443 (secure port).
An alternative would be to rewrite all http requests with https.
i'm using wso2esb 4.7.0 and wso2dss 3.0.0. when i have started with these server their was less load on servers as their are less no of services.but now situation changes.Their are no of services on server and each proxy contain particular address endpoint of dss. After calling this address endpoint it navigate to that endpoint and retrieve information and give the response. This is general scenario of all the service.
Day by day no of services increases and due to the load the server getting slower. That's why i wish to create a particular default endpoint from where i can call the service easily. No need to call the address endpoint and all. Is it possible? how can i implement this?
for load balancing i have used Amazon AWS Elastic Load Balancer.
The question is not clear. For all proxy services your endpoints are different or not? I mean, all different endpoints calling same dataservice or different. If they are different, you need to have different endpoints. If all endpoints point same dataservice, then you do not need to have multiple copy of same endpoint. Define only one endpoint and use that in all proxyservices. When you define proxy service there is a option to define endpoint, where select the existing predefined endpoint.
I have built a website and a WCF service. The website calls the WCF service (an application underneath the website) to get data. This connection is made using netTcpBinding (it _should be netNamedPipes but for some reason this refuses to work (only) on the deployment server, so I'm using TCP/IP).
In IIS (7.5) I have used IP Address and Domain Restrictions to deny all unspecified clients to the WCF service. I can see the change reflected in my web.config and I am unable to browse to the WCF service (403.6 Forbidden screen appears).
The problem is that the website is able to connect to the WCF service and get data even when I specify NO IP address is allowed i.e. no matter what I change, the website can still call the WCF service.
Why can the website access the WCF service?
Did you make those same IP restrictions on your website? Since your website is the one calling the WCF service, making those same IP restrictions there would make sense also.