My website is hosted on AWS and currently it has a ELB health check URL is set to a static webpage(ping.php).
I want to set my health check URL to another page which is dynamic - with database connectivity. Also those web pages are authenticated with basic authentication as well.
My requirement is to have a path set in my AWS ELB which calls for the dynamic and authenticated web page and return the 200 response back to ELB.
How can I manage that in Apache configuration ?
Hope it's clear!
Thanks.
Based on the comments.
The issue was that ALB does not support any type of authentication to your application, e.g. basic authentication. Therefore, ALB can't login to your app and perform health checks afterwards.
To overcome the issue, there are two general solutions:
Setup health check HTTP code to the code representing failure of authentication.
Modify your application to have normal health check endpoint without any authentication.
Related
I do have a Stripe webhook which is successfully caught and processd in Stripe's TEST MODE, on http local host server.
However, when switching to Stripe's LIVE MODE DATA, the webhook returns status code 500, while the EC2 instance is untouched, no logs being generated.
There is no issue with Signing secrets or Stripe keys, the event never reaches the HTTPS endpoint of the EC2 created using a Load Balancer.
Stripe's support cannot pronounce to this so any suggestions of why this could happen or how to handle it is very welcome.
The error displayed on Stripe is:
HTTP status code 500 (Internal Server Error)
Response Failed to connect to remote host
I have added a whitelist middleware to the express server running on EC2:
app.use((req, res, next) => {
console.log('Always inside ', req.originalUrl);
next();
});
before handling the stripe webhook URL
app.use('/afterpayment', bodyParser.raw({ type: 'application/json' }), afterPaymentRoutes);
in order to see if Stripe event reaches the server, which is not happening.
However, if i manually enter into browser the Stripe Webhook URL, domain/afterpayment, the result is as expected: whitelist middleware prints the message and webhook handler takes over.
I was having a similar problem, and watching this thread. In my case, the issues were a few different things. I'm forcing https to my site (elb is redirecting any traffic from 80 to 443). The app on my ec2 was accepting connections over port 80. Access to the site was working. I thought maybe stripe sending the webhook data to the elb was breaking because of the redirect. This wasn't the case. However, I had a security group that was only allowing access from my IP address (for testing). Changing this to 0.0.0.0/0 from the internet (actual production access) didn't completely fix the problem but I wanted to get things set up to as close as real-world as possible. In the stripe dashboard I created a new webhook pointing to the app endpoint I exposed for testing. From the Stripe dashboard I hit the "Send a test webhook" button. This time instead of getting a timeout the error was invalid signature. So, I knew that exposing the site to the internet was part of the problem., (Yes, I could have created a security group that only allowed access from the IP addresses where the webhook data originates from, but again - I wanted to keep this as close to production as possible thanks #justin-michael for the nudge in the right direction). My app was still using the test webhook I set up for development. When I created the new webhook it also created a new signing secret. I pulled this new webhook signing secret into my app then ran the "send test webhook" again and it was successful. So, allowing the correct access from Stripe and making sure the signing secret was correct fixed the problem for me.
The problem was that the domain was not properly exposed on the internet.
So I have Elastic Beanstalk environment running a node.js server app on which I set a Load Balancer and exposed the server over HTTPS.
While trying to catch a webhook sent by a 3rd party app, like Stripe, nothing arrived on the server, even though I could successfully simulate POST request to the domain endpoint. The domain was also accessible through browser (or so it seemed).
The issue was that the domain name linked to load balancer was not resolvable publicly on the internet. Here are 2 useful links:
https://www.ssllabs.com/ssltest/index.html
https://dns.google.com/query?name=&rr_type=ALL&ecs=
Running tests on them unveiled problems related to DNSSEC configuration of my domain, which was not enabled on my domain.
While following this instructions i did:
On Hosted Zones, under DNSSEC signing -> Enable DNSSEC signing.
Created KSK and Customer managed CMK
Under DNSSEC signing, copied the information from View information to create DS record
On Route 53, on Registered Domains -> on the domain -> DNSSEC status, created a new key with info from previous step
After this, all tests passed and the webhook was successfully handled.
I have implemented a Django web app on AWS Fargate using Docker behind Application Load balancers.
When I try to log in to the web app I get the following:
Error 403 CSRF verification failed. Request aborted.
Environment:
I am using Application Load Balancer (ALB) as per the best practices of AWS. The ALB also has a TLS certificate to properly handle HTTPS when I run multiple instances of the web app.
I tried to resolve the issue by forcing stickiness of the ALB targets assuming that the Round-Robin lands the requests on different servers. I also reduced the number of docker instances to one (so there is no Round-Robin).
None of this made any difference.
I managed to log in (to get CSRF to work well) was when I connected directly to a docker instance (no Load Balancer) and when I used only HTTP on the Application Load Balancer - disabling redirect to HTTPS. This leads me to believe that the issue is between the HTTPS part of the load balancer and the Django web app.
Disabling HTTPS is not production ready, so I am back at square one. I saw a similar question posted here, without answers:
django posts receive CSRF verification failed after switching to load balancer
After placing a debug on the live system as a temporary measure the underlying issue became clear.
Referer checking failed -
https://test.domain.tld/path/ does not match any
trusted origins.
The solution is through the CSRF_TRUSTED_ORIGINS parameter in Django. A quote from the Django documentation:
CSRF_TRUSTED_ORIGINS
Default: [] (Empty list)
A list of hosts which are trusted origins for unsafe requests (e.g. POST).
For a secure unsafe request, Django’s CSRF protection requires that the request have a Referer header that matches the origin present in the Host header.
This prevents, for example, a POST request from subdomain.example.com from succeeding against api.example.com.
If you need cross-origin unsafe requests over HTTPS, continuing the example, add "subdomain.example.com" to this list.
The setting also supports subdomains, so you could add ".example.com", for example, to allow access from all subdomains of example.com.
A similar discussion and solution can be found in this thread.
CSRF validation does not work on Django using HTTPS
I have a backend service i'm running in Fargate. I need this service to have an SSL cert on its load balancer so that it can talk to other HTTPS services. I've created the load balancer and it gives me an AWS domain (my-cool-app.us-east-1.elb.amazonaws.com).
Now, when I try to request a certificate through acm, it fails and says "Additional verification required". So i'm not sure if it's possible to add an SSL cert to this load balancer without registering a custom domain?
Also, this is a Django app and I haven't done anything other than keep it as runserver which I know isn't good for production but I just need to start by making it work as a dev environment. Do I need to change the way Django runs in order for SSL to work? Or is the load balancer sufficient?
To use an SSL for a domain you need to have control over that domain. For the AWS managed certificate service (ACM) you can verify through either DNS validation or email validation both of which you must essentially have domain control to validate.
As you're trying to use ACM for a AWS owned domain, someone from AWS would need to approve the SSL (which they won't).
Regarding your second point what you're describing is SSL offloading, in which the load balancer will serve HTTPS and then terminate encryption in transit. It will then forward the request to the Fargate container using the protocol and port defined in the target group.
The only thing you want to consider is how you display to the user, for example ensure that all CSS, JS ans links on your site are HTTPS. You can detect whether the incoming request used HTTPS at the load balancer by inspecting the X-Forwarded-Proto header in your application.
I am trying to set Listener rules on an ALB. I want to add Google Oauth support to one of my servers.
Here are the Google endpoints I am using
I see google auth page alright, but on the callback url I'm seeing 500 Internal Server Error. I've also set the callback URL. Am at a loss as to what's wrong here. Any help is most appreciated!
After authentication, I'm not redirecting to my application, instead I've set ALP to show a text based simple response.
I struggled with the same problem for hours, and in the end it turned out to be the user info endpoint that was wrong. I was using the same one as you, but it should be https://openidconnect.googleapis.com/v1/userinfo.
I haven’t found any Google documentation saying what the value should be, but found this excellent blog post that contained a working example: https://cloudonaut.io/how-to-secure-your-devops-tools-with-alb-authentication/ (the first example uses Cognito, but the second uses OIDC and Google directly).
From AWS documentation
HTTP 500: Internal Server Error
Possible causes:
You configured an AWS WAF web access control list (web ACL) and there was an error executing the web ACL rules.
You configured a listener rule to authenticate users, but one of the following is true:
The load balancer is unable to communicate with the IdP token endpoint or the IdP user info endpoint. Verify that the security groups for your load balancer and the network ACLs for your VPC allow outbound access to these endpoints. Verify that your VPC has internet access. If you have an internal-facing load balancer, use a NAT gateway to enable internet access.
The size of the claims returned by the IdP exceeded the maximum size supported by the load balancer.
A client submitted an HTTP/1.0 request without a host header, and the load balancer was unable to generate a redirect URL.
A client submitted a request without an HTTP protocol, and the load balancer was unable to generate a redirect URL.
The requested scope doesn't return an ID token.
I have an iphone app based on sharepoint REST API CRUD operations. To do these operations, I get a fed auth cookie in the app launch using a custom login (sharepoint page) and thereafter all interactions are done using REST API calls. The problem we are facing is that randomly we are seeing abrupt session logout. While researching, we found out that this might be a stickiness based problem. So, we want to enable stickiness on our F5 load balancer. Now my question is- Is stickiness something that is browser dependant? If the requests keep moving via API calls and not through browser requests, which stickiness is recommended?
If your application supports cookies, then you can use cookie persistence. Otherwise, you can use source IP address affinity.