I have an application that was recently given an AWS certificate (and put in an ELB - classic I think).
The web application has a Flash movie that makes web calls (to same site URL) in order to fetch data using Zend Framework 1 models. The page in browser does not change.
When I request the site over https, all of the imported items have been changed over to https protocol, but when the Flash movie initializes, it makes non-secure requests over http.
It makes these non-secure requests when I load the site over http, or https.
The reason I mentioned the AWS ELB is because I was told that the ELB is doing some kind of redirect to port 80.
If I request the site over https, and immediately do print_r on $_SERVER array I am only seeing HTTPS as a REDIRECT key, and not seeing $_SERVER['HTTPS'] set, which I think is important.
In summary, the Flash movie, inside a Zend 1.12 site, is making POST requests over http, and I'd like it to make the same requests, but over https.
It is a very old Flash movie, and although I've opened the swf file with a decompiler, I do not know much about actionscript to see where (in the many code files) I'd be able to instruct the movie to call https instead of http.
My theory is that when the site is properly running as SSL/https that the flash movie may ?possibly? start making https calls since at the moment is "is" using the address bar URL, but there also could be that ELB redirect stuff happening that's gumming it up as well.
Update: I found (what appears to be) evidence that if https is detected in the URL it's given, that it will then make secure requests...
FILE: mx.rpc.remoting.RemoteObject
mx_internal function initEndpoint() : void
{
var chan:Channel = null;
if(endpoint != null)
{
if(endpoint.indexOf("https") == 0)
{
chan = new SecureAMFChannel(null,endpoint);
}
else
{
chan = new AMFChannel(null,endpoint);
}
channelSet = new ChannelSet();
channelSet.addChannel(chan);
}
}
Thanks,
Adam
I was able to restore the original/old unedited Flash SWF File, and instead modified the PHP Code that passes in a variable and value called "endpoint".
In the code sample I provided, it checks if endpoint has https in it (which I initially thought that it did).
I added code to modify the value of "endpoint" when HTTP_X_FORWARDED_PROTO was "https", sample below: (the $request->getBaseUrl() is from Zend Framework).
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
$endpoint = sprintf(
'%s://%s%s',
$_SERVER['HTTP_X_FORWARDED_PROTO'],
$_SERVER['HTTP_HOST'],
$request->getBaseUrl()
);
} else {
// use existing (and working) value for endpoint
}
With that code in place, the FLASH movie loads in, and operates properly
whether site is loaded with http or with https
Related
I've uploaded a new static blog to GitHub Pages using Ghost and Buster.
Github Repo: https://github.com/paddy420Smokers/cannalogie
I've added the code below to force all pages to use https:// , on the Frontpage and Category Pages its working fine, but on Posts only https:// is there but it's not fully secured.
<script>
var host = "cannalogie.net";
if ((host ==window.location.host) && (window.location.protocol != "https:"))
window.location.protocol = "https";
</script>
Does anyone know how to fully secure all pages and posts?
Looking at the developer tools, it looks like you're loading something that over http while the rest of your page is loaded over https. That causes the whole page to be considered insecure and not show the lock symbol, even if the url shows https.
It looks like you're loading a .gif over http. If you change the url to load it over https, the error should go away and the lock should appear.
I currently have two web apps that are set up in cloudflare with the following CNAMEs. Both are keystonejs applications.
app1.example.com ===pointing to ===> AWS ALB 1
app2.example.com ===pointing to ===> AWS ALB 2
I have Cloudflare Enterprise set up, so i'm able to use the "Render Override" feature in my page rules. I have 2 page rules set up using the following:
www.example.com ===render override ===> app1.example.com
www.example.com/app2/* ===render override ===> app2.example.com
Now in order to access the keystonejs application on app2.example.com. The application is called using app2.example.com/pa
The problem that i'm facing is that render override doesnt allow me to use sub paths, and i do not want to use the forwarding rule. Do i need to make my keystone application accessible through the root url, namely app2.example.com/ ? or is there another way to do this? Otherwise, would i need to use a reverse proxy? such as nginx ?
Thanks
Note: Since you are an enterprise customer, I highly recommend contacting your Customer Success Manager and/or Solutions Engineer at Cloudflare. They are there to help with exactly these kinds of questions. That said, I'll answer the question here for the benefit of self-serve customers.
I think when you say "Render Override" you actually mean "Resolve Override". This setting changes the DNS lookup for the request such that it is routed to a different origin IP address than it would be normally.
Note that Resolve Override does not rewrite the request in any way; it only routes it to a different server. So, a request to www.example.com/app2/foo will go to the server app2.example.com, but the path will still be /app2/foo (not /foo), and the Host header will still be Host: www.example.com.
It sounds like in your case you really want /app2/* to be rewritten to /pa/*, in addition to redirecting to a different origin. You can accomplish this using Cloudflare Workers, which lets you execute arbitrary JavaScript on Cloudflare's edge. Here's what the script might look like:
addEventListener("fetch", event => {
event.respondWith(handle(event.request));
});
async function handle(request) {
let url = new URL(request.url) // parse the URL
if (url.pathname.startsWith("/app2/")) {
// Override the target hostname.
url.host = "app2.example.com"
// Replace /app2/ with /pb/ in the path.
url.pathname = "/pb/" + url.pathname.slice("/app2/".length)
// Send the request on to origin.
return fetch(url, request)
} else {
// Just override the hostname.
url.host = "app1.example.com"
// Send the request on to origin.
return fetch(url, request)
}
}
With this deployed, you can remove your Resolve Override page rules, as they are now covered by the Worker script.
Note that the above script actually does rewrite the Host header in addition to the path. If you want the Host header to stay as www.example.com, then you will need to use the cf.resolveOverride option. This is only available to enterprise customers; ask your CSM or SE if you need help using it. But, for most cases, you actually want the Host header to be rewritten, so you probably don't need this.
I have an asp.net 5 MVC 6 site I am working on. I turned on require HTTPS like so:
services.AddMvc(options =>
{
options.Filters.Add(new RequireHttpsAttribute());
});
It worked great, and I have been working like this for a little while. Today I need to turn it off, so I commented out the options filter, but it is still requiring HTTPS.
I have not used the [RequireHttps] attribute on the controllers or actions themselves.
I have gone into the properties and unchecked "Enable SSL" and pasted the http url in the "Launch URL" box.
I have shutdown IIS Express and relaunched the site. It doesn't seem to matter what I do, it continues to try to redirect to HTTPS.
Is it possible IIS Express or Kestral has cached something I need to delete?
Anyone have any suggestions of what else could be forcing it to HTTPS?
The RequireHttpsAttribute implementation will send a permanent redirect response (301) back to browser:
// redirect to HTTPS version of page
filterContext.Result = new RedirectResult(newUrl, permanent: true);
This means that when you initially had the attribute enabled and requested a url like http://localhost:62058/, the server will respond with:
301 (Moved permanently)
Location: https://localhost:62058/
If you look at the definition of the 301 response code you will see that browsers will cache it by default:
The requested resource has been assigned a new permanent URI and any
future references to this resource SHOULD use one of the returned
URIs. Clients with link editing capabilities ought to automatically
re-link references to the Request-URI to one or more of the new
references returned by the server, where possible. This response is
cacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to the
new URI(s).
After you remove the RequireHttps filter, the browser will still use the cached response:
So all you need to do after removing the RequireHttps filter is rebuild and clear the browser cache!
I am using the RequireHttps attribute on most of the actions in my User controller which handles the login and my secure https pages.
On my Home Page which is http I have a link to my login page as follows (MVC 4 Razor View):-
Login
The link correctly goes to the login page with an https address. However, when I look in the IIS log I see there are two entries for the login URL, one on port 80 and one on port 443.
Is this an issue I should be concerned about?
I know on my #Url.Action I could force https mode, but not sure if this is the best way. Plus this removes the port, which is annoying when using IIS Express in VS 2012. I'd then have to further extend the #Url.Action to include the hostname:port.
So I am just checking if (a) this should be a concern and (b) if it is a concern whether there are any other ways to forcing the URL to https.
Most tutorials will agree that by having a mixed mode site (both HTTP and HTTPS) you're defeating the purpose of SSL (having certain paths require SSL then switching back to a non SSL connection). Once you switch to HTTPS it's recommended that you force the user to stay using HTTPS for everything, at the very least until they logout. I have one site that uses HTTPS and once you hit the site, I just use a URL Rewrite rule to switch the user to HTTPS, and only HTTPS is allowed.
<rewrite>
<rules>
<rule name="Redirect HTTP to HTTPS" stopProcessing="true">
<match url="(.*)"/>
<conditions>
<add input="{HTTPS}" pattern="^OFF$"/>
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="SeeOther"/>
</rule>
</rules>
</rewrite>
Once you do this it's also recommended to set the authentication cookie to require HTTPS as well. For Forms authentication this is as simple as setting the following in your web.config.
<authentication>
<forms requireSSL="true" />
</authentication>
I would also recommend looking at some of the Headers that can be set to help browsers treat the site correctly, like using Strict-Transport-Security to signify that the site requires SSL. Keep in mind that while Headers are a great supplemental measure you can take, ultimately they are left for the browser to enforce and should not be relied on exclusively.
I recommend these steps because I don't suffer from the symptom you're describing and am hoping they'll help resolve the issue you're noticing in the logs.
AMMENDMENT: Oh and I also forgot to mention, HTTPS is a little more intensive to establish a connection with than plain old HTTP. Not much in the grand scheme of things but still it's something. I'd recommend you utilize HTTP Keep Alive so as to reduce some of that overhead.
UPDATE: Communicating over SSL doesn't imply that you are authenticated. It just means you're talking over a secure/encrypted connection.
Take your Amazon example lets say. If you visit the site, you'll like get just a normal connection over HTTP. You're aren't logged in you're just browsing the site. If you wanted you could switch to HTTPS and you'd still get the same site but you're not logged in yet. Now if you try to login you'll get redirected so that you talk over SSL (if you're not already) as noted by the HTTPS moniker. Even after you actually login you will still be communicating over SSL. Even if you try to manually switch to not using SSL while you are logged in by removing the S from the protocol part of the URL, it'll still send you back to using HTTPS. This is the correct way of doing it. It's generally suggested that you not return to a non encrypted session after authenticating. This is typically to avoid session hijacking since your authentication cookie would never be sent over plain HTTP. Make sure the resources you have on external sources, are on sites that you trust. External resources access while in a HTTP connection should also be over an SSL connection. Again just because you communicate over SSL doesn't mean you're logged into those sources. For my app is 100% access over SSL, but I also have Google analytics and Google maps integration on the site (obviously both are external to my domain). I just make sure that I talk to Google over SSL. I don't have to actually be logged into Google to use any of those things. The same goes for your external images. Just make sure your URL's used to reference those external images are defined using the HTTPS moniker so that it uses SSL.
UPDATE: The reason you're getting two hits in the log like that is because you're login link is being requested over HTTP, the Require HTTPS attribute hits first realizes you're not using SSL and redirects you back to itself with the HTTPS protocol. If you update your ActionLink URL you can get around this, but as you know it gets ugly.
Url.Action("Login", "User", null, "https", Request.Url.Host)
Add this to your global.ascx
protected void Application_BeginRequest()
{
if (!Context.Request.IsSecureConnection)
Response.Redirect(Context.Request.Url.ToString().Replace
("http:", "https:"));
}
This will cause all the requestes to be converted to https instead of http
I write an extension for Url.Action that generate the right protocol depending on the Attribute decooration. I let you check
public static class Extensions
{
public static string SecuredAction(this UrlHelper helper, string action, string controller)
{
bool requireSSL = false;
var route = System.Web.Routing.RouteTable.Routes.Select(r => r as System.Web.Routing.Route) .Where(r =>
r != null && r.Defaults != null && r.Defaults["controller"] != null && r.Defaults["controller"].ToString().Equals(controller, StringComparison.InvariantCultureIgnoreCase)
&& r.Defaults["action"] != null && r.Defaults["action"].ToString().Equals(action, StringComparison.InvariantCultureIgnoreCase)).FirstOrDefault();
if(route == null)
return helper.Action(action, controller);
//Get the method and check if requiere ssl
MemberInfo method = route.DataTokens["TargetActionMethod"] as MemberInfo;
requireSSL = method.CustomAttributes.Any(a => a.AttributeType == typeof(RequireHttps)) || method.DeclaringType.CustomAttributes.Any(a => a.AttributeType == typeof(RequireHttps));
//Return the correct protocol
if(helper.RequestContext.HttpContext.Request.IsSecureConnection && !requireSSL)
return helper.Action(action, controller, null, "http");
if (!helper.RequestContext.HttpContext.Request.IsSecureConnection && requireSSL)
return helper.Action(action, controller, null, "https");
return helper.Action(action, controller);
}
}
I'm loading Disqus on a page loaded via HTTPS with the following code, as suggested in this answer.
<div id="disqus_thread"></div>
<script type="text/javascript">
var disqus_shortname = 'our-shortname';
(function() {
var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
dsq.src = 'https://' + disqus_shortname + '.disqus.com/embed.js?https';
(document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
})();
</script>
Note that I've changed the request of embed.js to be https rather than http, and I've added ?https to the end of the request too, which I believe is supposed to force HTTPS.
The initial request goes via HTTPS as planned, but it makes a secondary request via HTTP, which Chrome is hating (I get the red cross over padlock icon).
From the Chrome console:
The page at https://our-website.com/blog-post-name ran insecure content from http://juggler.services.disqus.com/event.js?thread=635675380&forum=our-shortname...[long query string]
Is this the correct method to get Disqus to use ssl on all requests, or have I missed a step?
Thanks.
This looks to be an issue within Disqus itself. We had Disqus working fine via SSL with the same approach in a couple of Drupal sites, but both recently had Disqus begin causing SSL warnings in both IE and Chrome as you've described.
I did a bit of digging, and I see that the DISQUS.useSSL function that's defined in embed.js and called in thread.js updates a few URLS (specifically ["disqus_url","realtime_url","uploads_url"]) in the Disqus json settings object by replacing http in their URL with https if https is found in the settings. The juggler_url doesn't get the same treatment, and so it's not updated to load via SSL. I'm not sure what juggler's purpose is, but it appears that that URL (http://juggler.services.disqus.com/) won't load via SSL in any case, so even if it's url was changed to https, it still wouldn't work.
So perhaps Disqus has made a recent change, since we had this working previously? We're taking this up with them, since this doesn't appear to be a config issue on our end...
UPDATE:
Apaprently Disqus launched a new service that does not support SSL. This is what's generating the extra scripts that get loaded insecurely, thus triggering the security warning. Disqus disabled this new service (which they didn't tell us the name of) for our specific account, and now SSL is once again working as expected. So, the solution is to just ask them to make your account SSL compliant, and that should take care of it.
Found this article, which hands the solution:
http://help.disqus.com/customer/portal/articles/542119-can-disqus-be-loaded-via-https-
Basically it's not possible (yet) with Disquss 2012, but switch it off and change the embed src so it uses https:// and add the ?https param:
dsq.src = 'https://' + disqus_shortname + '.disqus.com/embed.js?https';
I have had this problem off and on for the past few months and have been forced to disable Disqus altogether. Initially I contacted Disqus to see if they could make the switch that disabled the non-SSl compliant feature on their side and this worked for a while but the mixed content problem kept re-occuring.
What seems to happen is that despite Disqus forcing the https version of its count.js javascript, count.js still redirects to mediacdn.disqus.com instead of securecdn.disqus.com for some reason. If one appends ?https manually in the plugin editor to force the redirect to the securecdn.disqus.com, the problem disappears in the first call to the CDN but in subsequent calls to the CDN with the query string ?https added to the count.js call, the redirect just reverts back to mediacdn.disqus.com. I've tried this numerous times.
The annoying thing about this issue is that the SSL page in question on my site creating the mixed content notification does not even have a comment section. So Disqus is loading its javascript needlessly on the page.
I like Disqus but it's unbelievable to me they wouldn't fix this issue by either allowing users to disable the javascript selectively or by implementing a secure cdn version that works in all cases. I am hoping they figure this out.
Also they told me that Disqus 2012 doesn't support HTTPS (although it will be in the future).
Apaprently Disqus launched a new service that does not support SSL. This is what's generating the extra scripts that get loaded insecurely, thus triggering the security warning.