I'm allowing my customers to upload large files. Because I'm using Cloudflare, anything over 100 MB gets rejected, which is no good.
So what I'm thinking of doing is switching the upload form action from mysite.com/upload to mysite.net/upload. This way I'm using a domain name that isn't going through Cloudflare, so file sizes won't be restricted.
I've set up mysite.net as a site in Forge to mirror mysite.com by setting the root location in nginx to point to the current folder of mysite.com. So now when someone goes to mysite.net they see the contents of mysite.com.
Unfortunately, mysite.net is now open to DDOS attacks because it isn't running through Cloudflare.
So what I'd like to do is make it so that mysite.net/upload is the only route that's open under that domain, and that it's only accessible from my load balanced servers.
Is this possible, and if so: how do I do it?
I've been researching this and haven't really come across an answer that applies to me, the most common scenario is using subdomains, which is not applicable in my situation.
Figured it out; I decided to use a subdomain as it was easier.
I went into Cloudflare, added the subdomain upload.example.com (of course, use your real domain) so traffic could hit it, and then turned off protection for the subdomain so that large files could be uploaded.
I updated my .env file and added the SESSION_DOMAIN variable, so that the user's session will work across both example.com and upload.example.com domains.
SESSION_DOMAIN=".example.com"
Notice that the domain starts with a period, and the value is enclosed in quotes. If you omit the quotes your users will not be able to login to your app, and if you use Envoyer omitting quotes will break the decryption when editing your .env file.
I then added a new group to my routes file to handle traffic to the subdomain. I added a route to redirect all GET traffic back to the original site (https://example.com), and added a POST route to handle the uploads.
Route::group(['domain' => 'upload.example.com'], function () {
Route::get('/', function () {
return redirect(url('https://example.com'));
});
Route::post('upload', 'UploadController#store')->middleware('throttle:4,1');
});
And then in my form...
<form action="https://upload.example.com/upload" enctype="multipart/form-data">
Finally, I cleared my browser's cache and cookies, then logged into the site and uploaded a large file! :)
Related
I have this problem since several days.
I'm developing a Vuejs/laravel app, using Sanctum as an authenticator. where laravel mainly have the api gestion role, and I've started to deploying it. On Local, everything looks fine, api and auth are working.
On deploy, since my app is binded to be in a subdomain (laravelapp.maindomain with folder path of domain/laravelapp), when i try to access any page (vue-router) instead of domain/laravelapp/login i get domain/login, even if the page itself is looking fine.
If i try to reload the redirected page (domain/page) i have a 404. Also, since every API is pointing to domain/api/link instead of domain/laravelapp/api/link, everything is broken starting with auth.
I've tried modifying .env file, RouteServiceProvider, .htaccess(but i have no knowledge about that).
I also tried to set the subdomain Document Root to domain/laravelapp (it's the first thing i've done), but not only it dosn't work, if I try to print on screen subdomain's root, it returns domain. It's becoming a real issue right now, thank you for any help.
EDIT: I've discovered something. in the main domain there is a Joomla application. The api route contains the Joomla redirect (like, there is a plugin oh the site that changes language automatically, appending /en /it /de given the chosen language). So, in my case, the api is domain/index.php/en/subdomain. I tried again being more specific with document root, with no results, and playing around with .htaccess, but with no success.
I searched for my issue in so many ways, but I don't seem to find the correct case, so I'm asking here.
I have a Laravel app which is installed on a server and everything works correct. The domain is set as HTTP only and is configured from AWS. However we need to have another domain which should work only from HTTPS. The HTTP domain is pointing to the server instance and the HTTPS one is pointing to a CloudFront distribution with origin the HTTP domain. The issue is that when I open the HTTPS domain, all of the links and images are loaded from the HTTP domain.
To be more concrete, let's say I have http://mysite-notsecure.example.com and https://mysite-secure.example.com.
When I open http://mysite-notsecure.example.com everything works as it should and there are no issues. However when I open https://mysite-secure.example.com the site loads, also files like app.js and app.css load with the correct host, but things like fonts, images, links, etc, load from http://mysite-notsecure.example.com.
Because most of the urls are built with the url() function, I think the issue has something to do with APP_URL, which was first set to http://mysite-notsecure.example.com, but when I added the new domain, I set it to empty (APP_URL=),
however the urls are still built the same way (I cleared config cache).
What should I do in order for my site to build the urls according to the current host?
I don't need any other change for the two domains. They should load everything exactly the same, only the host should remain and not redirect to the other domain.
It turned out there were two different issues.
I'll describe them here, because there is a slight chance someone could be dealing with one of them.
First, I printed the contents of the $_SERVER variable on both domains and the host in both was the same - the HTTP domain.
This issue was from the CloudFront configuration. Turned out the Host header was removed from the CF distribution behavior, so that CF replaced it with the origin's value (the origin is the http domain). After this was fixed, the host in $_SERVER appeared correctly.
But the initial issue for the urls building was something else which I didn't think of. After clearing the cache to remove the debugging and seeing the right urls on the HTTPS domain, I switched back to the HTTP one and saw now there all the urls pointed to the HTTPS domain. That is when it hit me that these domains share not only the configuration, but also the cache. And most of my urls on the page I was testing with, were coming from a function with cache, so when the cache was stored from one of the domains, they appeared the same on the other. When I included the host in the cache key, everything worked correctly.
Hope this helps someone else.
goto file .env and setup the APP_URL=https://mysite-secure.example.com/ and change
href={{asset('folder-path')}} in layout or blades file
I have a Laravel website with LAMP stack and host on a ec2 server. I setup the Virtual Host configuration for the host name www.abc.com and it works fine. One day, The client said they want to use their domain to visit the website like www.client.com/abc. They use the reverse proxy to point our ec2 server. The first problem we met is the virtual host has failed and we fixed it by adding server alias setting.
ServerAlias www.client.com
The url has connected to the server correctly and the second problem is coming up. Because of the subfolder of the url www.client.com/abc, all the assets paths are failed. For example, we had fonts, styles and js paths that generated by laravel-mix:
{
"/js/app.js": "/js/app.js",
"/css/app.css": "/css/app.css",
"/js/login.js": "/js/login.js"
}
Those paths are absolute and it turns to 404 found on the website if we use the mix() helper function to load assets. The rendered url on the blade pages are wrong.
It would be
http://www.client.com/js/app.js
instead of
http://www.client.com/abc/js/app.js
And the fonts loaded from the vendor and styles, which use the relative paths and are converted to absolute as well. So we had to workaround this by adding the option processCssUrls: false to webpack.mix.js.
The third problem is the redirection when user logs in out. The defaults redirect url is /. I know we can change the redirect urls in middleware and controllers but it feels like so much workaround over this. Is there any better way to solve those problems?
To declare the question again, how to setup a Laravel project behind the reverse proxy with subfolder?
http://www.example.com/laravel
I was trying to solve the problem with cookie-free, the yslow has suggested to create a subdomain. I did, but the yslow still "show" the problem.
i didn't set the cookie´s domain in the page, cause i don't know how to do it.
anyone know a tutorial or a solution to this problem?
Create a subdomain such as static.yourwebsite.com which is where you will deliver all your static files from.
Point your new subdomain to the /wp-content directory for a WordPress installation.
For cPanel users, you will need to update the document root field from public_html/static to public_html/wp-content like the screenshot below. cpanel document root
Edit your config.php file to reflect the following:
define("WP_CONTENT_URL", "http://static.yourwebsite.com");
define("COOKIE_DOMAIN", "www.yourwebsite.com");
Now that your cookie domain and static content subdomain are set, you can begin delivering static content without the server setting an unnecessary cookie for static assets.
https://www.keycdn.com/support/how-to-use-cookie-free-domains/
To work around this problem, make sure that static components are requested with cookie-free requests by creating a subdomain and hosting them there.
If your domain is www.example.org, you can host your static components on static.example.org. However, if you've already set cookies on the top-level domain example.org as opposed to www.example.org, then all the requests to static.example.org will include those cookies.
In this case, you can buy a whole new domain, host your static components there, and keep this domain cookie-free.
Yahoo! uses yimg.com, YouTube uses ytimg.com, Amazon uses images-amazon.com and so on.
Read More
Serve static content from a different domain to avoid unnecessary cookie traffic.
When the browser requests a static image and sends cookies with the request, the server ignores the cookies. These cookies are unnecessary network traffic.
Move all your static content on a different domain, where no cookies
are set.
Move your static content on a different sub domain and set
all the cookies to the www subdomain.
Hey folks, working on a CI app that provides public ad well as private (secure) access. I have not implemented SSL before but i understand that part of the setup is specifying which folders should be accessed using https.
I would like some advice with regards to how i should structure my folders to facilitate that.
Does the setup only affect the controllers folder? in other words should I split my app controllers between a public and secure subfolders under the standard CI controllers folder?
Do I need to do do anything to my views and models folders? anything else I should be paying attention to?
Your help would be appreciated.
thanks
OK the best way to split things up the way you want, would be to:
Set up your CodeIgniter app under a folder, say /var/www and ensure everything is working as you want.
Set the base url for the site under the config.php of CodeIgniter to just "/".
Create an Apache virtual host for the secure portion of the site, listening to requests on port 443 or whatever. Install your certificate and so on. http://www.namecheap.com are good for certs. Set up the web root as the CodeIgniter folder, e.g. /var/www.
Create a further Apache virtual host, pointing to the same directory e.g. /var/www for the unsecure version of the website.
You will now, all being well, at this stage be able to access the entire site using either https or standard http. I think you mentioned being able to take things a step further by only allowing access to certain controllers via HTTPS and certain unsecure. What I would do for this is the following.
Create a CodeIgniter library, call it say Ssl.php, under your application/libraries folder. Put in the following code:
class Ssl {
public function require()
{
// Is the current request method secure, via SSL?
if ( ! isset($_SERVER['https']) )
{
// No. Do something here, display an error, redirect... up to you
show_error("This resource must be accessed through an SSL encrypted connection.");
}
}
}
Now, in your application controllers, simply load the library the usual way $this->load->library('ssl') and for any controller method that you wish to require an SSL connection for, simply call the $this->ssl->require() method before any execution starts.
You could even go a step further and drop that method call to require() in a class controller __construct() function, or even an entire new controller that you may wish to extend from.
I hope this helps in some way.
Hey, I am in the middle of developing a CI app that is successfully running with HTTPS/SSL.
I think you are a bit confused. As far as I know, you can only set up an SSL enabled site per se by creating a new site or "virtual host" if you are using Apache for example.
So essentially if you were using Apache, you would create a virtual host to handle requests on port 443 for say https://example.com and then set the web root to say /var/www or wherever your CI app sits. You would also have to configure Apache to use your certificate file, once you have bought the cert and downloaded the bits and bobs after generating the cert request. It's easier than it sounds.
Is there any reason why you can't just have your entire app running through SSL? Rather than an encrypted and non-encrypted section? There is a small CPU overhead for SSL but it is minimal.
I hope this helps in one way or another.
EDIT IN RESPONSE TO COMMENT:
You're welcome. It's a minimal overhead. For the hassle, I would just simple put it all under an SSL vhost. Plus, if you were to split content between SSL/non-SSL, you may notice that if you include non-SSL based content on an SSL page, users will get a pesky message in their browser about "insecure content" etc, which may put them off and create some needless doubt.
It may be quite difficult to split as you want - as you would need seperate root index.php CI files for each vhost to allow CI to route it correctly. You couldn't just set a vhost serving a directory such as application/controllers/private/ because CodeIgniter wouldn't know how to handle the request without some severe modification to it's core routing.
I would honestly just stick everything under an SSL vhost. Or, another option would be to set up two CI apps running from the same system/core CI folder... if that makes sense, but then sharing content such as libraries and models will become tedious.