In shared hosting environment, how to hide .env file from public?

Did you configure your server to host the public folder? Check if you have a .htaccess file in your public...

Have you changed the location of the .env file?

A default Laravel install has the .env file located one level up from the public folder and by default shouldn't be accessible.

  laravel\
      -> .env
      -> public\

You might need to check your nginx/apache configuration and check that the web root is public.

Can you provide your nginx/apache host file?

I do have an htaccess file.

I don't believe I have the server to host the public folder; everything is in public_html.

Add the following .htaccess to the root of your project:

RewriteEngine on
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://examle.com/ [R=301,L]
RewriteCond %{REQUEST_URI} !public/
RewriteRule (.*) /public/ [L]

I wish I had a dollar for every time proper folder structure was answered. But here we go again:

First use this as a guide:

http://novate.co.uk/deploy-laravel-5-on-shared-hosting-from-heart-internet/

Second your folder structure would be like this:

https://i.imgur.com/Oo6k4Fp.jpg

Third your htaccess add the line:

    RewriteEngine On
    RewriteBase /laravel54/   //Change this line to your use case

A similar guide:

https://laravel-news.com/subfolder-install

Note in the guide:

FTP everything except your public folder into the back-end folder that you created (dj3core in my example)

FTP the contents of your public folder into the subdomain folder (dj3 in my example)

and

// require __DIR__.'/../bootstrap/autoload.php';
require __DIR__.'/../../dj3core/bootstrap/autoload.php';

and

// $app = require_once __DIR__.'/../bootstrap/app.php';
$app = require_once __DIR__.'/../../dj3core/bootstrap/app.php';

Use your names, and adjust as needed for laravel 5.8

If the guide is followed, this whole process only takes a few minutes.

=====================

Display an image use asset helper:

<img src="{{ asset('assets/upload/imgdogs') . '/' . $row->dogpic }}" alt="" class="image"></a>

Load basic resource:

<link href="{{ asset('assets/css/dog/style.css') }}" rel="stylesheet">

Load js

<script type="text/javascript" src="{{ asset('assets/js/jquery.js') }}"></script>

But use your folder names.

If using mix, follow documentation.

In shared hosting environment, how to hide .env file from public?

You don't, it's not in public_html so it can't be exposed. It's exposed only in an in-proper folder structure.

Just make sure your web server ONLY serves the public folder. Don't try hacking it with .htaccess trickery or editing index.php

Put everything on the same level as public_html and then create a symlink between public_html and the public folder in your laravel install.

Put everything on the same level as public_html

No, very insecure that way.

Just curious, but websites have been in the public_html directory for decades without be insecure; why is Laravel insecure by being in the public_html directory.

Because people actually use the EnV file in a production environment where it's only meant to be used in development.

Type

Yoursite.com/.env

What is scary is the thought of having to explain such a detail.

That is correct, but you have to remember that the old websites "everything" was intended to be seen by the people browsing the site. I'm just guessing here but if you are using Laravel you are probably accessing a database and may be adding data and running procedures on that database. That requires a different level of security that in the old websites. If you look at the public folder in Laravel it almost have nothing, just a few files and the pictures you are showing in the site. Everything else is hidden to the public.

jlrdw - The question was to be the devil's advocate to see what makes Laravel different than all the other websites in the world that are perfectly secure in the public_html folder.

Obviously this Discussion of Laracasts isn't about open conversation, it appears that it is a place to judge people and their knowledge of things.

Because people actually use the EnV file in a production environment where it's only meant to be used in development.

@jlrdw Please tell that to Taylor, who uses .env for websites hosted on the Laravel Forge service. Are you saying he is wrong and doesn't know what he is doing and millions of sites are insecure because they use .env in production?? Please explain. It even has an editor to edit the .env file in the browser on the live production server.

Incoming story on a Logistics company or some random pet code.

@jlrdw Not sure how putting your project on the same level as public_html is very unsecure? Consider this scenario and correct me i'm wrong.

home/user
    -public_html -> home/user/source/public (symlink)
    -source(laravel files)

if this is unsecure and incorrect let me know because i've done it wrong on many sites.

@yougotnet the way a laravel installation works is instead of using public_html laravel uses public instead. So you have to look at it that way and you will see that the .ENV file is outside of the public folder which makes it inaccessible and secure. I hope this helps you out.

If this is all about the .env file; then I moved the .env file back one directory and updated the bootstrap\app.php to include the new path $app->useEnvironmentPath(realpath(DIR.'/../../'));

So would this mean I am still not secure?

Well, letting someone browse your storage folder (eg logs) might not be a good idea.

Its not about if the folder is called public_html or public or htdocs or whatever. The point is that you want some stuff private and some stuff able to be served by your webserver. Just don't mix them up without truly knowing what you are doing.

Eg https://www.novochem.net/storage/logs/

I totally get the concept and the documentation for Laravel and I understand web security; all I was trying to do was analyze Laravel to know for sure what individual parts of Laravel need to be protected (hidden from public) and what can be visible to the public.

I don't just want to be a user/programmer of Laravel; I want to be a master of Laravel and understand as much as I possibly can about it.

Thanks for everyones input!

all I was trying to do was analyze Laravel to know for sure what individual parts of Laravel need to be protected (hidden from public) and what can be visible to the public.

Did you at least look at:

http://novate.co.uk/deploy-laravel-5-on-shared-hosting-from-heart-internet/

That is not from me, but a guide I use for shared hosting. It is the proper technique for shared hosting.

If using D.O., they have tutorials.

I am waiting to see if @talinon offers you some assistance.

@jlrdw

You're right. I should stay on topic. I'm unable to provide any further advice on .env security that isn't already answered by your join query. Thank you for clearing up the thread's topic with that relevant code snippet.

Also, I should thank you for clarifying that .env should only be used in development environments. Honestly, I had no idea. I guess I'll remove the .env file from all production servers and hard-code everything in the configuration files and commit those changes to version control. Does that put me back on the right track?

are you saying you do not remove main laravel out of public

No, I was saying that the statement you made that I quoted, was false.

@jlrdw seriously you need to find a project to work on. People loose interest in these long rambling argumentative posts. They are not helping the OP. Neither are all the posts that just say "Learn Laravel". Its just one extreme or the other. Please try and stay on topic. Answer the question succinctly and stop playing my answer's better than your answer because I have loads of time to kill.

@jlrdw Read the first part of the sentence you quoted before the highlight....

PHP's execution model (shared nothing) does not work well with having to read and parse the contents of a file for every single request, thus the reason I say this library was not designed for production

That's correct for an app that you pull the DotEnv library into and don't take anything else into consideration, however, laravel specifically has ways to cache the config for production using artisan config:cache, which means the part of the quote I highlighted is negated by that fact. It doesn't parse the .env, or config files in production. It reads them from the cache. https://laravel.com/docs/5.8/configuration#configuration-caching

@cronix I agree with you on that, my only part I was trying to convey for OP is:

The .env can be read in the URL if the folder structure is not set correctly in a shared hosting environment, nothing more nothing less.

Granted this post got a little out of hand, maybe we are all a little guilty on that.

Your above comment is what I meant by it's been expanded in usage.

I know how Taylor uses the .env.

I did not fall off a turnip truck yesterday, it was a manure truck.

And

People loose interest in these long rambling argumentative posts

I only get that way when someone sets me off, like @talinon did.

Otherwise

Look at my first answer, that should have been good enough.

But then someone instead condoned putting all under public_html, well .... read what you will into it. But that is wrong period.

@snapey you are really something sometimes, you jump all over me yet someone above can post:

Incoming story on a Logistics company or some random pet code.

And you don't say anything. You completely did not even give me any credit for first answer, which actually comes from you.

So please if you are going to jump on me for a reply (I am okay with), at least jump on others for a bad reply as well. Or leave it alone if you can't be fair.

Listen, I know you're trying to help.. but, you constantly reply with irrelevant, misguided information. You reply to random things, often incorrectly, and then argue over it for as long as someone has the endurance to keep up with you. Even when proven wrong, you still keep it up with long-winded replies trying to prove some obscure point that no one cares about.

Perhaps my reply was unprofessional, and I apologize for that. Although you just proved my entire point.

You've been triggered for hours over this. Drop it and move on.

@talinon okay

Perhaps my reply was unprofessional, and I apologize for that.

I appreciate you saying that.

And I will admit it got out of hand after my first reply which is correct.

That reply actually is not mine it came from someone else I just use it.

I admit I really get steamed at times.

Create .htaccess file in your Root Directory and put the following Code.

options -Indexes
#hide a Specifuc File
<Files .env>
order allow,deny
Deny from all
</Files>```

Also, protect dot files with this following Code.

```# Block access to dot file
location ~ /. {
    deny  all;
}```