In the previous projects did you maybe move the public dir file one dir up? Or if you are using virtual hosts did you point the document root to the correct directory?
Not sure if this could be a problem but these are the mistakes I always make :)
@citricsquid I know this isn't best practice but unfortunately I don't have a choice in our environment.
@Maccle415 I haven't changed the folder structure at all. I have a virtual host set up but it's just pointing to the folder that I have all of my projects in:
NameVirtualHost *:80
<Directory "/Users/me/Documents/Repositories/">
Allow From All
AllowOverride All
Options +Indexes
</Directory>
<VirtualHost *:80>
ServerName companyName
DocumentRoot "/Users/me/Documents/Repositories"
</VirtualHost>
If anyone has any good Apache resources, that'd be appreciated too. I feel like I have a decent understanding until I have to actually implement something and then it all falls apart, haha.
It's actually really horrible practice. If for some reason there are folders you simply CAN'T move use aliases. However you should probably rethink your architecture.
@enkay As I said, I'm aware that this approach sucks. It's not how I would prefer to do it but I don't have an alternative. I'm just trying to figure out why this workaround isn't working for this project.
Even in the most backwards environments you can still run Laravel without compromising on security, this doesn't just "suck", it's bad. If you can describe the limitations of your environment (is it shared hosting?) we can help you find the actual solution to your problem.
@citricsquid Ok. We have a shared internal server that we have only FTP access to. Different applications are located in different folders, e.g. oursite.com/deptname/appname. It's a bad setup but it's what we have to work with. Any ideas on doing this better?
If you have some leeway you could do the very simple solution and have 2 "applications", the core and the public.
department/
app1/
app2/
laravel-core/
app/
bootstrap/
vendor/
artisan
composer.json
laravel-public/
assets/
index.php
Then you modify laravel-public/index.php to reference the new "core" application, like so:
require __DIR__.'/../laravel-core/bootstrap/autoload.php';
$app = require_once __DIR__.'/../laravel-core/bootstrap/start.php';
Do you think they would allow you to do that?
I think I could probably get away with that. Just to clarify, would you have a laravel-public and laravel-core folder for each app in the department root? And then have an .htaccess file in the app folder pointing to the proper folder?
And could you explain how this is more secure since I can't actually change permissions on the different folders? I know it's a mess but thanks for your help!
Laravel uses the public directory to prevent access to your applications core. If you have an application that doesn't separate the public from the private then when you make a mistake in one of your files (for example include a closing ?> with trailing characters) or if your web server is misconfigured your applications core files are exposed to anyone with access to your website. You could very easily mistakenly expose your database password, your api passwords, your proprietary code... it's a potentially disastrous situation caused by just one small mistake. The absolute worst case when using separation of public and core is that you expose the contents of index.php which is nothing more than a bootstrap file: it just doesn't matter if that file is exposed.
You don't need to do any sort of .htaccess wrangling to use the setup that I posted above. This is the default Laravel file setup:
app/
bootstrap/
public/
artisan
composer.json
server.php
From the department/ directory:
- Rename
publictomyapplication - Move the remaining files and folders (app/, bootstrap/, artisan, composer.json, server.php) into
myapplication-core - Modify index.php in the new public directory (
myapplication/index.php) to reference the new core location (as shown in my post above
That's it, now when a user visits department/myapplication they are accessing your Laravel public folder and you haven't compromised on anything.
There are much better solutions for those with control over their web server (modifying the document root) but when you're in a situation like yours this is pretty much the best you can do.
@citricsquid I was aware of the issues but didn't realize there was a workaround given the limitations of the environment. Thanks for the help!
Sign in to participate in this thread!
Laravel
Laravel News
Laracasts
Laravel Podcast