I have an Elastic Beanstalk Application to host my Django Rest Framework End points.
I have enabled corsheader to protect Cross origin request forgery.
Now the problem is when health check on ELB occurs it sends a request on health url via :80/api/health/ but this URL throws 400 Bad request since the URL via any domain except once specified in allowed_host are not allowed.
I tried putting in allowed_host as ["172.", "192.", "10.", ".mydomina.com"]
But it does not seem to work.
I raised this as a ticket with AWS support and found a solution as
https://dryan.com/articles/elb-django-allowed-hosts/
Make Changes to your production configuration as
# Add Private IP of the ELB Instance to Allowed Host for the Health check not to throw CORS 400 Bad Request
EC2_PRIVATE_IP = None
try:
EC2_PRIVATE_IP = requests.get('http://169.254.169.254/latest/meta-data/local-ipv4', timeout=0.01).text
except requests.exceptions.RequestException:
pass
if EC2_PRIVATE_IP:
ALLOWED_HOSTS.append(EC2_PRIVATE_IP)
print("Allowed Host List:")
print(ALLOWED_HOSTS)
Related
I have a REST API on a Hetzner server which uses Varnish. I am trying to set up Cloudfront to use as the CDN for it. After reading around, I currently have the following setup:
Hetzner / Varnish
A main API route api.mydomain.com.
Config in Varnish for cdn-api.mydomain.com to also act as a route to the same API.
In the DNS for the domain in Hetzner, for cdn-api.mydomain.com I have
added the name servers for Route 53.
Route 53
Hosted zone called cdn-api.mydomain.com.
An A record with name prod.cdn-api.mydomain.com which points to my Cloudfront distribution.
An A record with name cdn-api.mydomain.com which points to the IP address of the server.
Cloudfront Distribution
Has the alternate domain name prod.cdn-api.mydomain.com.
Has the origin domain of cdn-api.mydomain.com
Protocol for origin is HTTP only
What I think should happen
Make a request to prod.cdn-api.mydomain.com.
Route 53 forwards to the Cloudfront distribution.
CloudFront looks to origin cdn-api.mydomain.com.
Origin cdn-api.mydomain.com looks to IP address of Hetzner.
Hetzner receives request, Varnish allows the domain through, sends back data to Cloudfront.
What actually happens
If I make a request straight to cdn-api.mydomain.com from Postman, it works if I turn off SSL.
If I turn on SSL, I get the error SSL Error: Hostname/IP does not match certificate's altnames, saying that cdn-api.mydomain.com is not on the certificates of the server.
If I make a request to prod.cdn-api.mydomain.com, I get the error Error: Exceeded maxRedirects. Probably stuck in a redirect loop. Which may be due to the same certs error.
Cloudflare
As a comparison, we have Cloudflare set up as the CDN for a different domain on the same Hetzner server. It has:
A main API route api.myotherdomain.com
In Hetzner a CNAME for cdn-api.myotherdomain.com with value cdn-api.myotherdomain.com.cdn.cloudflare.net.
In Cloudflare, an A record for cdn-api.myotherdomain.com which points to the IP address of the server.
cdn-api.myotherdomain.com is set up in Varnish as an entry point, but is not on the list of certificates of the server.
This all works fine including with SSL enabled.
It would be good to understand what I'm doing wrong here.
The manual says this about the HTTP URL value of an http listener:
"Displays the generated HTTP URL for the HTTP Listener. This is not an actual
configurable setting, but is instead displayed for copy/paste convenience. Note
that the host in the URL will be the same as the host you used to connect to
the Administrator. The actual host that connecting clients use may be different
due to differing networking environments."
When I have used the feature in the past its value has always begun "http://localhost:" which would be great except this time it is auto-generating " http://'domainName':${Incoming_Pathology_Source_Port}/${Incoming_Pathology_Source_BaseContextPath}/"
For the first time, we are deploying Mirth inside a Kubernetes cluster, 'a different working environment'. (nginx accepts https and we want it pass the messages on as http to Mirth).
Is there any way I can take control of the URL or must I change the configuration of the cluster in some way.
All help/suggestions welcome.
I developped an application NUXTJS with a backend in Symfony. I deploy an API REST that allows me to talk beetween front and back. Everything work in local.
I want to deploy this on my host.
So I created two subdomains : one for my front and one for my backend.
So when I try to access to my application, I try to connect but I have these two errors CORS :
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://mysubdomain.domain.fr/api/login_check. (Reason: CORS header 'Access-Control-Allow-Origin' missing).
And
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://mysubdomain.domain.fr/api/login_check. (Reason: CORS request did not succeed).
How can I fix this ?
Thanks a lot
You need to enable CORS by specifying the nextjs domain, not the api domain. If you want to be sure you can also allow all domain by using a *. But this reduces security a bit.
If you really want to be secure, you could add a proxy to your nextjs server, which proxies to your Symfony application. For example, in your NextJS application, proxy /api to the Symfony application hostname.
This way you don't need to enable CORS at all.
If you use Api Platform you may need to configure the CORS_ALLOW_ORIGIN variable in your .env file 😁
We have a REST based API project. The project is hosted in IIS on multiple servers on a load balancer.It works great except when a server goes down on the load balancer, we receive a 404 Bad Request error for few seconds and then it resolves itself. How do we resolve this? Are there any changes that need to be done in IIS or on the REST API project itself?
As far as I know, if you use IIS ARR's loadbalance there is no need to add the specail setting to check the server's status. The IIS ARR healthy test will auto send the request to check the server is work well or not. If the IIS ARR find the server is down or return error, it will not redirect the request to the server.
Besides, as far as I know, the 404 error means the page not found not the bad request. Normally, 400 is the bad request status code.
If you find a server is down in your server farms, I suggest you could try to access the server directly through the brwoser to know the details error message.
If the server return 404 error, that means your browser couldn't access the server, it is a network issue normally. You should check the DNS server setting or make sure the IIS web application is running.
If the server return 400 error, you should troublshooting according to the details 400 error message. Normall, it shows when the request contains the wrong header.
I have an AWS EC2 Jira instance running behind an AWS Classic load balancer. The site loads in the browser fine, but all API requests are returning 404 for some reason. It is not a Jira 404, but a generic 404 response with no body and minimal headers. Only response useful header seems to be Server: nginx.
Tried white-listing my client IP, opening up all ports, sending request to the LB and directly to the instance with proper security group settings, etc., but same 404 response is returned. I'm using Postman to test the API. I noticed when I load the EC2 instance directly in the browser, it redirects to the load balancer.
Returns 200 with HTML. Basic auth works, too.
GET http://jira (home page)
Returns 404:
GET http://jira/rest/api/2/issue/ticket-num (or any other /rest/ endpoints)
Where should I start looking to debug this 404 issue? I feel like I'm missing something basic. I'm not seeing any Jira configuration for setting up its rest API. I feel like perhaps it's a server configuration issue, although I've never come across manual web server configuration while installing Jira, so maybe on the AWS's side?
EDIT: still waiting to get ssh access to the instance, so I'll update as I get more info and access.
This HTTP 404 responses with very limited set of headers could be from the default (the bottom one) rule in ELB. I experienced similar issue getting HTTP 404 because instead of host header I set path and provided the host domain name in one of ELB rules. So the rule did not work and default rule returned 404 because there is no such path exists on the instance.
I would recommend to try to use Redirect to or Return fixed response options for default rule to check out if it goes to the default rule.