We have developed a Laravel application which is working fine. Once we enabled CDN (Amazon Cloudfront), it stopped working all forms. Wherever there is a form submissions like Login, Contact us , etc. It's not at all working.
We have identified that there should be some changes we have to do for Laravel applications, we are looking for help from some experts who have successfully configured Laravel application with CDN.
We are using PHP 7.1.20 and Laravel 5.4 versions.
I think you misunderstand the use of CloudFront as a CDN, or any CDN for that matter.
You don't put it in front of your whole site - it doesn't serve your site. It serves as cache for your static assets: your media, stylesheets and scripts. Everything else is still served directly from your PHP application.
You can set the ASSET_URL environment variable for your application and Laravel will use that to point to your assets when you use the asset() or mix() helpers.
Contrary to the accepted answer you can, and often you should, put CloudFront in front of your application, not just in front of static files.
To clarify this is the setup that I'm talking about:
example.com -> CDN -> origin (ALB, API Gateway, S3 ...)
Why would you do that?
You can use CloudFront to terminate TLS meaning that your users will make a secure connection to the CloudFront and then CloudFront will communicate with the origin over plain HTTP.
How can this help? Instead of your Australia users doing a 3-way-handshake with your server in Germany, they'll do it with Cloudfront closes PoP probably in Melburn. You can see how this lowers the latency. You might be wondering if is it okay to transfer data over plain HTTP from CloudFront to origin. AWS will still encrypt your data:
All data flowing across AWS Regions over the AWS global network is automatically encrypted at the physical layer before it leaves AWS secured facilities.
They just do it on the first OSI layer, instead of 4 where TLS happens. Is this enough for you? If you are not dealing with regulators or highly sensitive data, probably yes. If AWS security measures fail and somebody is able to spoof traffic inside the AWS data centre - you are probably not the attacker's target.
Quote from Cloudfront FAQ:
For files not cached at the edge locations and the regional edge caches, Amazon CloudFront keeps persistent connections with your origin servers so that those files can be fetched from the origin servers as quickly as possible.
What they are saying is that when a user makes a connection to CloudFront, CloudFront will make a connection to the origin (if one is not already open and a file is not cached) and will keep that connection alive. That means that any subsequent, not cached, request coming from any user will experience lower latency since CloudFront will reuse that same TCP connection from CloudFront to the origin.
Use optimized AWS global network to communicate from the PoP to the origin instead of going over slow internet. AWS Docs
Cloudfront (or other CDN providers like Cloudflare) can help you absorb some DDOS attack requests and protect you, especially if you turn on AWS WAF and AWS Shield Advanced.
You can benefit from Cloudfront even for routes/files that are not cacheable.
My go-to cache setup is the following. I cache /img/*, /css/* and /js/* routes, and all others I just proxy to the origin over HTTP.
You are probably aware of performance gains on cacheable content. So I'm sharing here results from non-cacheable requests (the one which goes all the way to Laravel) with and without CloudFront in front of app:
Please note the SSL/TLS latency decrease. Response time is just the global average. The performance increase is higher from locations that are further away. For example, we have lowered the latency from Sydney from 1.3 seconds to 0.6s for the same request just by having Cloudfront in front of it!
To answer your question, both the ASSET_URL and APP_URL are the same, we point to the domain to CDN distribution and play a bit with caching policies.
You can set up your Cloudfront distribution to serve 2 origins. One is your static assets inside an S3 bucket while the other origin is your ELB or EC2 that handles your Laravel App. For this to work you must forward the proper cookies, headers, and allow the required methods to your Laravel origin.
It looks like this https://aws.amazon.com/blogs/aws/amazon-cloudfront-support-for-custom-origins/
After re-reading your question, it seems you already set up the custom origin and possibly you are just not forwarding the XSRF-TOKEN. If Laravel is responding with 419, that is most likely the case. Try whitelisting that token and the session token as well.
If your forms stopped working it sounds like you need to enable the POST method in Cloudfront. Open the relevant Cloudfront distribution, select behaviours and edit the default one.
There is a setting called "Allowed HTTP methods". It needs to be set to allow "GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE" for forms to work.
