Has anyone run into problems trying to use AWS Amplify with a URL that contains periods? The app is working perfectly fine while running on the local dev server (which is using Parcel.js), so I'm fairly confident it's an issue with Amplify.
For example, we have a page at https://example.org/data/sample/H2.32.433 and end up getting an AWS AccessDenied when hitting the URL directly. As a workaround, we've been encoding the periods but that's not as readable of a URL.
We have a redirect rule that AWS provided in the Amplify docs with the following regex that redirects to index.html with a 200 (Rewrite) code:
</^[^.]+$|\\.(?!(mp4|css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json)$)([^.]+$)/>
I'm thinking it has something to do with the redirect rule, but I'm not sure.
Any thoughts would be greatly appreciated!
Related
I've been trying to add google login to my django app following this tutorial:
https://github.com/RealmTeam/django-rest-framework-social-oauth2
By following exactly the instructions, everything works fine in local.
However, when I try to replicate the same on the server, I get the following error on the redirect page of the login:
Error 400: redirect_uri_mismatch
redirect_uri: http://localhost:8000/auth/complete/google-oauth2/
What is strange to me is, in my google developer console, I have set up the correct redirect url in my app, as follows:
https://mydjangoapp.com/auth/complete/google-oauth2/
And I have also put 'mydjangoapp.com' under 'Authorised JavaScript origins'.
So my question is, why google keeps telling me that the redirect url is
http://localhost:8000/auth/complete/google-oauth2/
which is not the one I have set up in the console? Perhaps there is something obvious that I'm missing here. Thank you!
Why google keeps telling me that the redirect url is
Because your application is sending its in your code the app is running on http://localhost:8000 and if you are using a client library its probably adding the rest automatically.
http://localhost:8000/auth/complete/google-oauth2/
The redirect uri must exactly match what you are sending from your application.
You need to add
http://localhost:8000/auth/complete/google-oauth2/
Javascript origin is only needed if your code is using javascript.
This video will show you how to fix the error. Google OAuth2: How the fix redirect_uri_mismatch error. Part 2 server sided web applications.
If you want your code to send https://mydjangoapp.com then your going to have to be running it from https://mydjangoapp.com probably and you may need to figure out how to configure it so that it is running from the correct host.
I have a Django website hosted under AWS/Cloudfront.
Every form contains a CSRF token and is caught with jquery and then processed with AJAX.
When accessing the website with the Elastic Beanstalk URL everything works fine.
Url pattern working: http://example.us-east-2.elasticbeanstalk.com
When accessing the website with the domain name, all the Ajax calls are refused with a 403 error.
Url pattern not working: https://www.example.com/
I have the strong intuition there is a parameter to change in AWS, but for me, it is a black-box.
Thank you in advance for reading and maybe answering this.
EDIT 1: I think the only problem is the posted parameters not being parsed to the controller (views.py)
I think you should verify SSL/TLS requirements,
or some docs like :
Amazon Using HTTPS
When I launched a AWS serveur, I had to configure for http and https.
As expected I finally found a single parameter to change:
CloudFront > Select your Bucket > Distribution parameters > behaviors > Edit > Select managed-AllViewer for the Origin policy.
So -
have amazon ecs app using a load balancer set to authenticate against cognito.
Using one of amazon's domains (blah.auth...)
been running fine for ages
suddenly a few hours ago started giving back
err_invalid_response when you tried to login, for that domain/login....
lots of computers at different sites were doing it
then manually changed the address to http:// instead of https://
it gave an error, then redirected to https:// then worked!!!
and now it just works from everywhere
so...
does anyone have any idea what's going on... and more importantly
anyone have any idea how I troubleshoot this? Are there any logs anywhere?
I am using AWS codestar to deploy by react application using serverless nodejs template. This is the url that is given by codestar after successfully completion of all the stages https://xxxxx.execute-api.us-east-1.amazonaws.com/Prod . This url displayed all the components in my app correctly. In navbar of my app i have items like this a ,b,c. where clicking on each one of them will redirect to a new component.(i.e.https://xxxxx.execute-api.us-east-1.amazonaws.com/a,https://xxxxx.execute-api.us-east-1.amazonaws.com/b etc. But when i refresh the page which is having a url like this https://xxxxx.execute-api.us-east-1.amazonaws.com/b i am getting a error like {"message":"Forbidden"} and in my console it is showing like this favicon.ico:1 GET https://xxxx.execute-api.us-east-1.amazonaws.com/favicon.ico 403
It seems the chrome is fetching the favicon based on the https link, which fails because there is no such favicon at the location. I tried to remove favicon.ico link in index.html but even then the chrome is using the same url to fetch the favicon which eventually fails. I followed max number of suggestions in SO to acheive this but no luck. Is there any way to say api-gateway to exclude these favicon get requests and display my app rather than showing message forbidden.
And i am pretty sure that i had enabled logs for both the agi-gateway and lambda where i didnt find any forbidden errors(i.e.403) which is weird because i can see those 403 errors in my console.
Thanks
Any help is highly appreciated.
The https://xxxxx.execute-api.us-east-1.amazonaws.com/Prod url provided by API Gateway is the base url for your site, so those paths would have to be /Prod/a instead of /a.
One way to get around that is to register your own domain and connect it to API Gateway via a custom domain. That would allow you to have https://example.com as your base url, and your paths could stay /a, /b, etc.
So we are using the Meteor browser-policy package, and using Amazon S3 to store content.
On the server we have setup the browser policy as follows:
BrowserPolicy.content.allowOriginForAll('*.amazonaws.com');
BrowserPolicy.content.allowOriginForAll('*.s3.amazonaws.com');
This works fine in local dev and in production when visiting our http:// site. However when using the https:// address to our site the AWS content no longer passes this policy.
The following error is put on the console
Refused to load the image 'http://our-bucket-name.s3.amazonaws.com/asset-stored-in-s3.png' because it violates the following Content Security Policy directive: "img-src data: 'self' *.google-analytics.com *.zencdn.net *.filepicker.io *.uservoice.com *.amazonaws.com *.s3.amazonaws.com".
As you can see we have some other origins allowed in the browser policy, these all seem to work fine in both http and https. AWS S3 is the only one that is failing.
I've tried Chrome, Firefox, and Safari and they all have the same issue.
Whats going on?
I may not have the exact answer to this question but I have some information which the community may find helpful.
First, you should avoid serving mixed content. I'm unclear if that would set off the browser policy alerts but you just shouldn't do it anyway. The easiest solution is to use a protocol-relative-url or just explicitly specify https in your url.
Second, I too assumed that the wildcard worked like a glob. However, I've been told that it works the same way as an ssl certificate rule - i.e. for all subdomains or for a specific subdomain. In other words, *.example.com and www.example.com, are valid but *.foo.example.com, isn't meaningful. I think you want to explicitly add your bucket like so:
BrowserPolicy.content.allowOriginForAll('our-bucket-name.s3.amazonaws.com')
unless you literally want to trust all of amazonaws.com.