Support the ongoing development of Laravel.io →
posted 9 years ago
Installation
Last updated 1 year ago.
0

Why do you want to do this?

Last updated 1 year ago.
0

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 :)

Last updated 1 year ago.
0

@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.

Last updated 1 year ago.
0

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.

Last updated 1 year ago.
0

@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.

Last updated 1 year ago.
0

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.

Last updated 1 year ago.
0

@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?

Last updated 1 year ago.
0

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';

(original config here)

Do you think they would allow you to do that?

Last updated 1 year ago.
0

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!

Last updated 1 year ago.
0

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:

  1. Rename public to myapplication
  2. Move the remaining files and folders (app/, bootstrap/, artisan, composer.json, server.php) into myapplication-core
  3. 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.

Last updated 1 year ago.
0

@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!

Last updated 1 year ago.
0

Sign in to participate in this thread!

Eventy

Your banner here too?

mrberggg mrberggg Joined 10 Feb 2014

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

Laravel.io

The Laravel portal for problem solving, knowledge sharing and community building.

© 2024 Laravel.io - All rights reserved.