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.
Related
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.
We have an intranet server that hosts many web applications / web services in various virtual directories all located under the default web site in IIS6. These all just use http connections on port 80 e.g. "http://ourintranetsite/applicationname" or "http://ourintranetsite/servicename" etc.
We have a new web service that we have deployed to a virtual directory under the default web site and it works fine using an http connection. One issue has arisen now that we are starting to use SharePoint Online. We want to be able to call this web service from some client site script on a SP Online page, but it is causing an issue because the SP Online page is using https, so it doesn't like calling a web service over http (IE just puts a warning message in the browser console, but Chrome refuses to make the call at all).
Is it possible to configure just the virtual directory hosting this web service to require an SSL connection rather than setting it at the web site level? We really don't want everything under the default web site to start requiring https, just this particular service. Obviously I could just tick the "Require secure channel (SSL)" option in the properties of the virtual directory, but from what I understand (I've not had to use SSL before), the default port for that will be 443 while the website is using port 80. Ideally we'd just like to be able to get to the service with something like "https://ourintranetsite/secureservice/..." while not impacting any of the existing http applications and services.
No it's not possible to assign a certificate to virtual directory, however when you add a cert to the website all it does makes the site brow sable over https but that doesn't mean that it has to be browsed only over https.
What I meant is you can have site to be brow sable over http and https. Add the necessary cert to the site and make sure you do not check "Require secure channel (SSL)" and it should be good to go.
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.
I have very recently started development on a multiplayer browser game that will use nowjs to synchronize player states from the server state. I am new to server-side development (so many of the things I'm saying are probably being said incorrectly), and while I understand how node.js works on its own I have seen discussions about proxying HTTP requests through another server technology (a la NGinx or Apache) for efficiency.
I don't understand why it would be beneficial to do so, even though I've seen plenty of explanations of how to do so. My current plan is to have the game's website and info on the same server as the game itself, so if there is any gain from proxying node I'd love to know why.
In the context of your question it seems you are looking for an answer on the benefits of implementing a reverse proxy in front of your node.js webserver. In summary, a reverse proxy (depending on implementation) can provide the following features out of the box:
Load balancing
Caching of static content
Failover
Compression of responses (e.g gzip)
SSL support
All these features are cross-cutting concerns that you should not need to accommodate in your application tier/code. By implementing these features within the proxy it allows you to focus on developing the code for your application and leaves the web server to do what it's good at, serving the HTTP requests for your application.
nginx appears to be a common choice in a reverse proxy/node configuration and if you take a look at the modules reference you should get a feel for what features the proxy can provide.
When you say "through another technology" I assume you mean through a dedicated web server such as NGinx or Apache.
The reason you do that is b/c in a production environment there are a number of considerations you don't want your application to have to do on its own. Caching, domain (or sub-domain) mapping, perhaps security, SSL, load balancing, and serving static files to name a few.
The web servers are already built to do all those things for you, and so they can handle them and then pass only the requests on to your app that actually need to be handled by your app. They're also optimized for doing those things and will probably do them as well or better than the average developer can.
Hope that helps.
Another issue that people haven't added in here is that with a front-end proxy, when you need to take your service down for maintenance (or even just restart it), nginx can serve up a pretty "YourCompanyName is currently under maintenance" page, making for a much more pleasant user experience.
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).