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
Related
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'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! :)
I've got a Laravel app that's hosted on Heroku, currently in staging environment that's password protected. It's accessible via https:// but axios is making requests to http:// and causing a cors error... I've tried adding allow origin headers as middleware on the routes but that doesn't fix the error.
Is there a way to force axios to use https by default? I don't want to pass the full URL to the axios.get()
This doesn't happen on local so could it be something caused by Heroku?
There is a Pull Request on the way that will try to access http/s if the other protocol fails. So it's a matter of time now.
I think the issue is actually related to Heroku but I can't be certain.
The only thing that tells me this is that I moved to an EC2 instance via Laravel Forge and I don't have any problems.
Strangely I also had a couple of files that were being requested without www. And when viewing in browser it forced the css files to the naked domain. What's weird though is other css files loaded with www. And weren't redirected so I think it could also have been a permissions thing.
I solved the file issue by simply changing the file name and the redirect stopped so maybe an overzealous redirect. Either way it was annoying and I think I tried everything so hopefully that information helps somebody else in future.
Cheers
I'm using CloudFlare in my website and it works perfectly. Problem is, I decided to host my static files like JavaScript, CSS, etc. in static.example.com and I don't know how to set up the subdomain.
I already tried adding a CNAME record (static is an alias of example.com) and it didn't work, and as a A record (static points to IPAddress) where IPAddress is the IP address that both www and example.com use.
I'm I doing something wrong? I've waited about an hour for any DNS propagation problems and still doesn't work.
If you have added the subdomain in your CloudFlare DNS settings (settings->DNS settings), then it should start propagating out after a few minutes or so. If you're still having issues with the subdomain, please contact CloudFlare with the domain name so we can look at it.
I had the same issue until I realized I had to click on the greyed out cloud on that row to activate Cloudflare on the subdomain. This is what it currently looks like:
The instructions at the top of the page clearly say you have to do this, but I'm not one of those read the manual types for simple tasks. I guess what would have really got the point across was some sort of notice the very first time I added a subdomain on my account.
Once you've clicked the icon, then the activated proxy will be indicated like this:
Oh well, hope this helps somebody else.
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.