I have been having an issue with my rails app not generating https assets. I have set config.action_controller.asset_host equal to https:// version of my cloudfront assets but I still seem to get:
Mixed Content: The page at URL was loaded over HTTPS, but requested an insecure font 'http://cloudfront.net/assets/fontawesome-webfont'. This request has been blocked; the content must be served over HTTPS.
I have set cloudfront to https only but it still seems to be generating the http version. I can see where it sets the fontAwesomePath but I can't seem to find where it is being included.
I am uncertain as to why it is still being delivered as an http resource and would appreciate any advice
Much Appreciated
chaddpaul
Related
I installed TFS 2017 to be accessible on both, HTTP (port 8080, default settings) and HTTPS. Now I removed HTTP binding form the IIS and reapplied the Public URL (via Administration Console -> Change Public URL).
Most of the TFS application tier works normally (as it uses relative addressing). However, build extensions somehow want to get their icons from HTTP (port 8080). See screenshot. When I noticed this, I first checked the HTML/JS source and I found that _vssPageContext variable still holds some URLs pointing to old HTTP configuration.
Has anyone solved that mistery or has any idea what to do?
EDIT: Later I re-enabled the HTTP bindings in IIS just to make the TFS work and I get a lot of warnings and errors due to HTTP / HTTPS mixup (I access TFS via HTTPS, however some content is still accessed via HTTP):
Mixed Content: The page at
'https://xxxx.xxxxx.xxxx/tfs/TFSDefault/Project/_build/definitionEditor?definitionId=113&_a=simple-process'
was loaded over HTTPS, but requested an insecure image
'http://xxxx.xxxxx.xxxx:8080/tfs/TFSDefault/_apis/distributedtask/tasks/9fcb05af-0ffe-4687-99f2-99821aad927e/0.1.1305/icon'.
This content should also be served over HTTPS.
WebSocket connection to
'ws://xxxx.xxxxx.xxxx:8080/tfs/signalr/connect?transport=webSockets&clientProtocol=1.5&contextToken=412c3608-de3b-4dab-a00d-bf5c13728d97&connectionToken=OoSymcl1qzWg%2BrHB9pzSBpb%2BdHVywo7NNUWN5xMx3Z51p9ZdZQ14wvoQKXqxB%2Bvo66eTap4iUdlqzHR1hJNUf%2By8oFUaudlkCbQIZjHQhLBHsEWtcLdfLlL7MAevl4h0My1yQA%3D%3D&connectionData=%5B%7B%22name%22%3A%22builddetailhub%22%7D%5D&tid=7'
failed: HTTP Authentication failed; no valid credentials available.
This is an issue related to the default endpoint of TFS being initially set as http, which all the elements are then defaulting their requests to, rather than relying on the initial request you are making in the browser. so you end up with a javascript element attempting to connect to the server via http and get a cross content issue.
Here is a really good article that covers the issues you are probably facing and how to fix them to use https: https://hybriddbablog.com/2017/12/16/changing-tfs-to-use-https-update-your-agent-settings-too/
I have to caveat that I havent done this yet, we actually went back in favour of running http until we moved to the next version of TFS, but from my experience of TFS, the steps look sound.
I'm hosting a website on Heroku using Ruby on Rails. It uses a Cloudfront distribution to serve assets, and S3 to store images.
When going to http://example.com, everything works fine except for 2 webfonts. All the other fonts load fine.
When going to http://www.example.com, none of the webfonts load.
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.example.com' is therefore not allowed access.
I was using the normal Cloudfront asset host d12345.cloudfront.net, but I figured if I switched to assets.example.com, I'd outsmart the CORS issues. But I'm still getting:
Access to Font at 'http://assets.example.com/assets/myfont-Bold-735639b52225ec60e258c2b8b193dfb479f6158c3738a595db04f3a9684a4ad8.woff' from origin 'http://www.example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.example.com' is therefore not allowed access.
```
I have read countless threads, blogposts, SO answers about this issue but I can't seem to figure it out.
I have set up Rack::Cors in my rails application as follows:
Rails.application.config.middleware.insert_before 0, Rack::Cors do
allow do
origins '*'
resource '/assets/*', headers: :any, methods: [:get]
end
end
My asset_host is set up correctly:
CLOUDFRONT_HOST = "http://assets.example.com"
config.action_controller.asset_host = CLOUDFRONT_HOST
All other assets work perfectly fine. Images, JavaScript, CSS all come from CloudFront without any hiccups. It's just the 2 webfonts when going to the www.example.com subdomain and all webfonts when going to the root level site example.com.
I have tried a number of options in the Cloudfront and S3 admin panels:
added cors config to my bucket
whitelisted headers in my cloudfront distribution
But nothing seems to work. I'm lost as to why those 2 fonts won't load properly while everything else works fine.
Fonts are usually checked by your browser preflight, with an OPTIONS request. In your CORS setup, try also allowing OPTIONS in addition to GET. You might also have to allow OPTIONS on your CloudFront distribution.
Note that if these fonts have a query parameter in the request url, like assets.example.com/font.woff?v=123, the CloudFront distribution should also forward query parameters.
I have 1 question and 1 issue:
Question: If using CloudFront, is the image URL supposed to have s3.amazonaws.com or randomblah.cloudfront.net?
http://s3.amazonaws.com/bucketname/project_images/photos/000/000/006/medium/IMG_3867.JPG?1438009375
or with the actual cloudfront.net url...
http://fdawfwe8200.cloudfront.net/bucketname/project_images/photos/000/000/006/medium/IMG_3867.JPG?1438009375
Right now, I have this in my production.rb
config.action_controller.asset_host = 'fdawfwe8200.cloudfront.net'
Issue: I'm getting Redirect at origin 'http://fdawfwe8200.cloudfront.net' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header.... error
How do I fix this?
The only thing I see breaking on my site is, bootstrap icons are boxes.
you can find documentation to help CloudFront with your Cors configuration like here:
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-cors
So just let your content server specifiy the 'Access-Control-Allow-Origin' header to what you want and configure your CDN to keep those headers.
I've got a non wildcard SSL certificate for my root domain (example.com), and I'm using the heroku ssl endpoint add on. I'm using routing constraints so subdomain.example.com matches various controller actions, and I reroute the subdomain with CNAME records to the root domain. This all works fine in development, and it works fine in Tor browser if I disable https, but I can't get it to work in any ordinary browser.
I've tried using gem SSL-enforcer to enforce SSL except on host with subdomain as such:
config.middleware.use Rack::SslEnforcer, :except_hosts => 'subdomain.mydomain.com', :strict => true
Can I disable the https protocol for subdomain of my rails app? I feel like this might be impossible as I've read that SSL negotiations are made before the server knows the URL.
I would have recommended SSL-enforcer.....
Are you using config.force_ssl and generating a strict transport security header? I would suspect that might be the issue if it works with Tor but not a normal browser. Check the headers; if the HSTS exists, then that's probably the reason. Should be straight forward to change that (changing the max-age attribute to 0)
If not, check the Heroku docs again and make sure your settings and DNS/CNAME are correct....
https://devcenter.heroku.com/articles/ssl-endpoint#subdomain
Hope this helps.
There is a nice option to config for the Rails app:
config.force_ssl = true
However it seems that just putting that to true doesn't get the HTTPS connections working. Even more - after trying (and failing) to connect to https://localhost:3000 with Chrome, I've set this option to false, and Chrome still tries to open https, even if I write http.
So, couple of questions:
--How to force Chrome not to try https anymore?
--What is the proper way of enabling SSL on my Rails app?
Update: The app is run on Heroku, and it seems that https is supported there automagically. Can I test SSL also locally? Like when running rails server?
First, I should say that I haven't tried this, but there are mainly two possibly reasons for Chrome still using HTTPS:
Using HTTP Strict Transport Security headers: if the server sets them, the client (supporting HSTS, like Chrome) is meant to stick to HTTPS for all subsequent requests to that host.
Permanent redirects. If the initial redirect you got was using "301 Moved Permanently" (and not 302 for example) to make the redirection,(*) the browser is meant to remember it ("The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs").
A likely solution to this would be to clear the cache in your browser.
(*) This question seems to indicate this is the case for Ruby on Rails with this config).
I had the same issue. What I did is using an ssl enforcer gem which adds a middleware that handles ssl and redirects. It has a strict option which enforces the configured protocols.
in your Gemfile add:
gem 'rack-ssl-enforcer'
in production.rb add:
config.middleware.use Rack::SslEnforcer, only: %r{your_regex_condition}, strict: true
This will force the requested pages to be secured and the rest to be non secured. It disables the HSTS header which is problematic in chrome (redirect caching issue).
You can also expire the cache for all cleints (if it already exist) to make sure you'll not get infinite redirect:
config.middleware.use Rack::SslEnforcer, only: %r{your_regex_condition}, :hsts => { :expires => 1, :subdomains => false }
also remove the ssl enforcement in production.rb (otherwise it might conflict with this middleware):
config.force_ssl = false
Let's see what happened once you updated your config file with:
config.force_ssl = true
This has caused Rack SSL Middleware to be loaded as the first middleware. As you can see in the code, Rack SSL sets an HSTS header by adding this line to the headers :
Strict-Transport-Security
It tells supported browsers such as Chrome to use HTTPS only to access your website.
So once you set back :
config.force_ssl = false
Chrome will still uses HTTPS to access your website and causes an error.
To solve this problem, you need to empty the HSTS cache. You can to that by going to the following url in your chrome browser :
chrome://net-internals/#hsts
Open your Chrome Developer Tools when you're at localhost: Then you can right click the refresh button ↻ and select "Empty cache and hard reload".
This error might also happens to you, if you start your server in the production environment, where HSTS is enabled.
Chrome redirects you to https://localhost:3000/ and says "SSL connection error".