AWS Elastic Load Balancer not Forwarding HTTP Headers to EC2 Instance - amazon-web-services

I'm currently running a Python Flask Application on Amazon Elastic Beanstalk. When I test the application, it all works fine locally (I used Postman to send the GET & POST requests). However, on AWS, it doesn't work because the request that gets to my EC2 instances (behind the load balancer) does not include the Authorization header. It seems like the load balancer strips off the header. Is there something I'm doing wrong here?
Here's a comparison of what I get when I print out the header locally and on Elastic Beanstalk.
Locally
[2017-07-04 13:18:14,650] [INFO] [common.decorators] Headers = Host: localhost:5000
Connection: keep-alive
Content-Length: 151
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Cache-Control: no-cache
Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop
Content-Type: application/json
Authorization: Bearer ad9fd4d9-6ce6-497b-855a-dcebebdad65b
Postman-Token: xxxxx
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
Elastic Beanstalk:
[2017-07-04 17:27:03,813] [DEBUG] [common.decorators] Headers = Accept-Language: en-US,en;q=0.8
Accept: */*
Host: dev.onetext.com
X-Forwarded-For: 66.30.13.108
Content-Type: application/json
Postman-Token: xxxxx
Connection: keep-alive
Accept-Encoding: gzip, deflate, sdch, br
X-Forwarded-Proto: https
Cache-Control: no-cache
X-Forwarded-Port: 443
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Thanks to the comment added by #notionquest, I found the solution at https://forums.aws.amazon.com/thread.jspa?messageID=729128
I solved this by adding a new file under the .ebextensions folder with the following content:
files:
"/etc/httpd/conf.d/wsgihacks.conf":
mode: "000644"
owner: root
group: root
content: |
WSGIPassAuthorization On

AWS do not accept unserscores (_) in headders, while we can use (-), So Remove underscores from the header variables, example:-
header_var_val = "some value"
replace it with
headervarval = "some value"
It works for me

Related

How to set content type of an AWS S3 file?

First URL is presigned. Then with PUT message the gif file is uploaded. Content-Type is set both when presigning and also in PUT message, but in AWS interface gif type is not visible. Why?
PUT request header:
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en,nl;q=0.9,hu;q=0.8,de;q=0.7
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 10912652
Content-Type: image/gif. // <---------------
Host: t44-post-cover.s3.eu-central-1.amazonaws.com
Origin: http://localhost:3000
Pragma: no-cache
Referer: http://localhost:3000/
sec-ch-ua: ".Not/A)Brand";v="99", "Google Chrome";v="103", "Chromium";v="103"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "macOS"
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36
x-amz-acl: public-read
If image is uploaded from web interface, gif type is visible.
Content-type is S3 metadata. So to change it, you have to modify the metadata properties of your objects.

POST request returning 401 Unauthorised (only in Chrome)

I'm using Django Rest Framework and Vue.js to build a basic web app, and am currently working on the auth. Using axios to send a post request while registering a new user returns 401 in Chrome for some reason, but works in other browsers (Edge) and returns a 201 Created.
The error in chrome is "detail: Invalid Token", but this particular endpoint (registration) doesn't even need auth/token to access.
My frontend is at http://192.168.1.33:8080 and my backend is at http://127.0.0.1:8000
I am trying to POST data to http://127.0.0.1:8000/api/v1/users/auths/
The Network tab in chrome dev tools after trying a request:
Request URL: http://127.0.0.1:8000/api/v1/users/auths/
Request Method: POST
Status Code: 401 Unauthorized
Remote Address: 127.0.0.1:8000
Referrer Policy: strict-origin-when-cross-origin
Access-Control-Allow-Origin: http://192.168.1.33:8080
Allow: GET, POST, HEAD, OPTIONS
Content-Length: 27
Content-Type: application/json
Date: Mon, 06 Dec 2021 12:19:15 GMT
Referrer-Policy: same-origin
Server: WSGIServer/0.2 CPython/3.8.5
Vary: Accept, Origin
WWW-Authenticate: Token
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Authorization: Token acf8b9099de5eba413dea141ce2c06b6cfb03159
Connection: keep-alive
Content-Length: 53
Content-Type: application/json
Host: 127.0.0.1:8000
Origin: http://192.168.1.33:8080
Referer: http://192.168.1.33:8080/
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
The network tab in Edge dev tools after trying the same thing:
Request URL: http://127.0.0.1:8000/api/v1/users/auths/
Request Method: POST
Status Code: 201 Created
Remote Address: 127.0.0.1:8000
Referrer Policy: strict-origin-when-cross-origin
Access-Control-Allow-Origin: http://192.168.1.33:8080
Allow: GET, POST, HEAD, OPTIONS
Content-Length: 89
Content-Type: application/json
Date: Mon, 06 Dec 2021 12:20:25 GMT
Location: http://127.0.0.1:8000/api/v1/users/auths/12/
Referrer-Policy: same-origin
Server: WSGIServer/0.2 CPython/3.8.5
Vary: Accept, Origin, Cookie
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Authorization
Connection: keep-alive
Content-Length: 51
Content-Type: application/json
Host: 127.0.0.1:8000
Origin: http://192.168.1.33:8080
Referer: http://192.168.1.33:8080/
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96", "Microsoft Edge";v="96"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.55 Safari/537.36 Edg/96.0.1054.43
The obvious difference is that there is a "WWW-Authenticate: Token" in the Chrome Network tab, which is odd.
CORS headers and all have been set up properly, plus the issue is only in Chrome. Is this some Chrome quirk, or am I missing something?
Why is it that, after spending some two hours on a problem, you only get the answer after you've posted it on a forum? Probably something to do with putting the problem down categorically and formally...
Anyway. Turns out the issue was with there being a random token sitting in Chrome's local storage, which was causing all the trouble with the "invalid" token. I cleared local storage, and it's working now. No clue why I had to do this specifically — I had made sure to clear the cache earlier...

nginx allow access to location only if request came from cognito

I'm using AWS Cognito for auth, and have it redirect to a certain path at my nginx website
I want this path should only be reachable if the request comes from after the user logs in via cognito.
How do I block access to the path in nginx if someone just types that path into the address bar?
Let's say for example, the location I want locked down is:
http://localhost:3010/firstPath/
In Chrome devtools I don't see any referrer or anything like that in the request:
Request URL: http://localhost:3010/firstPath/?code=axxxxx-xxxx-xxx-9b18-df2832a401e9&state=N35vxxxxxJGnlJr5YEI5AVfFRPdbghFG
Request Method: GET
Status Code: 200 OK
Remote Address: 127.0.0.1:3010
Referrer Policy: strict-origin-when-cross-origin
Accept-Ranges: bytes
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Date: Thu, 28 Jan 2021 08:52:50 GMT
ETag: W/"868-KJFfIJ4iphNuyGJQRrz3NAqMbz4"
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Powered-By: Express
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Connection: keep-alive
DNT: 1
Host: localhost:3010
Pragma: no-cache
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36
code: axxxxx-xxxx-xxx-9b18-df2832a401e9
state: N35vxxxxxJGnlJr5Y
In nginx I can block requests that didn't come from AWS ELB to my /health check path, like this:
location /health {
set $block 1;
# Allow all the ELB health check agents.
if ($http_user_agent ~* '^ELB-HealthChecker\/.*$') {
set $block 0;
access_log off;
}
# block invalid requests
if ($block = 1) {
return 444;
}
return 200;
add_header Content-Type text/plain;
}
Is there a way to do similar for this path, based on the request coming from aws cognito?

S3 response header inaccurately returns location: "https://http//example.com"

I'm attempting to route my 'www.example.com' in S3 to 'example.com'. I'm using Amazon S3, Cloudfront, and Route 53.
When I visit 'www.example.com' console shows that I post two GETs (below), but I end up being redirected through 'http://www.example.com' to 'https://http//example.com.'
First GET Request:
- Host: www.example.com
- User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) - Gecko/20100101 Firefox/56.0
- Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
- Accept-Language: en-US,en;q=0.5
- Accept-Encoding: gzip, deflate
- Connection: keep-alive
- Upgrade-Insecure-Requests: 1
First GET Response:
- Content-Length: 0
- Date: Sun, 12 Nov 2017 04:47:31 GMT
- Location: http://https://example.com/
- Server: AmazonS3
- Age: 57072
- X-Cache: Hit from cloudfront
- Via: 1.1 **************************.cloudfront.net (CloudFront)
- X-Amz-Cf-Id: adKFULOwqXFzT9Q_SYjWsb-oCjcfBAmxUvk9iRl3kMo0hICMCmJJrA==
Second GET Request:
- Host: https
- User-Agent: Mozilla/5.0 (Windows NT 10.0; …) Gecko/20100101 Firefox/56.0
- Accept: text/html,application/xhtml+xm…plication/xml;q=0.9,/;q=0.8
- Accept-Language: en-US,en;q=0.5
- Accept-Encoding: gzip, deflate
- Connection: keep-alive
- Upgrade-Insecure-Requests: 1
Second GET Response is never returned.
The error seems to start somewhere around the obviously incorrect response 'location' (italicized above). Then the second GET gets confused by the first GET's 'location' and sends the second GET to 'https' as the 'host', which results in a redirect to Google and the URL of 'https://http//example.com'. I confirm on Redirect Detective and Redirect Check that my redirect ends up at 'https://example.com' which really confuses me.
Any help is appreciated. I've tried a multitude of different things to try and fix it. I think I've finally narrowed it down some.
This means that the default document at www.johnmacintire.com (index.html, etc.) is returning the HTTP header: Location: http://https://example.com/. Notice how this is formatted incorrectly (http://https://).

simple javascript file keeps returning 301 with cloudfront

I'm using cloudfront for a simple javascript asset that is the following:
https://d1syjrf5lltxmn.cloudfront.net/Content/JavaScript/jquery-migrate-1.2.1.min.js
I've got the Origin Domain name and path set to
www.siliconvalley-codecamp.com
Origin type is custom origin, policy i sMatch Viewer, view policy is http and https. Problem is when it hit this (over and over) it keeps returning a 301 and doing another request from my origin server.
I can't figure out why it keeps doing the 301's. I've read others having issues but can not find a solution.
GET https://d1syjrf5lltxmn.cloudfront.net/Content/JavaScript/jquery-migrate- 1.2.1.min.js HTTP/1.1
Host: d1syjrf5lltxmn.cloudfront.net
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.99 Safari/537.36
DNT: 1
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
and the return is:
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=UTF-8
Content-Length: 208
Connection: keep-alive
Location: https://www.siliconvalley-codecamp.com/Content/JavaScript/jquery-migrate-1.2.1.min.js
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Fri, 23 Jan 2015 04:18:21 GMT
Age: 10575
X-Cache: Hit from cloudfront
Via: 1.1 f86dab587205f74a0e6f36b42207dec2.cloudfront.net (CloudFront)
X-Amz-Cf-Id: 8h4R0WTOl1wg8LDafMoeAkcvOr1G8ujfAVMgz84Uy_BVE8QlxTbTrQ==
<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found here</body>
Origin server setup: