I have a server app that can serve files from it's local file system. However before it does that it should check to see whether the file could instead be served from CloudFront and, if so, redirect there instead.
Not all the files on the server are not necessarily duplicated in the S3 bucket origin(s) associated with the CloudFront distribution, so there will be some cases where a redirect to CloudFront is inappropriate.
How can I query the CloudFront SDK to find out whether a redirect to that would be successful (and not return a 404 for example)?
I appreciate that I could query the contents of an associated S3 bucket origin instead, but ideally I'd like to get the result from CloudFront so that it can do all of it's caching and failover between multiple origins and origin groups and I don't really want to have to replicate all of that logic in my code!
I happen to be using the c# SDK, but happy to accept answers in any language, it's more the principals behind it that I'm interested in. Am I perhaps thinking about this in the wrong way?
I was vastly overthinking this. Just making a http request with HEAD rather than GET and checking the response was 200 was all that was needed.
Related
I am trying to find a script or program to convert my html website links from http to https.
I have looked all over hundreds of search results and web articles and I used the Word Press SSL plugin but it missed numerous pages with http links.
Below is one of thousands of my links I need to convert:
http://www.robert-b-ritter-jr.com/2015/11/30/blog-121-we-dont-need-the-required-minimum-distributions-rmds
I am looking for a way to do this quickly instead of one at a time.
The HTTPS Everywhere extension will automatically rewrite unsecure HTTP requests to HTTPS. Keep in mind not all websites offer a secure and encrypted connection.
I'm using AWS S3 and Cloudfront to deliver images to my sites/domains.
I've been looking at AWS S3 CORS and I wanted to ask if I limit the domains will this restrict other domains from access my images.
If I was to set the following on a Bucket that contained images would this stop other domains from access the images within the bucket or do images operate differently to under resources under CORS.
<AllowedOrigin>http://www.example.com</AllowedOrigin>
Essentially I would like to restrict my images to my sites only.
Also I heard you must include the Cloudfront as another AllowedOrigin for this work - Can someone confirm this?
thanks
CORS is a policy enforced by a browser. Its not going to prevent users from downloading images from your cloudfront distribution.
You have two options.
Make all your files private and provide access via signed urls. Cloudfront wont really cache images in this case however.
The other option is to configure cloudfront to forward all headers, and use a bucket policy to limit access based on referrers. You can get around this, but it would prevent most casual hotlinking.
Basically, Heroku gives you a domain named by default: XXX.herokuapp.com.
On my own, I have a set of REST apis that I would like to set on a domain named: api.myDomain.com.
On the same time, I have my HTML files (web view) distributed by the same server as the REST API.
It's similar to this; embedding static files on server in a dist folder.
I expect the domain serving those HTML/JS files to be www.myDomain.com.
I thought about putting them clearly on a distinct server dedicated to static files, but the fact is that Single Page Application should be controlled by a server, in order to make the refresh works (F5 redirecting to index.html), that's why I chose to use the same server as REST apis.
An alternative would be to dedicate ANOTHER server to treat only static files, independent of the REST Apis' server.
How to deal with both domains (api and www) while sources being on the same servers?
Or should I completely rethink the strategy?
You can just set both domains to direct to your page by setting it up in your app settings, but then I'm pretty sure that would mean api.myDomain.com/dist would show your static things, and www.myDomain.com could show your api things.
https://devcenter.heroku.com/articles/custom-domains
Another way you could do this might be by doing some things with your actual code, but we don't really know what your code is like right now.
I have a single page application that I am (trying) to host on Google Cloud Storage.
The application is at index.html, and the application handles routing using Angular's html5Mode. (e.g.: routes like example.com/this and example.com/that are handled by the js application in index.html)
Using Google Cloud Storage's website configuration this is all well and good, except that routes that are accessed directly ("example.com/this") will 404 as they obviously do not map to a file.
I have set my 404 page to be my index page, but what I really need in order to run a single page application in html5Mode is that such routes ("example.com/this") will not return a 404 header - they will simply be handled by index.html and return a success header (200).
Is this possible?
Setting index.html to your 404 page from the website configuration seems to do the trick now.
Unfortunately, this isn't really possible. Google Cloud Storage's web mapping is pretty simple, and you can't create arbitrary rules based on patterns and the like.
You might want to consider either disabling html5mode or forcing a hashbang with html5mode. See this answer for more on that option.
I am working on a project where I need make cross-origin requests, but there does not appear to be any way to allow this in a pure web page.
Chrome extensions can simply request permission to the domains they would like to make requests to as in the following example.
"permissions": [
"http://www.google.com/",
"https://www.google.com/"
]
http://developer.chrome.com/extensions/xhr.html
I found https://developers.google.com/chrome/apps/docs/no_crx which seemed like something closer to what I was looking for, but the only permissions allowed are "geolocation", "notifications", and "unlimitedStorage".
There is the HTTP header Access-Control-Allow-Origin which could be set on the domains I would like to make requests to, but they are not under my control so that is not practical.
Similarly the Content-Security-Policy: connect-src https://www.google.com; is primarily used to further restrict access instead of opening up access.
http://www.html5rocks.com/en/tutorials/security/content-security-policy/
I understand the security concerns, but as a quick search will show people get around this by making a proxy server. Wouldn't it make sense to allow the equivalent request to be made, meaning a request without the user's session/cookie information (like incognito mode)? Or some mechanism by which the page can request permission in the same manner as an extension? Seems somewhat backwards to require things like this to be down in browser specific manner.
Just like webspeech api (or getUserMedia) requests access to use microphone.
Any thoughts or perhaps something I missed?
EDIT: I posted this elsewhere and got:
If you are making requests from domains that are under your control, there are other options (like JSONP) that you can use to access data from another domain. Or, you can load an iframe and use postMessage() to interact with the contents - there are lots of tools that also enforce that the domain you're trying to communicate with is willing to share that data.
Me:
JSONP looks like a solution for data sources that provide JSON, but I am not sure that will solve my overall problem. I am trying to create a tool that will pull in data from a variety of sources to do both displaying a result and interpreting the information to perform an action. One query might be a google search which jsonp or the other official methods should allow for, but that does not work for scraping data from other web pages. All of the requests being made will not require user session information and thus a proxy would work, but will add latency and maintenance costs.
The postMessage() interface would require the pages being requested to implement listeners right?
So far the "best" solution still seems to be to have a companion extension that runs in a privileged environment that can make the requests and communicate the results with the page. The tool does a variety of other things that work within a web page so I would rather leave the primary environment as the web page with the option to run the extension.