Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Имею следующую схему данных
-Users. Таблица с данными пользователей
-Journals. Таблица со списком журналов.
-Entries. Таблица со списком записей в журналах.
-journal_user. Журнал могут вести разные пользователи. Таблица описывает права. Только те пользователи, которым указаны в этой таблице для определённого журнала, могут его вести.
Связь от Users к Entries. Каждая запись в журнале принадлежит определённому пользователю.
Есть Journal, который могут заполнять Entries определённые Users. Каждая Entry принадлежит определённому User. И только пользователь, который сделал эту Entry может её редактировать. Имеется необходимость в следующих ограничениях:
Для определённого Journal только определённые Users могут оставлять Entries. Остальные Users не должны иметь никаких прав на работу с Journals и Entries.
Только тот User, который оставил Entry (при условии, что он всё ещё имеет права на работу с журналом, т.е. присутствует в таблице journal_user) может редактировать её. Остальные доверенные пользователи (из таблицы journal_user для текущего Journal) могут только читать.
Я не знаю, как подступиться к описанным выше требованиям к ограничениям. Самое удобное - сделать ограничение подобное на стороне middleware, который бы использовался в качестве middleware для группы роутов в web.php. И если с пользователем понятно (я могу получить его данные через Auth::user()), то как быть с Journal?
Route::get('journals/{journal}', 'JournalController@show')->name('journals.show');
Нужно проверить, что пользователь может открыть этот журнал. Значит на стороне middleware нужно как-то получить переданный параметр роута {journal}. Как это можно сделать?
Насчёт возможности редактирования только своей записи я вроде бы понимаю - реализовать можно через Request и валидацию (есть там метод auth). Но как быть с выше описанным? Это можно сделать как-то иначе? Да, я могу в каждом методе контроллеров проверять, но это же не правильно, да?
artoodetoo, немного подумал, почитал, разобрался. Да, нужно считаться с индексированием. Думаю делать url адрес с указанием точки сбыта в виде дополнительно параметра `r`
test.com?r=14
test.com/catalog?r=14
test.com/ru/catalog/category?r=14
Но куда выносить логику первоначального перевода на какой-то конкретный рынок сбыта, смену его и другое? В middleware можно определять рынок сбыта при первом посещении. А логику управления переносить в отдельный контроллер? Или как?
artoodetoo, я, кажется, начал понимать. Но мне нужно время, чтобы всё это переварить и изучить спокойно. Обязательно отвечу немного позже! Спасибо!
artoodetoo, но как маршруты связаны вообще с тем, что я хочу сделать? Я попробую ещё раз объяснить.
У меня есть хедер (отдельный вид в отдельном файле header.blade.php). Хедер подключается абсолютно ко всем страницам сайта вне зависимости от роута. В хедере я хочу выводить переключатель страны, например. При посещении сайта страна устанавливается автоматически. Дальше пользователь может её изменить. Т.е. по факту при первом посещении где-то (где?) нужно присвоить значение по-умолчанию или считать из кеша уже установленное, если посещение не первое, и вывести в хедере.
artoodetoo, совсем не понял, как это применить. Быть может я запутано объяснил, что я пытаюсь понять?
Экспериментирую с созданием сайта-магазина на laravel 5.7. Пытаюсь реализовать функционал точек сбыта - отдельных магазинов, регионов, стран и т.п., которым присущи свои отдельные товары и цены.
Переключатель в хедере. При посещении сайта автоматически устанавливается значение по-умолчанию (потом быть может будет определяться по положению).
Проблема в том, что я не могу решить, как это сделать. Пользователь заходит на сайт и... и что? Где должна описываться логика? Вид (хедер) - общий для всех страниц. Там нужно отобрать выбранный рынок сбыта. А значит, нужно это где-то хранить. И код должен отработать сразу же при открытии сайта. Т.е. это что-то глобальное с доступом к кешу. С помощью чего это лучше всего сделать и как?
Laravel 5.7.17
php 7.3.2
чтобы данные "отдать" в нужном виде придумали Ресурсы - https://laravel.com/docs/5.6/eloquent-resources. В контроллере вы просто получаете данные. И отдаёте Ресурсу.
И вы так и не ответили на мой вопрос касательно связи между таблицами. Таблица промежуточная должна называться наоборот - direction_execute (по алфавиту). Тогда достаточно создать только две модели и очистить их от мусора
class Direction extends Model
{
protected $fillable = ['id_user', 'name'];
public function executes()
{
return $this->belongsToMany('Growth\Execute');
}
}
class Executer extends Model
{
public function directions()
{
return $this->belongsToMany('Growth\Direction');
}
}
Теперь можно как-то так. И отдать Ресурсу.
$directions = Direction::with('executes')->where('id_user', Auth::user()->id)->get();
Так. Давайте разберёмся ещё раз.
Есть таблица direction (тренинги) и таблица execute (исполнители). И таблица многие ко многим direction_execute, где описываются связи - на каких тренингах какие исполнители, какие исполнители на каких тренингах.
Верно? Хорошо. А теперь скажите, что вы хотите получить?
Это первое видео серии. Хорошие курсы по laravel. Первые 2 видео можно пропустить.
return $directions->executes; (если связь так вызывается)
npm run dev в консоли (если последняя версия laravel). Вам нужно все свои компоненты и т.п. "скомпилировать" в js. А потом подключить его на странице.
У меня, например есть файл webpack.mix.js, где указано что куда "компилировать"
mix
.js('resources/assets/js/app.js', 'public/js')
.sass('resources/assets/sass/app.scss', 'public/css');
А в моделях связи между таблицами вы прописали?
Пытаюсь разобраться с oauth. Что сделано:
- установлен Passport и auth
- запущены миграции и т.п. В итоге всё завелось, но не ясна логика работы. Где не смотрел - слишком много слов и абстракции.
Как я должен теперь работать?
1) Создать контроллер, где проверять логин и пароль пользователя и возвращать данные из таблицы oauth_clients
public function login(Request $request)
{
if (Auth::once(['email' => $request->input('email'), 'password' => $request->input('password')])) {
return Auth::user()->oauth;
}
return response('Not auth', 401);
}
2) В ответ получаю в том числе и secret приложения, завязанного на конкретного пользователя в таблице users
3) Дальше я шлю второй запрос по адресу http://db7/oauth/token с целью получить access_token и refresh_token. Отправляю вновь логин, пароль, но дополнительно ещё и client_id, client_secret и др (т.е. часть данных, полученных при первом запросе)
4) С каждым запросом далее отправляю access_token.
Всё вроде бы работает. Но при каждом запросе http://db7/oauth/token токен генерируется каждый раз новый. Т.е. сколько раз залогинились, столько раз и создаётся токен. Это правильно? Или же нужно первым запросом проверять - если логин и пароль верный и есть действующий access_token, то верни его. Если нет, то там же создай новый. Или как?
Помогите, пожалуйста. Как всё это правильно должно работать???
Страницы 1