Спасибо большое за ваш ответ! Да, проект небольшой, но хочется на его примере разобраться со всеми этими вещами, обучение - одна из целей. А можно подробнее насчет контейнеров, nginx, php-fpm, redis, psql - это всё отдельные контейнеры, которые связываются между собой docker-compose? А в каком из них лежит сам исходный код laravel-приложения?
JhaoDa, структура проекта, возможно, набор используемых модулей. И было бы довольно странно задавать вопрос "как использовать docker с любым фреймворком".
Я перечитал разные статьи, где авторы используют микрофреймворк flask, так там достаточно скачать один контейнер и все готово.
Спасибо за ответ, я знал, что ответите именно вы :)
Не обязательно "процесс, который будет запущен всегда". Цель - раз в несколько секунд опрашивать сторонний API и обновлять у себя соответствующие данные.
Планировщик - Task Scheduler (он же вроде бы не позволяет чаще, чем раз в минуту выполнять задачу)?
Слушатель очереди - Queue Worker, которого в документации рекомендуют запускать через supervisor?
То есть так и задумано, что я вручную, руками, ввожу входные данные и ожидаемые выходные?
А что значит покрытие строк, ведь модульный тест покрывает конкретный метод, т.е. насколько я понимаю, 1 unit test = 1 метод. Я же не могу покрыть одну строку своего кода..
Антон Алексеевич, спасибо за ваш ответ.
Лучше просто забыть, что я задавал этот вопрос... Ещё и попал в топ-3 интересных, LOL
Сейчас потестил в разных браузерах, работает всё идеально, без всяких настроек. Но я вообще не понимаю, почему это работает: следил за изменением remember_token в базе данных, он меняется при каждом logout. Я зашел в аккаунт с 2 браузеров, потом в одном вышел, токен в базе поменялся, но сайт продолжал помнить второй браузер, как и должно быть (хотя токен поменялся)...
Mikhail Osher, Пришла хорошая идея. Можно же сделать полностью корректную реализацию Authenticatable, просто внутри методов, которые работают с remember_token`ом, добавить логику для определения к какому устройству относится remember_token (id устройства можно хранить в cookie). Тогда даже не нужно писать свой Guard, судя по всему. Я же правильно мыслю?
Mikhail Osher, ну да, логично, он же с Guard`ом связан. Свой Provider вроде не проблема сделать - это ведь задаётся в конфиге, как и Guard. Это все места, где используется Authenticatable?
Mikhail Osher, И вообще, зачем нужен интерфейс Authenticatable? Можно как-то узнать, где он используется? Если только для Guard`ов, то сделав свой Guard можно вообще не париться с реализацией этого интерфейса.
Mikhail Osher, А как быть с контрактом Authenticatable? В нём все методы рассчитаны на то, что remember_token один. Или его не обязательно реализовывать?
JhaoDa, спасибо за совет, но я, очевидно, сделал это не раз. Причем не только оригинал, но и различные переводы. Пошарил в коде фреймворка, судя по всему, эта фукнция определяется в нашем request-классе. А вот зачем же она всё таки нужна, не совсем понятно.
JhaoDa, простите, что надоедаю, но хочу задать последний вопрос.
Не могли бы вы привести пример конфликта мелких разрешений, чтобы я понимал, чего опасаться?
И, главное: почему же все таки лучше хранить информацию о подробностях разрешений отдельно, чем делать мелкие — я не вижу отличий между этими подходами... Т. е. почему конфликтов не будет в случае хранения информации о подробностях отдельно?
JhaoDa, Благодарю за ответ.
Разумеется, открывал и читал. Понятно, что методы политики могут проверять что угодно и содержать любую логику.
Допустим у меня будет дополнительная таблица permissions_data, которая будет содержать подробности каждого разрешения для каждой роли. Вопрос в том, чем это лучше кучи мелких разрешений, какие могут быть конфликты у мелких разрешений?
JhaoDa, Да, я тоже не хотел дробить разрешения... Хорошо, вот в методе политики я узнал, что пользователь может в принципе вызывать messages.delete. Откуда политике узнать "подробности разрешения" - что пользователь может удалять любые сообщения в определенных чатах, если это не указано в самом разрешении?
Большое спасибо за ответ!
Да, этот некто должен иметь возможность насоздавать типов пользователей (администраторов, техподдержку, модераторов, ...), а потом "натыкать" галочек-разрешений для каждого из них, в этом главная задумка. Значит для такого случая RBAC подходит лучше всего?
Для случаев вида "модератор может редактировать как свои, так и чужие сообщения" разумно просто создать несколько разрешений: messages.edit:basic (разрешение на редактирование своих сообщений), messages.edit:all (редактирование любых сообщений) ?
Но как быть в этом случае: "модератор может удалять сообщения не во всех беседах, а только в заранее выбранных администратором"? Тут уже не пойдет создать несколько разрешений... Да, у меня будет нечто похожее на политики в Laravel - если я правильно понимаю, это классы, в которых куча булевых методов, определяющих, можно ли выполнить действие Y. В этих методах я и должен проверять, например, то, что модератор хочет удалить сообщение в чате из разрешенного списка? Тогда у меня будет разрешение messages.delete:all_in_allowed_chats(право удалять любые сообщения в разрешенных чатах) и будет где-то хранится список разрешенных чатов для этого пользователя.