In a silverlight application, I want to access the page the silverlight .xap file from an HTTP subdomain, but have the web services access a different subdomain for sensitive information over HTTPS.
I set up clientaccesspolicy.xml at the root of the subdomain and it lets the silverlight app access its services over http, but not over https. It gives the cross domain access error that it would give normally without a clientaccesspolicy in place.
I know that browsers themselves have a lot of restrictions about mixing http and https. Am I trying to do something that is not allowed?
Check out:http://silverlight.net/forums/t/12741.aspx
You can either make https calls to the
same domain or http cross-domain
calls, but not https cross-domain
calls.
This is described in
http://msdn2.microsoft.com/en-us/library/cc189008(VS.95).aspx
(see "If not HTTPS" in the matrix)
By JohnSpurlock
This is out of date since Silverlight 2.0 was released. You can now do most cross-domain scenarios with the appropriate configuration. http://msdn.microsoft.com/en-us/library/cc197955(VS.95).aspx
The important thing to note here that is not in the above information clearly is you must have access to the "ROOT" level of the domain request, and the clientaccesspolicy.xml must reside at that level.
If for example you have a production environment that your application is behind a load balancer that directs traffic as most large companies do to your application via the URI, you then have a little bit of a problem.
Example: http://mydomain.com/MyApplication/* goes to your server, where your app resides.
http://mydomain.com/clientaccesspolicy.xml is where the policy exists.
Related
Is there an elegant way to prevent requests from referrers outside the application? Looking at the app.yaml documentation, it doesn't seem like this is a in-box functionality but it seems like it'd be so preferred/common that it has to be hidden somewhere rather than necessarily having to reimplement it manually for every application.
It is built in.
In app.yaml you can specify login: admin for a handler and it would accept requests just from admin or from AppEngine (e.g. cron, taskqueues, and pribably urlfetch of the app itself - the last one not 100% sure).
See docs: https://cloud.google.com/appengine/docs/python/config/appref#handlers_element
Also you can check HTTP_HEADERS like referer, IP, user agent.
Also you can issue a token and pass/check it with every request.
There are probably a few issues being conflated here.
CORS - a browser enforced security measure to prevent pages maliciously or otherwise sending data to non-origin servers. Servers cannot enforce this, only permit it. Permitting this is an application level concern (i.e. Not built in to GAE)
XSRF - a server enforced security measure to stop authenticated users having their account abused by malicious client code. This is an application level concern (i.e. Not built in to GAE)
Authentication - identifying a user or client by some set of permissions. There is some support for this with GAE (cloud endpoints, provided identity service, requiring admin login), but it typically would also be an application level concern. In the case of authorizing a client (as opposed to a user) there is no built in support.
Authorization - different sets of access based on roles/permissions. Not built in.
Other solutions:
Using Host or Origin header - trivially outfoxed by someone implementing a curl request, or any application more sophisticated
API token - fine for server to server over https but trivially compromised when used on a published client (like a web page)
Your best bet is to leverage your framework and have user accounts.
If you don't want to do this, something like XSRF (token in a header and cookie) would be enough in the general case to ensure that a web client was responding to your 'app'. This only works if the client is a web browser though, same as origin/host.
No. There is no built-in logic in GAE for that. Any support would have to exist at the level of your application-specific request routing.
I'm sending simple messages to Google Analytics from a Silverlight app. They look something like this (data changed):
http://www.google-analytics.com/collect?v=1&tid=foobar&cid=foobar&t=pageview&dp=foobar&dt=foobar
Very simple API. If I use HTTP it works beautifully.
If I use HTTPS, I run afoul of Silverlight's cross domain policies. According to the docs, google-analytics.com needs to approve the cross-domain call by hosting either a clientaccesspolicy.xml (Silverlight-specific) or crossdomain.xml (original used by FLASH). Turns out they do host crossdomain.xml, and I can see that Silverlight downloads it (via Fiddler), but apparently Silverlight doesn't like the file's content and doesn't allow HTTPS calls to that domain (System.Security.SecurityException).
So.. at least at the moment, I can't use Google Analytics from Silverlight using HTTPS. Does anyone know a work around for this issue?
Note, I can't just use HTTP, because that causes IE to issue a "Allow Mixed Content" prompt which causes problems for some of our customers. I need to use HTTPS like the rest of our app.
EDIT: OK, I took a totally different approach, using HtmlPage.Window.Invoke to call a 3 line Javascript function to do the asynchronous send rather than using WebClient in the Silverlight code. Works like a champ. Anybody see any potential problems with that?
I suspect there may be a way to make this work, because I know google-analytics.com is very cross-domain friendly for exactly this reason.
If you absolutely can't get it to work another option would be to proxy the hits. If you do this, you'll want to make sure to use the ua and uip override fields in the hit you're sending so that they show up in Google Analytics with the IP address and User Agent of the original visitor and not your server.
Here's some more info on using a proxy server with the Measurement Protocol:
https://developers.google.com/analytics/devguides/collection/protocol/v1/devguide#using-a-proxy-server
Is it possible to access Rally's SOAP services from Silverlight? I am able to access the service from a .NET 2.0 proxy in a desktop application, but not via a WCF client proxy in Silverlight. I get the following familiar exception,
System.ServiceModel.CommunicationException:
An error occurred while
trying to make a request to URI .... This could be due to attempting
to access a service in a cross-domain way without a proper
cross-domain policy in place, or a policy that is unsuitable for SOAP
services. You may need to contact the owner of the service to publish
a cross-domain policy file and to ensure it allows SOAP-related HTTP
headers to be sent. This error may also be caused by using internal
types in the web service proxy without using the
InternalsVisibleToAttribute attribute. Please see the inner exception
for more details.
I believe the problem is caused by trying to make a cross domain request from Silverlight, which requires a cross domain policy file installed on the server. If this is the case, why does the desktop application not require such a policy?
I'm not a Silverlight expert, but this looks like a cross-domain scripting/security sandbox that Silverlight imposes to make sure that Silverlight clients don't make requests to sites other than the server/host from which they were downloaded, unless the Silverlight client is specifically granted that right by the service provider/devloper. In the error message above:
"You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent."
I think the "owner of the service" means the owner of the Silverlight host, rather than the "external" webservice (in this case, Rally).
Desktop and/or console apps wouldn't have this same sandbox restriction. You would probably encounter the same issue trying to access another vendor's webservices via a Silverlight client.
You might find this Silverlight-specific thread:
Cross Domain Policy
Helpful for the specifics of how to setup and configure a Silverlight cross-domain policy file on your server.
Silverlight was built with security in mind. That means cross site scripting from the Silverlight application is turned off by default and must be enabled on a case by case basis. A .NET desktop application, on the other hand, generally has far greater security permissions and can call whatever web services, COM objects, and native APIs it pleases.
The way you work around this issue in Silverlight is to create a service on your server. The Silverlight client code calls your server side service which in turn calls a third party web service. The server side service can bet .NET, java, whatever. Web servers can generally call whatever they like -- problem solved.
Resolved this myself by using the extended permission features available in Silverlight 5. Since the xap is deployed on an internal internet, this solution was acceptable.
I know the Google App Engine docs say you can only have HTTPS on your foo.appspot.com domain, not with a custom domain.
But is it possible (and safe) to host a custom domain somewhere else, and set it up to proxy all HTTPS requests to https://foo.appspot.com?
If so, how would you recommend setting it up? And would it be much slower, compared to using https://foo.appspot.com directly?
Yes, it's possible to do this. It's secure if you trust your proxy and you use SSL from the proxy to the app. It will be noticeably slower, since there's a longer path between your user and your app. In addition, unless you get multiple proxies, all your traffic will have to go via a single global location, whereas the appspot domain is served from frontends all round the globe.
I want to provide silverlight app to my customer while hosting the app at my own site for streamlined maintenance.
my Silverlight .xap is hosted in, let say, domain me-supplier.com
i want to embed it in, let say, domain my-customer.com
It works perfectly for http://my-customer.com, not for https://my-customer.com
i have added the (me-supplier.com hosted) cross domain silverlight policy file to allow my-customer.com
i have configured the mime types for .xap
the silverlight app needs html dom access so the iframe approach is not viable i believe.
this works for javascript code, so why not for silverlight ? any idea, workaround ?
Is the silverlight app also on https? If not, you might be hitting a security wall which does not allow to intermix http and https application domains
I think the answers to this question may explain it.
Generally HTTPS doesn't like you drawing data between domains within a page because the certificate is tied to the current domain.