I have a Silverlight app that run on a single server which also hosts the web service used for data access. This is a Service Reference in the project. A common issue is that someone browses to the app using an IP address rather than the machine name. This breaks because the app thinks this is a cross-site violation.
To access the web service we create a System.ServiceModel.ClientBase and assign is an address in the web.config file. So locally in dev this is localhost:xxxx, and in production is it the machine name. Or we could set it to the IP address, but then everyone would have to go to the app using IP address only.
Is there a good way to do this? One issue is that some people access the app internally where the machine has a good name, while others access it through a VPN where they may need to use IP. I would like for both to work.
FYI I had this same issue. silverlight application and wcf service running on same server, but when application is started using an ip address vs. application url, then cross domain problems occur. evidently these urls/ips are not resolved/matched locally so to the silverlight application, they look like different domains. My app is running as an application and couldn't be moved to root of iis web site for technical reasons which is required for a clientaccesspolicy.xml file or crossdomain.xml to work properly.
I solved it by adding an entry into the hosts file on the server with the ip address and name of the domain. This looks a bit strange since we are on the server pointed to by the ip address and the domain/machine name but it works.
Adding this locally in the hosts file evidently redirects all requests for the ip address to the server PRIOR TO making either the call to get the silverlight application or the call the wcf service, so they look the same no matter whether the application or the service is called using an ip address.
Hope this helps anyone else in the future.
FYI - this does not work with VMs
We use VMs for some functionality and I have found this just doesn't work when running clients from the VM. The VM manager must do something to the request before passing it through. Just thought I'd mention this for future use.
Have you tried creating a clientaccesspolicy.xml file?
http://msdn.microsoft.com/en-us/library/cc197955(v=vs.95).aspx
Related
Our AppEngine app is connecting to a remote service which requires a VPN and also required me to add entries to the hosts file on my local machine in order to connect to their endpoints.
e.g.
10.200.30.150 foo.bar.com
This is working fine when running the app locally, but I can't figure out how to set this up on Google Cloud to work once deployed.
I can't use the IP addresses directly because it errors that the IP is not on the cert's list.
How do I map the host names to the IPs in Google Cloud so that AppEngine can use them?
From the error mentioned in the comment I suspect connecting directly through the IP fails because the certificate doesn't recognize the IP to DNS mapping as valid and therefore the secure connection setup breaks. Based on the requirements of connecting to the API by VPN and tweaking the hosts mapping there are few things you may try.
The simplest approach that may work would be using a Google Compute Engine VM instance, since there you would able to manipulate the etc/hosts file and replicate the local machine setup. This VM could be used either as the main app service or as a proxy from App Engine to the 3rd party API endpoint. To go that route I would suggest taking a look at these two posts which explain how to change the etc/hosts file on GCE (Changing the file once wouldn't work as the VM periodically overrides it, see the posts for cronjob like workaround).
Separately, as your app runs in App Engine flexible environment there is the chance to provide a docker container with the app packaged. It may be possible to set the workaround above in the docker file and have it working in App Engine too.
I have a local sandbox website on my computer running on nginx. I have chrome canary and that's what I"ve been using to test the various media sizes. Of course, this doesn't stack up against actual hands-on testing to get an idea of the feel of the website.
So, is there a way to be able to access a website running on my computer from the same network? Even if I have to use a specific app. I would like to use the same URL. dev.mywebsite.com and mywebsite.com run a on a server, sandbox.mywebsite.com is on my machine (this is the one I would like to access). I don't need to access to it remotely, just when I'm on my network is fine.
Note: I need to use the actual URL.
Thanks.
If sandbox.mywebsite.com maps to localhost on your computer, then by mapping sandbox.mywebsite.com in the hosts file of your phone to the local network IP address of your computer e.g. 192.168.1.9, you should be able to access it on the phone.
I have done this using android with hosts editor, connecting to apache running on an ubuntu laptop.
There are also many google results for this, so you may be able to find something there for your specific configuration.
i am new for openshift apps, so i make an app in openshift website and i need to point a domain to its web address .
so my domain provider only allowed to set domain based on Website Nameservers . so i want to know is my Website Nameservers i openshift is static, or may be changing in future.
For example my site address is
app-mysite.rhcloud.com
and it's Nameserver is :
ns1.p23.dynect.net with IP 208.78.70.23
.so if i set my domain NS Recorde to ns1.p23.dynect.net it will work .and Nameserver of app-mysite.rhcloud.com will be change in future or no. (Because in openshift site they have said IP address of app-mysite.rhcloud.com maybe change do to server maintenance or ...)
The best way to configure custom domain names with your OpenShift applications is through the use of CNAME certs, see this post for more information https://www.openshift.com/blogs/domain-names-and-ssl-in-the-openshift-web-console. That being said providing the name of your domain provider might be helpful.
Your application IP will inevitably change since your application will unlikely stay on that node. Take a look at the article I mentioned earlier and if you follow those steps your custom domain should persist regardless of your application IP.
I'm developing a silverlight application that uses a web service. It works just fine when I run it on my local machine but when I publish it to a remote server, it fails because it is looking for a a crossdomain.xml policy at localhost:4689 instead of the websites root directory. How do I fix this?
Thanks for the help!
When you add the service reference, the host--in your case, localhost--is included as part of the generated code, and is the default endpoint when you create the service client on the Silverlight end with no constructor parameters.
Use the constructor overload of the service client class that accepts a Uri parameter to specify the correct hostname (and path to the .svc file) on your production server.
You need to edit your ServiceReferences.ClientConfig because when you deploy your project it's still using the endpoint address of your local computer.
I made a simple Silverlight app, with a web service calling a database, and got it to work on my development computer.
When I published the web service project to IIS, on the same computer, and accessed the Silverlight app from IIS using http://localhost/SilverlightTest/, I could see the Silverlight in the page, but the call to the web service was not working.
So I added the file clientaccesspolicy.xml in several places. All of the instructions say to put it in the root directory, so I tried:
c:\inetpub/wwwroot\ Did not work
c:\webs\SilverlightTest\ This the folder to which I published the web service project, including the xap file. But did not work
c:\webs\ Just a guess, but that did not work.
Then, in VS, I added the file to the web service project, and that added it to the folder where the web service project is stored c:\work\Silverlight\TestWCF\TestWCF.Web\ . When I opened the page in Firefox from IIS, the call to the web service now worked. Apparently, the Silverlight application is calling the web service in my development folder, not the service in the IIS virtual directory c:\webs\SilverlightTest\ (He call to the web service did not work when I opened the page from a different computer in the workgroup)/
Why would the Silverlight application call a web service in a development folder? Shouldn't the web service be in the virutal directory to which it was published? How can I resolve the confusion?
Here is the configuration in my ServiceReferences.ClientConfig file
<client>
<endpoint address="http://dellnov2006:2753/SimpleWCF.svc" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_ISimpleWCF" contract="SimpleWCF.ISimpleWCF"
name="BasicHttpBinding_ISimpleWCF" />
Any help, explanation, or pointers to relevant articles would be greatly appreciated. An article explaining how Silverlight apps call web services would be greatly appreciated.
Thanks
Mike Thomas
In your config file, the endpoint address is http://dellnov2006:2753/SimpleWCF.svc
So it seems that you are trying to connect to that address.
Before you publish the application you must modify that address to http://localhost/Service/SimpleWCF.svc or something to point exactly to your service.
The clientaccesspolicy.xml must be in **c:\inetpub\wwwroot** But you need this file only if you will access the service from different host that it was downloaded. I don't think you need it in your case, if you want to use localhost on the local iis.
The address in the ClientConfig is the address of the service you "Added Service Reference" against. As you noticed, it's not a relative path. To overridde this behavior, specify the URI of the address in the constructor of the Service client.
Also, you really need Fiddler. You'll love it. It helps with these issues as well as cross domain issues.
Many thanks djjoyro. You were right. Changing the config file to:
endpoint address="http://MachineName/SilverlightTest/SimpleWCF.svc" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_ISimpleWCF" contract="SimpleWCF.ISimpleWCF"
name="BasicHttpBinding_ISimpleWCF"
worked, and without a client access policy file. This also worked when I accessed the Silverlight app from other computers in the workgroup.
I also tried using localhost instead of the computer name, but I did have to use a clientaccesspolicy file, and I could not access the web service when using other computers in the workgroup.
There is a lot more I need to know about this, but at least deployment is now working after several days of struggling.
Mike Thomas
Late to the party, but I will add that if your binding address includes a port #, then you are still using the Visual Studio web server. http://dellnov2006:2753 is a dead giveaway that you still using the VS web server and not IIS as you intended.