in the light of facebook's imminent switch to HTTPS (yes, i'm late to the party),
i have some questions around AS3 and HTTPS / HTTP.
so my understanding is that facebook is going to serve up html from an https address,
and in the html is an iframe with the URL of our .swf file.
i assume that we'll have to be able to server that .swf file via https, and that seems reasonable.
my questions are more around what happens within flash once the .swf is running.
we have many requests to our backend via HTTP, and we also periodically open up a raw socket also into our backend.
is flash/the browser going to give us grief about that socket or those http requests ?
thanks in advance,
orion
Related
I have a project that run in local server, i need to record the user audio but the browser not allowed the microphone without https, there have chance to do this in local server without https ? thank you before , and sorry for the bad english language
I have a project that I have to inject Javascript into websites using the browser. I mean that I go to developer tools -> console -> enter the following:
window.FO_DEBUG=true;
var b=document.getElementsByTagName("head")[0].appendChild(document.createElement("script"));
b.src="//path-to-file//"
The issue is that I cannot inject code from my local machine for HTTPS websites.
The only way I found to do it is to inject a file from another HTTPS server.
Do you know any way of injecting a file from my local machine to an HTTPS server?
It's possible to inject scripts to HTTPS websites as long as the origin of these scripts is HTTPS server.
Therefore, the easiest way to do it is to create a local HTTPS server, and inject the script from this https server.
The following videos show perfectly how to do it:
https://www.youtube.com/watch?v=zTlc5Z59FpA&t=208s
https://www.youtube.com/watch?v=VbNPi2gaJpU
We're using the HTML5 Application Cache feature:
<html manifest=".appcache">
...
</html>
When returning users navigate to this application they will already have all static files cached and the application is therefore loaded without network requests.
Once the application is loaded it will make AJAX requests to load dynamic content, and the browser will check whether the Application Cache manifest is outdated and possibly download a new version of the application in the background.
Many of our users are accessing this application over insecure connections (HTTP, not HTTPS).
We're in the process of introducing HTTP Strict Transport Security (HSTS) on the servers that host the application.
Implementing HSTS means that our servers will handle requests like this:
If the request is insecure (HTTP only), then the server will respond with HTTP status 301 and a Location header that redirect to the requested URI but changing scheme to https.
Otherwise; if the request is secure (HTTPS) the server will process it as normal but decorate the response with a Strict-Transport-Security header.
So, when a new user open up our application over HTTP they will be redirected to HTTPS instead and then the application cache manifest is installed using the secure location. That's perfect.
However, a returning user (over HTTP) will NOT be redirected to the secure location (because they already have a cached version on the insecure location). The application cache manifest won't load (since it's a redirection). So returning users are stuck with the application version they had cached and they're stuck using HTTP which is no longer allowed. This is very bad.
We need to come up with a way to transition returning HTTP users to the HTTPS version. How would be best do that?
The way I see it there are two problems:
The browser cannot fetch the application manifest (because it is a redirection). It is therefore unable to upgrade the application to a new version.
We could perhaps overcome this problem by configuring our servers to allow /.appcache to be served over plain HTTP.
Even if we do that, the application will still be accessed at the HTTP location (since that what's cached by the manifest)
To workaround that, we might have to implement some kind of javascript logic that changes the scheme of document.location.href to HTTPS.
I don't like this approach, but it's the only one we've got at this point.
We settled on the following solution to this problem:
When server receive an insecure request to get the application cache manifest (/.appcache in our case), then a 404 response is returned instead of the normal HTTPS redirect (301).
Getting a 404 causes the cached manifest to be stale and the browser will therefore attempt to reload the application on the next refresh, which will cause it to fetch index.html and be redirected to the secure location.
Our system uses an AWS Elastic Load Balancer.
We are encountering a maddening issue where our HTML video tags are failing to play randomly. I can't reliably reproduce the issue unless I bypass the ELB, which makes me suspect it, naturally.
I've verified that the same files are on both of our IIS servers, and I have verified that the MIME types are the same on both.
The video files are H.264 MP4s, but they will sometimes work, so I don't think it has anything to do with Chrome's support of the codec.
Anybody have an idea on what I can do, or where to look next?
This is a session issue on the AWS ELB. Enable the Sticky Sessions on the ELB and this issue will be resolved. Here is the developers guide.
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html
I would enable full logging on both IIS and the ELBs, and carefully check the access logs on each to confirm.
You would expect to see a 200 http response code on the ELB and the IIS server for each request made. Check for any requests that result in a 400 or 500 error. You need to pair each individual request from the ELB to the IIS server and review.
See Monitor Your Load Balancer Using Elastic Load Balancing Access Logs
How do you tell if a site is an HTTP:// site or an HTTPS:// site? I am just starting to learn some of the more fundamental things about internet security. When you put up a web site is there a special way that you have to set up the html format in the .html files so that the site is secure or is this something that can be purchased from the site provider were you host the web site.
This seems like and easy thing to do but even on stackoverflow what it type in is
stackoverflow.com/questions/ask
There is no HTTP or HTTPS in front of the internet address. Is this implied or is there a way to toggle this on an off in the tools?
HTML Code:
<html lang="en">
<head>
<title>Test Title</title>
</head>
<body>
//...code goes here...
</body>
</html>
Is there something that goes in the HTML that determines whether the site is secure or not? Or is this an option on each page when you host the site.
How do you tell if a site is an HTTP:// site or an HTTPS:// site?
By looking at the URL
This seems like and easy thing to do but even on stackoverflow what it type in is
If you type in something that looks like a URL with the scheme missing, then browsers will assume you intended to put http:// in front of it.
Most browsers will hide the http:// part from the address bar for non-SSL sites.
When you put up a web site is there a special way that you have to set up the html format in the .html files so that the site is secure or is this something that can be purchased from the site provider were you host the web site.
To use SSL you need to have an SSL certificate and the web server needs to be configured to use it.
Beyond that, everything comes down to how the server is configured. You could have different sites hosted on http and https, or the same site, or redirect from one to the other, and so on.
Is there something that goes in the HTML that determines whether the site is secure or not?
No. SSL is dealt with at the transport level, not the document level.
Or is this an option on each page when you host the site.
You could configure a server to redirect the URLs for some pages to HTTPS and some to HTTP. This was typically done to save on CPU power for pages where security wasn't needed. Today, CPU power is much cheaper, so it is normally better to use SSL by default.
To make a site secured (an HTTPS) site you need a certificate and add the proper binding that means including a port and protocol by default https uses port 443 and NO, none of those configurations at server level will affect the files serve like your .html files.
HTTP means Hypertext Transfer Protocol. The "S" is Secure.
There is no special definition you can define to ensure a secure HTTP connection.
SSL (Secure Sockets Layer) is the standard security technology for establishing an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browsers remain private and integral.
These certificates can be purchased from companies that provide them. This essentially encrypts any data transferred between the server and person it is responding to.
In short, this is determined by the browser, and different browsers have different strategies.
When you visit a site, such as www.abc.com, different browsers will use different default protocols.
Microsoft Edge will first use http to connect to port 80 of the server. If the server is set to redirect, it will send a 301 move permanently message to allow the client to reconnect to the site using https.
But the new version of chrome will directly use https to connect to the site (port 443), if the connection fails, then connect to http (port 80).
https://blog.chromium.org/2021/03/a-safer-default-for-navigation-https.html
Chrome will now default to HTTPS for most typed navigations that don’t specify a protocol. HTTPS is the more secure and most widely used scheme in Chrome on all major platforms. In addition to being a clear security and privacy improvement, this change improves the initial loading speed of sites that support HTTPS, since Chrome will connect directly to the HTTPS endpoint without needing to be redirected from http:// to https://. For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails (including when there are certificate errors, such as name mismatch or untrusted self-signed certificate, or connection errors, such as DNS resolution failure). This change is rolling out initially on Chrome Desktop and Chrome for Android in version 90, with a release for Chrome on iOS following soon after.