This is probably a basic networking issue, but I am new to this stuff and just do not know the answer.
I have written a wcf service and client. I can use one of the http bindings and get the service to work correctly when I put my machine's network IP address as the endpoint address and run the client and server from the same machine. Now, I want to be able to connect to this service from a different machine over the internet. Clearly it does not work when I use my network IP address in this scenario, but simply putting in my router's broadband IP address does not seem to be doing the trick, either. Am I just missing a firewall port that I need to open up, or am I trying to do something that should not be possible?
If you want users from the internet to be able to connect to your service, you'll have to consider a few points:
binding: the lowest common denominator is the basicHttpBinding which is SOAP 1.1 with basically no additional features available - just like ASMX webservices. Just about anyone can connect to that. For more advanced clients, you might also want to expose a wsHttpBinding endpoint on your service
security: how (if at all) do you want to secure access to your web service? Do you have username/password credentials that callers must supply? Check out the WCF Security Guidance for a whole slew of information bits on the various security scenarios
authenticating your service: typically, you should strive to make your service authenticate itself to the rest of the world - this requires a server certificate and enables secured communication (messages signed + encrypted) on the wire
make sure your service endpoint(s) is reachable from the internet, through all firewalls and proxies and everything :-)
Hope that helps a bit!
You need to set up port forwarding on your router. Perhaps someone on ServerFault or SuperUser would be able to help you. Or even a google search now that you know what it's called. The instructions will be different depending on the router. The port you need to forward will be the port you've picked in the WCF config file.
I host WCF services through IIS, but it took me ages to work out how. At the moment I put the files on the webserver and enable websharing on the root folder. Then you can assign them to an appropriate Application Pool in IIS, and add a service reference to any client projects using the URL of the wsdl.
I'm not sure if this is the best way to do it but its the only way I've worked out so far.
Here's the simple solution.
I am assuming that you have made a working WCF application and hosted over the IIS.
The next thing to do is to browse the application from the IIS. It will give you url in the address bar something like:
http://localhost/myservice/service.svc
Next go to www.whatismyip.com. this will give you your system's WAN IP (say, 45.34.56.200).
Replace the URL you got in step 2 with: http://45.34.56.200/myservice/service.svc
Now you can use this URL any where in this world to consume your service.
I found a good Article and it is working fine for me, on the following the Main steps:
1-First you should create WCF Service.
2-add application on IIS and give alias for your virtual directory and set path from your local drive.
3-Make sure your default app pool set to .NET CLR V4.0.
4-test your WCF service is running successfully on localhost.
5-To access the same via LAN (Local Area Network) you must disable Firewall for you Private network.
6- try to use ngrok.com, you will get Temp URL to use via internet to access your LocalHost anywhere.
Then Everything will be fine.
For More Information Check the following Link:
https://www.codeproject.com/Tips/813650/Host-WCF-on-LocalHost-and-access-via-Internet
Related
I created an api using SLIM framework, but the services are not accessible to public as they are limited to localhost. how to host the services on a realtime server, so that, they can be accessible from anywhere?
please some one help me
This question requires more detail in order to answer properly.
If you are hosting your API on a windows server, then it is likely you have configured some kind of "WAMP" stack, correct? Or maybe serving PHP through IIS? This are important questions because we need to know what port you have bound your web application server to, which leads us to the next question...
Where are you hosting the server which is running the application which bound to what port?
Ultimately, a public, external IP will need to be either:
a. NAT'ed to the internal IP of your web server instanced
b. Port-forwarded to the internal IP of the server running your web application
Still, we are making a lot of assumptions here because getting a web application "accessible from anywhere" will require different work depending on your environment.
Here is the most basic example:
You are at home, running this API on your Windows workstation and will like to be able to hit it from a remote location.
Ensure Windows firewall allows inbound traffic to the port on which your application is running (probably port 80/HTTP, maybe 443/HTTPS).
Log into your ISP's router and configure port-forwarding to ensure inbound traffic on, say, port 80, is routed to the internal IP of the workstation running the API.
That's all there is to it.
Keep in mind that this also assumes that your ISP even allows you to expose your own web server to the internet on port 80 (or 443). Also, since we know nothing about your environment, this is all pure conjecture. Please provide more information you would like a real answer.
The most traditional way to host Slim Framework, would be through Apache. Install Apache and be sure you have the proper network settings to allow inbound connections, but more information about your setup could be needed for proper guidance.
http://httpd.apache.org/docs/2.4/platform/windows.html
When Apache is installed and working, you need to set Rewrite rules on the URL, information on that can be found on http://docs.slimframework.com/routing/rewrite/.
Your question on the verge of off topic, it probaly is, but read up on what questions can be asked and not, here on Stackoverflow, hope i could help.
I have a WCF service, and two apps behind the Firewall, and third app connect remotely through internet. I host the service on IIS.
If I restrict the IPs to local IP, and that remote server IP using IIS, would that be sufficient? if yes, Is that a bad idea for another reason rather than security.
Given that the remote server will connect through HTTPs and credentials.
thanks
Securing using IP is a good idea only if you are sure that IPs are static and unlikely to change. For example, local IPs can easily change (typically, they get auto assigned). So, I will go via this route if what you are securing is a critical/sensitive.
I have an app with a self-hosted WCF service.
My WCF service gets published under the URI "net.tcp://localhost:8004/DocumentService". When I run the service on a remote machine and try to discover the service with the new .NET 4 class DiscoveryClient, the found services all have the URI "net.tcp://localhost:8004/DocumentService" too without any information about the actual machine where the service is hosted.
Obviously this is useless if I want to access the service on the remote machine. But I can't find any reference to the actual remote machine (IP address or server name) in the arguments passed to FindProgressChanged.
Is there a way to get the information about the remote machine or do I have to publish my service with the machine name of the remote machine? Or is DiscoveryClient just broken?
I hope this make sense.
I spent a lot of time investigating this problem. Building base addresses in the code was not acceptable for me, as it implies hardcoding transport scheme and port (the latter, of course, can be stored in a separate config section, but then why not just to use the existing section?). I wanted to have an ability to just configure the base address in config as usual. And it turns out that a base address like <add baseAddress="net.tcp://*:8731/"/> will perfectly work. I think the same is true for programmatic configuration.
I am struggling with a WCF issue relating to name resolution-or something like so. When I consume a wcf service (netTcpBinding) on an application server via a web application on the web server it doesn't work. Ok it doesn't work in most situations. If you access the web application from the web server itself using localhost or 127.0.0.1 it works. However accessing it through the web server via another client machine or accessing the web application locally on the web server using the host name or IP address does not work. In both instances you get a socket connection aborted error.
What makes it more interesting is that switching all the security to 'none' as opposed to 'transport' resolves the issue.
My question is, is it possible to access wcf services using your web server and still use transport security? Or is this a bug/designed behaviour?
Many thanks for any insight,
Steve
The default NetTcpBinding security option is Kerberos / Windows Authentication. If your client and service are not on the same domain it will not work. You may need to look at certificate based authentication.
If you your service is running under a domain account, try changing it to LocalService or NetworkService to see if it resolves the issue.
Transport security typically only works point-to-point - when the client connects directly to the server.
If you have clients that come in from the internet, you have no control over how many intermediary hops they go through - so Transport security, even if you get it to work, will most likely not work at all, e.g. your message might be protected from the client to the first hop, and from the last hop to your server - but not in between hops.
For an internet scenario, typically, Transport security is not a valid option - use Message Security for those cases.
I'm not 100% sure why the connection wouldn't work at all - but in any case, if you're not behind a corporate firewall, I wouldn't be using netTcp with transport security in such a scenario.
Could you please add your server side config (anything inside <system.serviceModel>) to your question to see how you set up Transport security?
I have a WCF service currently using a TCP endpoint. Rather than create a separate console client app to administer the server I want the ability to telnet into the server or even just connect using a raw connection using putty and execute ascii commands straight on the server.
Any ideas how I would go about doing this? Not an expert on WCF so would appreciate any help. Thanks
I doubt you could do that - WCF will always have to use its defined endpoints - TCP, HTTP - whatever. I am not aware of any telnet binding or raw connection, as you mention it.
From my perspective, why not create a service contract for admin purposes and just hit that with HTTP and/or TCP from a console app? Seems easier than trying to "bolt on" something that's not really been thought of.
Marc
To administer my WCF apps, I host in IIS, and have a subfolder in the application virtual directory with Admin aspx pages. The folder is protected from unauthorized access using ASP.NET roles.
The Admin folder includes application-independent pages (e.g. managing logging, view log files) and where appropriate application-specific pages.
Since the ASP.NET pages execute within the same AppDomain as the hosted WCF services, the sky's the limit as far as adding functionality for instrumentation and dynamic configuration.
I don't think WCF support custom command processing out of box and it will be quite a bit of hoop jumping to get that to work. I would suggest
Host the WCF service inside a windows service rather than IIS
Create a socket listener inside the windows service listening on the port of your choice
Write some code to process your command when data arrives the socket