Владислав
Это всё детали.
Даниил
Владислав
Вася может просто сделать git clone и вы даже не узнаеете.
А
Сегодня у вас репозиторий не публичный. Завтра один из членов команды возьми и дай доступ Васе, чтобы он помог с фичей. Или возьми и сделай форк. Или завтра сайт вскроют. Вариантов много. И хранить пароли в гите просто не безопасно.
если ломанут сайт то тут уже ни что не поможет. там и так все настройки будут и не важно в конфигах они или в .env
Владислав
Владислав
Как раз, если настройки в env, то будет только ваш исходник, который как Неуловимыый Джо, и нахер никому не нужен :D
А
Как раз, если настройки в env, то будет только ваш исходник, который как Неуловимыый Джо, и нахер никому не нужен :D
а на сайте значит оне не смогут добраться до .env? хаха
Владислав
Ну фаервол ещё можете потюнить.
Владислав
Если совсем страшно )
Владислав
У вас вообще не должно быть доступа к корню проекта. Только к паблик директории.
Владислав
Очевидные вещи, не?
Владислав
и как это помогает если получили доступ к исходникам по ftp или ssh?
Госпаде. Если такой доступ получен, то никак. ) Но тогда ваша версия, что .env не безопасен, вообще чушь, извините.
А
Госпаде. Если такой доступ получен, то никак. ) Но тогда ваша версия, что .env не безопасен, вообще чушь, извините.
ну и ответь теперь на вопрос зачем держать настройки в .env на сервере?
Владислав
1. Чтобы не держать их в гите (это не безопасно, доступы там к фтп/ссш не нужны)
2. Это удобнее (очевидно снова, не?)
А теперь расскажите мне, на чём было основано ваше утверждение, что .env на проде - это плохо. Как я понял, на том, что вас таки могут вскрыть.
А
https://toster.ru/q/504565
Владислав
Там и пишут то же самое, что я вам говорю сейчас.
А
Там и пишут то же самое, что я вам говорю сейчас.
It is important to remember that this setup should only be used for development. For production you should still set your environment variables in the standard way
Владислав
Речь про настройку.
Владислав
ОК, зачем тратиться на считывание.
Владислав
Возвращаемся к вопросу, хранения в git
Владислав
И к моему вопросу относительно что лучше.
Владислав
В плане безопасности. Вы ответили, что .env не безопасен, если будет получен доступ к серверу, всё верно?
Nik
То дальше уже похрен :)
Владислав
вы как делаете сборку проекта на сервере при изменении?
Я выше описывал уже этот процесс коротко.
Владислав
Вы так и игнорируете мой вопрос.
Владислав
Следовательно, ответа внятного у вас нет.
Владислав
1. Чтобы не держать их в гите (это не безопасно, доступы там к фтп/ссш не нужны)
2. Это удобнее (очевидно снова, не?)
А теперь расскажите мне, на чём было основано ваше утверждение, что .env на проде - это плохо. Как я понял, на том, что вас таки могут вскрыть.
Владислав
видать вы в команде не работали
Работал и не в одной. ) Ваши заблуждения - это не мой деффект.
Владислав
Одну команду даже курирую сейчас.
Владислав
Ну так, к слову.
А
при сборке проекта через гит средствами типа TeamCity ваш .env вообще ни где не фигурирует соответственно на сервере он не появится
Владислав
при сборке проекта через гит средствами типа TeamCity ваш .env вообще ни где не фигурирует соответственно на сервере он не появится
Госпаде. Я для кого написал, что .env всегда на сервере?
Владислав
По волшебству.
Владислав
АвадаКедаврой, блэт
Владислав
Я тут ем, и мне выходить через 9 минут ) Вам что-то доказывать не буду, я устал. Я расписал вам уже достаточно.
Владислав
И плюсы в том числе.
А
не увидел ни одного плюса
Владислав
Тогда смотрите выше.
Владислав
Я их указывал.
Владислав
Ваше право.
.
Так успокоились 😄😄, теперь мне что надо делать ))))
Владислав
. https://scotch.io/tutorials/understanding-laravel-environment-variables#setting-production-environment-variables-in-forge
Владислав
Читаем и делаем выводы
А
вообще не убедил
Владислав
@andrew_a_v я скинул ссылку для . C вами я уже устал общаться по этому вопросу, написал же выше.
Ruslan
Если спорт о хранении паролей и ключей в гите, то так делать нельзя и остальные настройки касающиеся окружения тоже не хранятся в гите. Все это настраивается в своем окружении, локальном, деве, проде
Владислав
Именно об этом и был такой продолжительный спор. Это общепринятая практика, но её (даже заставляют) приходится объяснять. А когда объясняешь, называют бредом. ) Иногда проще забить.
Anton
Для чего это нужно?
Anton
Зачем фронту знать об этом. У тебя корень может быть локально один, на проде другой
Anton
Да. И что плохого?
Anton
За то всегда работает, как бы корневой путь не менялся относительно файловой системы
pa[aad
у меня была тоже такая проблема, просто вебпаком зарешал и tsconfig`ом
теперь делаю так import { some } from 'moduleName/blabla/some'
ko
Помогите плэс, если создаю второй и более проект то apartment из второго проекта появляется в первом, как сделать каждый проект отдельно с apartment???
public function projectShow($id){
$project = Project::find($id);
$floor = Project::with('Floors')->find($id);
$apartment = Floor::with('Apartments')->find($id);
return view('projectShow', compact('floor', 'apartment',
'project'));
}
Daniil
Daniil
Опиши структуру бд сначала
Евгений
у кого нибудь есть курс с ларакастс про разработку форума TDD?
Daniil
Потому что из кода непонятно
Daniil
А вот я хрен знает)) что он проектом считает, может быть это раскрашивание квартиры или этажа)
Ruslan
по коду та понятно что он хочет сделать
ko
ko
Здание -> этаж -> квартира
Ruslan
Помогите плэс, если создаю второй и более проект то apartment из второго проекта появляется в первом, как сделать каждый проект отдельно с apartment???
public function projectShow($id){
$project = Project::find($id);
$floor = Project::with('Floors')->find($id);
$apartment = Floor::with('Apartments')->find($id);
return view('projectShow', compact('floor', 'apartment',
'project'));
}
https://laravel.com/docs/5.6/eloquent-relationships
Daniil
Ну суть такая, если в project есть связь hasMany/belongsTo/etc то обратиться к кварьире можно $project->Apartment
Daniil
Через with ты всего лишь заранее подгружаешь чтобы не плодить лишние запросы позже
SarcasmIO
хотел бы я посмотреть на твой каноничный mvs на ларке)))
SarcasmIO
из коробки да