asp:MediaPlayer (Silverlight) Https / http issue - asp.net

we have a site (https://oursite.net) in which we display a videostream hosted on http (http://someserver.com). The site needs to be hosted on https, and we don't control the video, so I'm assuming it needs to be on http. we recently added the option to play the stream through the silverlight asp:MediaElement, which works perfectly fine in our test environment (on http) but doesn't work in production (https).
The info on the web is somewhat confusing as I'm having a hard time differentiating between how this stuff worked at different stages in the silverlight development (seems to have been a bit to and fro)
Is this setup possible at all (hosting the player on https but playing a stream on http) with some sort of policy file?
in that case: does this policy file need to be hosted with the silverlight app (on https) or where the streams are located (http)
Thanks for your time
Andreas

You are running into a cross-scheme violation unfortunately. The stream would need to match the same scheme (https) as the hosting application. Unfortunately most streaming isn't available in HTTPS.

Can you check the enableHtmlAccess property on the object tag to make sure it is true? Most media players end up using the HTML DOM bridge to communicate with the web page.
It's also likely that there is a cross-scheme issue: you should try and optimize for all assets being on the same scheme (HTTP or HTTPS).

Related

No need for HTTPS at all, but there seems to be no other way from the web browser

Given a web application running over an HTTPS connection. It also has to communicate with a Java application on the local area network.
This server is literally in the same room with the PC on which the web app is running, a simple HTTP connection would be completely fine between the two, but since the web app is running over HTTPS, the browser forces the HTTPS.
It's already stupid and a big overkill that I must employ an HTTPS server in the Java application just because of that, but still now it doesn't work yet, because now the browser is complaining about the certificate that it is self-signed..
I mean, do I really need to purchase an SSL certificate so two of my computers in the same room can communicate over HTTP? Even if I wanted I couldn't. There's not even a fix domain.
I'm confused, is there a way around?
UPDATE:
The web application is served from the Internet, that's why the HTTPS connection. Whereas it should receive data from a Java application running locally. Hundreds of megabytes in every couple of minutes (confidential medical images) so sending all that through a proxy is not really an option.
I also wanted to avoid the need of any manual configuration from the user's side to make the communication work (like importing a certificate into the web browser and similar) but maybe I have no other option.

Windows Azure VM SSL and Cloudapp.net

I installed an ASP.net application on a windows Azure VM (IIS 7). SSL certificate is installed, configured and the application works correctly. I have removed Http binding and http endpoints.
The issue I am having is that if I use the cloudapp.net link (using https), the application still opens with a mismatched certificate.
What can I do to deny any user from opening my application using https://xx.cloudapp.net/x?
It seems really silly that people are saying this isn't the right place for this question, since some of the solutions could be code related. ie: In your application, check the host and if it's cloudapp.net, do a URL redirect.
There's a few different options here but it sounds like what you're looking for is just the ability to prevent someone from viewing the application using that URL.
What I would do is set up a site in IIS that uses Host Header resolution to look for xx.cloudapp.net. If that URL is recognized, do a redirect using the HTTP redirect settings to the https version of your app. Don't bind the SSL port to this site or you'll run into SSL errors like you showed above.
The other option is to leave it out entirely and simply use the Host Header resolution to filter out requests for your site. I suspect what you've done is assign all incoming requests to the only IP address on the system, which is why the xx.cloudapp.net is showing your app and the cert is failing.
This would cause xx.cloudapp.net to fail to show any site at all but I think that might be what you want to do anyway.

google hosted scripts , use http or https?

I am using google hosted javascripts libraries,(jquery ,jquery-ui & other google jsapi),and I noticed that these scripts can be accessed by both http & https schema.Now ,I want to know that what are the effects of using http or https schema to access these google hosted scripts , and for my projects ,it's just an ordinary websites ,using http as default schema, so ,what should I do ,http or https? Is there any performance issue between the two ?
https does affect performance negatively, as encryption and security negotiation aren't trivial tasks. In the vast majority of cases this performance cost is not significant enough to outweigh its benefits.
Remember that SSL also secures the identity of the web server and not just the channel.
If a "man-in-the-middle" spoofed the address of your script's location (for instance), https would prevent you from unknowingly executing unintended scripts. http would not.
Check this out: HTTP vs HTTPS performance
The performance issue is rather small considering todays hardware and internet bandwidth. Personally I try to use the same protocol for all data used by one page (or iframe / frame), meaning scripts, CSS, images etc.
Data transferred over SSL will not be cached by the visitor's browser, instead will be downloaded each time a page is loaded.
Using SSL / HTTPS is recommended if a page contains sensitive data, personal data, or offers interactions like contact forms etc. Buying and installing a SSL certificate is justified in those cases.
Google analytics for example first checks which protocol your page uses, then uses the same protocol for downloading its scripts.

deploying asp.net MVC 1.0 app with HTTPS

We have an application built on ASP.NET MVC 1.0 which, once deployed, should be accessed with HTTPS. I tried few approaches for HTTPS but I have a few questions.:
My home page does not need to be Secured (HTTPS), but rest of the hyperlinks following it will be Secured.
I read about the action method attribute [requiresHTTPS] however I want to understand what happens to that tag during development on local machine.
In a development enviroment, how do I install a certificate on a dev machine/virtual directory to code and test my changes.
So this application is complex in nature and we have around 13 controllers and 50 action methods. This application will have information like Credit card numbers since we do accept payment through this website.
Thanks much !
If it is just about a few static pages of your application that don't need to be secured, I would strongly recommend to simply require SSL for everything by configuring two different sites in IIS, one for the actual page only on port 443, one on port 80 with a permanent redirect.
Advantages:
Your application and code doesn't have to know anything about SSL, and you don't need a SSL certificate on your dev machine. The web server does it all for you.
No cookie and HTTP caching mess with the HTTP/HTTPS flip-flop
If security/privacy matters, it's the best solution anyway to require SSL for all pages.
Regarding the possible disadvantage: serving a few requests on static resources via SSL is probably almost no overhead, compared to the rest of your application.

Fiddler not sniffing SOAP traffic from ASP.NET website

So far I've been successfully using fiddler to sniff web service traffic from both test fixtures, console apps and web projects.
Today I noticed I am not able anymore to sniff that kind of traffic if I am running my web application (it's a ASP.NET website, hosted locally on IIS). I see all the local traffic but the web service traffic is just gone (the service is being hit as I do see the response debugging into the code).
I am still able to successfully sniff soap requests and responses from test fixtures or console apps in the same solution (exact same environment).
If it was a windows (I am on Win7) security update or the likes it would never work I guess (unless it affects only traffic routed through IIS).
What should I be looking for that could cause the emergence this behavior?
Any pointers appreciated!
NOTE: I can see local traffic, but not the SOAP request/responses to the web service which is not hosted locally anyway (it's a sandbox another team is providing)
EDIT: This bit of configuration did the trick (found on Rick Strahl's blog)
<system.net>
<defaultProxy>
<proxy
usesystemdefault="False"
bypassonlocal="True"
proxyaddress="http://127.0.0.1:8888"/>
</defaultProxy>
</system.net>
What's the client of the web service? ASP.NET?
ASP.NET traffic isn't proxied unless you configure ASP.NET to use a proxy. It's possible/likely that the app.config or machine.config changed such that traffic is no longer getting proxied?
You should have a look at this section: http://www.fiddlerbook.com/fiddler/help/hookup.asp#Q-DOTNET
If you want to view the http traffic between your web site and your web service on your development machine, and don't want to change your machine.config.
One easy solution is to change the Application Pool Identity of your web site to use your own credentials of the current logged on user. This means that your web site will adopt your proxy settings and will now redirect to Fiddler.
Make sure the web service you are calling (from IE) is not http://localhost/yourwebservice
Fiddler will not intercept localhost traffic from IE, use http://machinename/yourwebservice instead.
I ran into this issue a week or so ago. Try this page: http://docs.telerik.com/fiddler/Observe-Traffic/Troubleshooting/NoTrafficToLocalhosthttp://www.fiddler2.com/fiddler/help/hookup.asp#Q-LocalTraffic
The ipv4.fiddler was the part that worked for me. Hope this helps.
You're probably using a port other than 80 for these http requests. I remember setting up a reverse proxy to look at WCF requests I was making on my local machine during dev. Here's the documentation:
http://www.fiddlertool.com/fiddler/help/reverseproxy.asp
Can you try the following -
Try stopping the windows firewall and see what happens
try using firefox and redirecting traffic to fiddler and see what happens

Resources