How can I get Django to generate the static URL's using static.mywebsite.com, instead of static.mywebsite.com.s3.amazonaws.com?
The S3 bucket used for static files works when I am using a bucket name with no periods. But with a bucket using periods, it gives Failed to load resource: net::ERR_INSECURE_RESPONSE
The reason I am trying to use a bucket with periods is because this guide and two StackOverflow posts say that this is required to get an address of static.mywebsite.com, instead of mywebsite-static.s3.amazaonaws.com:
http://carltonbale.com/how-to-alias-a-domain-name-or-sub-domain-to-amazon-s3/
how appoint a subdomain for a s3 bucket?
Amazon S3: Static Web Sites: Custom Domain or Subdomain
And it seems to work; when I browse to static.mywebsite.com, I get an XML from S3 saying AccessDenied. In the last link above, a user comments to ask if this will work with HTTPS. It initially appears that it does not.
Upon inspection, the URL's of the static files generated by Django still use the static.mywebsite.com.s3.amazonaws.com address. If I understand correctly, this is a HTTPS certificate issue due to the periods creating additional layers of subdomains.
So, I changed the settings to use:
STATIC_URL = 'https://%s.mywebsite.%s/' % ('static', 'com')
But that resulted in it generating static.s3.amazonaws.com.
How can I get Django to generate the URL's using static.mywebsite.com?
Related
Let's assume one has an Amazon S3 bucket example.com configured for static hosting. In the configuration, the console allows setting an index file and an optional error file. But I'm struggling to figure out how to add another page to the site. I thought this would be straight forward but I cannot find the answer in the official documentation or on the internet.
If I want to add one more page to the static site (e.g. example.com/page2) and there is a page2.html file already in the S3 bucket at the root, where is the correct place to make this routing configuration? Can it be done through the S3 console? Or does it need to be configured through some kind of a DNS record? As a further complication, this needs to also work with and without the www in the URL.
On the DNS side I currently have the following configuration:
CNAME | WWW | www.example.com.s3-website-east-1.amazonaws.com | TTL 30 min
URL Redirect Record | # | http://www.example.com unmasked
Are you trying to access the page at example.com/page2.html or example.com/page2
If you want to access the page at example.com/page2 then create a 'folder' called page2 off the root and in that folder put a file called index.html
If you want to use example.com/page2.html, then create a file called page2.html and put it in the 'root' of the bucket.
Simply create a file called page2.html. It will be accessible via example.com/page2.html.
No routing configuration is required.
The index file alias is only used if no page is specified (eg they go to example.com/).
As for mapping www.example.com to example.com, you would create another bucket with the name www.example.com and use "Redirect requests" to point back to example.com. (If using a CNAME works for you, that's probably easier, but test it first to see if it functions as expected. See: Mapping naked domain (www.domain.com) to static website which is saved in S3)
See: Configuring a static website using a custom domain registered with Route 53 (Follow the manual steps rather than automating via CloudFormation, so you can better understand what has been configured)
I'm new to this AWS and I'm experiencing a very annoying bug with S3.
I created a bucket named with dots : my.super.bucket.
After uploading pictures to that bucket with name 'my-key', I get the URL.
It looks like this : https://my.super.bucket.s3-eu-west-1.amazonaws.com/my-key
Problem : The SSL certificate is not valid and every browser trying to display the picture does not because the certificate is only valid for one-level subdomains (*.s3-eu-west-1.amazonaws.com).
Earlier it was working as I was using path-style request i.e. the URL looked like this
https://s3-eu-west-1.amazonaws.com/my.super.bucket/my-key
But, as from september 2020, aws will no be supporting path-style base url on S3, I'm tring to change it to change it to Virtual-Hosted style.
I am using httpS
One work around I know here is I can use '-' instead of dots. But is there any other way so that I can use virtual-hosted style with bucket name containing dots?
As I see it, you may need to change the bucket name. Or you can make the content available through CloudFront with different domain name.
I have two sites statically hosted at S3.
Site example-one.com should redirect to example-two.com.
I added a redirect in the S3 bucket for example-one.com.
Like shown in the picture below.
Problem: entering example-one.com results in example-two.com/index.html
Question: How can I make it redirect to **example-two.com and not example-two.com/index.html ?**
When I access example-two.com directly it results in example-two.com as intended.
example-two.com has the S3 static site setting index document given as index.html
I use CloudFront for both domains. They previously had set the setting default root object as index.html, however I removed this earlier today so it's blank now.
To see it live access the link
Please specify if further details are needed :-)
I will be hosting a static web site on S3. The problem is that the web engine behind S3-as-a-web-server does not transform http://example.com/hello/ into http://example.com/hello/index.html.
When configuring the web site, there is a provision for the root document (the one which will be displayed when calling http://example.com), but not any deeper URLS (such as my example).
Is it possible to use the redirect rules to achieve that?
I actually have a solution for this problem, but is is really convoluted:
host the web site on an S3 bucket
deploy a CloudFront instance which origins in that bucket
use a Lambda#Edge which will rewrite the call once it hits CloudFront
I hope there is something more straightforward (I have hope in the redirect rules, though "redirect" suggests that something was already attained, which is not the case in my problem as S3 does not seem to understand what http://example.com/hello/ is.
When you specify the default index file and wants to serve index.html in a subpath,
You need to have the index.html in every level.
The documentation for S3 specifies the following
If you create such a folder structure in your bucket, you must have an
index document at each level. When a user specifies a URL that
resembles a folder lookup, the presence or absence of a trailing slash
determines the behavior of the website. For example, the following
URL, with a trailing slash, returns the photos/index.html index
document.
http://example-bucket.s3-website-region.amazonaws.com/photos/ However,
if you exclude the trailing slash from the preceding URL, Amazon S3
first looks for an object photos in the bucket. If the photos object
is not found, then it searches for an index document,
photos/index.html. If that document is found, Amazon S3 returns a 302
Found message and points to the photos/ key. For subsequent requests
to photos/, Amazon S3 returns photos/index.html.
Alternatively, If you want ALL paths to server index.html, this thread might be useful
Many people have received 100s of links to PoCs that are on an internal facing bucket and the links are in this structure.
https://s3.amazonaws.com/bucket_name/
I added a redirect using AWS's Static website hosting section in Properties and it ONLY redirects when the domain is formatted like this:
https://bucket_name.s3-website-us-east-1.amazonaws.com
Is this a bug with S3?
For now, how do I make it redirect using both types of links? My current workaround is to add a meta redirect tag in each html file.
The s3-website is the only endpoint that supports redirects unfortunately. Using the s3.amazonaws.com supposes that you will be using S3 as a storage layer, instead of a website. If the link is to a specific object, you can place an HTML file at that url with a JS redirect, but other than that there is really no way to achieve what you are trying to do.
In the future, i would recommend always setting up a Cloudfront distribution for those kinds of usecases, as that will allow you to change the origin later on.