Session Bounced with AWS ELB with multiple instance? - session

I am facing an issue with AWS ELB with multiple Server with LAMP for an ecommerce webstite.
When an user login with domain, which is pointed at AWS ELB, the session is bounced automatic ever (User is logout). I am trying with enable sticky session for both application and duration.
But my issue is not solved, when i am pointing domain direct ec2 instance without elb, everything working fine.
My ecommerce website is on oscommerce.
Please suggest me for this case.

This is definitely an issue with session stickiness on your ELB.
An ELB has two options for stickiness, an application generated cookie that if you enter the name of the AWS ELB will generate it's own cookie from that cookie and build stickiness upon that, or you can have the ELB generate it's own cookie and maintain stickiness this way.
I suggest that you use "Enable load balancer generated cookie stickiness".
To confirm it's working, if you inspect the website's cookies you should see a cookie named AWSELB and the cookie data shouldn't change between page loads.

Related

Laravel: customize auth session data (get the correct ip address)

My app is hosted on AWS Fargate, behind a load balancer. All incoming requests have the IP of this load balancer. It stores the original IP in the "X-Forwarded-For" header. Laravel can retrieve that easily.
I'm using the database driver for the auth session, and I noticed that it stores the IP address. If that IP address was correct, it would be very useful to me for other purposes.
So the question is: how can I customize the code that manages the session, so that instead of storing request()->ip(), it stores request()->header('X-Forwarded-For') ?
Thank you
the solution was to do this. I don't fully understand why, but it works.
AWS Application Load Balancer real user ip problem
trusting my loadbalancer as a proxy apparently allows the request()->ip() method to retrieve the correct IP.

aws elastic beanstalk / S3 The page was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint

I have a Spring boot application deployed using AWS Elastic Beanstalk, im using S3 bucket for my angular app.
I have generated certifacate using aws certifacate manager and created CloudFront Distribution so my angular app is loaded on https.
The problem is I am calling a rest API from Https deployed Application to Http Rest API.
I keep getting this error:
Mixed Content: The page at "https://mywebsite.com" was loaded over HTTPS, but requested an insecure XMLHttpRequest 'http://myendpoint'. This request has been blocked; the content must be served over HTTPS.
I tried generating my own certificate in my spring boot application it worked locally but once deployed on elastic beanstalk web services doesnt respond.
any tip on how use https / beanstalk ?
The error message sums the problem clearly. It would be a huge security issue to allow unencrypted data transfer, for seemingly securely encrypted web page.
Moreover, you don't really want to do SSL termination on your instances, for performance reasons, you don't want to manually manage keys an so forth.
In your situation, I would advise setting up a CloudFront distribution in front of your ALB (which I assume you have). That will solve your problems immediately, as CloudFront will automatically setup a domain for you and will expose your endpoints via HTTPS. Afterwards if you decide, you can easily setup a custom domain and certificates.
Finally, I recommend reading this article to make sure you avoid common pitfalls when configuring ALB and CloudFront.
Best, Stefan

Laravel Socialite behind Nginx load balancer

I have a Laravel 7 APP with two instances behind an NGINX load balancer with SSL terminating at the load balancer, I've set up Trusted Proxies as described in the Laravel documentation which is working as expected and all traffic is using HTTPS. I have both Laravel instances using the same Redis server for session and a separate Redis server for cache, and both instances are using the same session domain in .env
Both Laravel servers work correctly if they are the only instance in the load balancer. However when both Laravel instances are added to the load balancer any Socialite login fails with an invalid state error.
HTTP 500 Internal Server Error
Laravel\Socialite\Two\InvalidStateException
AbstractProvider->user()
/app/Http/Controllers/Auth/LoginController.php (line 108)
// Get google user data
$google = Socialite::driver('google')->user();
I have the same issue with both Google and Facebook logins. If I try to login manually or register a new user I get 419 | Page Expired, but none of these issues occurs when the load balancer has only one instance or I don't us a load balancer.
Thanks,
Lee.
Ok so I've fixed the problem, I rebuilt the .env file and then cut and pasted into both servers, I then generated new keys and restarted the app servers and the load balancer.
I'd gone through and checked both .env files several times, so either I missed something or the issue wasn't visible ?
Either way it's working now.
Thanks,
Lee.

Using facebook login on multiple virtual machine website ec2

I have a website https://en.mypen.net that allow people to login with facebook and google.
The website is hosted on AWS.
the problem is that when I have more then 1 virtaul machines, getSessionFromRedirect() returns a session only if Im redirected to the same machine. Because I have 3 machines now, it works only 33%.
The address is the same. Any idea why Its happening? Im using CNAME from en.mypen.net to elsatic beanstalk.
Right now the session information exists on the server. When you have 3 servers the session only exists on one of them. There are two possible solutions to your problem:
Setup a distributed session store so that when a session is created by one server it is made available to all the other servers. This is the most scalable and fault tolerant option.
Enable sticky sessions. This is the quickest and easiest option. Just be aware that if Elastic Beanstalk scales down the number of instances, some sessions will be destroyed.

Session stickiness on Amazon Web Services

I'm a bit confused about the use of the session stickiness on Amazon Web Services. When I deploy my java web application using Amazon Elastic Beanstalk, I can choose to enable the session stickiness and then specify a cookie expiration period.
My application uses cookies for the session (JSESSIONID) as well as for other small things. Most of the website is accessible only after logging in (I use Spring security to manage it). The website will run on up to 25 small EC2 instances.
Should I enable the session stickiness? If I don't enable it, does it mean that I could be suddendly logged out because the load balancer took me to another server (not the server that authenticated me)? If I enable the session stickiness, do I get logged out when the server that authenticated me gets shut down? Basically, why and when should I use session stickiness?
Thank you very much.
If I don't enable it, does it mean that I could be suddendly logged out because the load balancer took me to another server (not the server that authenticated me)?
Yes
If I enable the session stickiness, do I get logged out when the server that authenticated me gets shut down?
Yes
When using Elastic Beanstalk with a typical Java webapp, I think you will definitely want to enable session stickiness. Otherwise each HTTP request from a user's browser could be routed to a different server.
To get around the issue of the user's session being destroyed when the server they are "stuck" to gets shut down you would need to look into Tomcat session replication. This isn't something that Elastic Beanstalk comes with out of the box unfortunately, so in order to setup session replication you would have to create a custom Elastic Beanstalk AMI for your application to use. Also, you would have to use an implementation of Tomcat session replication that does not rely on multicast, since multicast isn't available on AWS, or any other cloud environment that I know of. An example of an implementation that doesn't rely on multicast would be one that uses a database (such as Amazon RDS) or memcached server (such as Amazon Elastic Cache) to make the sessions available across multiple Tomcat instances.
Also note that the Elastic Beanstalk UI only allows you to enable load balancer-generated HTTP cookies. However after Elastic Beanstalk has created the load balancer, you can go into the EC2 console and modify the load balancer's settings to switch it to application-generated HTTP cookies, and then tell it to use the "JSESSIONID" cookie.
You can also use DynamoDB for tomcat session sharing: http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-tomcat-session-manager.html

Resources