Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
(2) то что отдельный роут и контроллер это понятно.
А выдавать токен - по логину и паролю, передаваемым в заголовках?
Ну типа get метод, например getToken(), который проверяет логин пароль и возвращает сгенерированный токен.
Получаем токен, и передаем его в последующих запросах к API.
Я правильно понимаю?
Тогда чем "подсмотреть логин пароль" отличается от "подсмотреть API_KEY", не совсем понимаю.
Для каких целей вообще токен, если можно в заголовках передавать логин пароль и проверять его?
Да, пользователь предполагается один - "служебный" - для того чтобы внешняя система могла обмениваться с API
Задача - нужно дать возможность извне подгружать некие справочные данные в БД.
Как правильно это сделать с точки зрения безопасности?
Пока такие мысли
1. Создать env константу например вида API_KEY = "12342fasdrf12342134sdfasdfq2341234asdfasdf1234"
2. Создаем Route::post('api/myMethod', 'MyApiController@myMethod')
3. Здесь добавляем этот url 'api/myMethod'
class VerifyCsrfToken extends BaseVerifier
{
/**
* The URIs that should be excluded from CSRF verification.
*
* @var array
*/
protected $except = [
//url запросов, для которых не нужно проверять CSRF токен
];
}
4. В самом 'api/myMethod' смотрим, если передаваемый API_KEY не совпадает, то отбреваем. Если совпадает, делаем что нужно.
Как этот вариант с т.зрения безопасности? Это штатное создание "внешнего" API?
city_time_zone, region_time_zone - это просто сдвиг в часах (или минутах) относительно UTC?
С этим то понятно.
А все таки, применительно к текущему заказу - хранить в двух полях локальную дату, время - в этом нет никаких граблей?
Доброго дня.
Есть следующая задача:
Территориально разбросанные склады. Каждый в своем часовом поясе.
Пользователь будет указывать дату и время "записи" на услугу хранения. Ну например хочу привезти товар завтра, в 12.00.
Т.е. бронировать "окна". Локация и часовой пояс при бронировании известны.
Как правильно это организовать с типами данных и хранить?
Варианты были следующие:
1. поле типа datetime. Хранить по UTC. Тогда вроде схема единая, но очень много преобразований. Особенно с учетом, если заказывает в Уфе услугу на Красноярск. Локальное время Уфы, нужно через Красноярск преобразовать в UTC, затем сохранить в БД. При отображении смотрим время UTC, преобразовываем к Красноярску. Очень кудряво
2. два поля типа date, time. Храним локальную дату (Красноярска) и локальное время (Красноярска). Плюсы в том, что данные относятся четко к локации и при отображении ничего преобразовывать не нужно. Минусы наверное есть (пока не знаю какие)
3. Поле типа datetimeTz - насколько я понял, это тот же datetime, в котором есть инфа о часовом поясе. Попробовал создать, но в pma отличий от datetime не увидел. М.б. с ним как то по особому работать нужно?
4. два поля типа dateTz timeTz, ситуация аналогично п.3.
Наведите на путь истинный. Наверняка есть "обычная практика" в этом деле.
Почему? Как тогда правильно организовать чтение порциями?
Ну типа вот здесь только https://laravel.com/api/5.7/Illuminate/ … nator.html
Мозг можно сломать 
В документации хорошо на примерах расписаны базовые вещи. И это круто для начала погружения.
Но как копнешь глубже - понимаешь, что совсем не понимаешь объектную модель.
Где и как развидеть это все?
Вот понадобилась своя пагинация (без обновления страницы через vue и вызов http get)
Все круто, только непонятно как руками установить текущую страницу.
Приходится кучу времени тратить чтобы загуглить. Оказывается это "просто"
Paginator::currentPageResolver(function () use ($currentPage) {
return $currentPage;
});
Идем в официальную документацию https://laravel.com/docs/5.7/pagination, ищем currentPageResolver - ничего не находим!
Как легко и быстро понимать возможности отдельных объектов? Где подробное описание всего api?
Спасибо, дружище!
Теперь понимаю, насколько глупый вопрос, мне можно я только учусь.
Конечно, этож так очевидно... поставил на хостинге composer, установил пакеты, все взлетело.
Перефразирую вопрос.
Зачем vendor по-умолчанию в gitignore
И чем грозит, если убрать его оттуда
В общем посмотрел, что не едет по-умолчанию.
public, storage - с этим все понятно, тут у нас картинки и прочее.
vendor - исключен в корневом gitignore полностью.
Ну тут видимо объяснение в том, что эти файлы от вендора, типа не изменяемы (обычно).
Как тогда правильно поступать?
- Клонировать репозиторий на хостинге
- подлить руками vendor, public, storage
- помнить всегда про их изменение и подливать вручную если эти изменения есть?
Собственно, проект на laravel содержит кучу gitignore файлов.
Поэтому когда на хостинге делаем pull проекта из репозитория, приезжает далеко не все необходимое для работы сайта.
Среди gitignore есть как полезные файлы, так и всякие файлы кэша.
Как правильно настроить обмен через git?
Может просто удалить все gitignore, оставить только в корне, который исключает .env файл?
Или это будет неправильным?
Круто.
Сделал вот так, совсем просто получилось.
if ($user_org!==null){
return redirect()->back()->withErrors(['name' => 'У Вас в списке уже есть организация с таким ИНН, КПП'])->withInput();
}
Только кажется, что проверять предварительно через обращение к модели - немного костыльно
$user_org = UserOrganizations::select()->where('user_id', Auth::id())->where('organization_id', $org->id)->first();
Может есть способ в UserOrganizations (или еще где) реализовать валидацию на составной индекс, а затем внутри метода store (OrganizationController) использовать этот валидатор?
Есть пользователи (User), которые могут создавать организации (Organizatoin) - поля name, inn, kpp.
Для формы и записи есть два маршрута
Route::get('pa/organization/add', 'OrganizationController@add')->name('organization-add');
Route::post('pa/organization/add', 'OrganizationController@store')->name('organization-store');
Внутри метода store - простенький валидатор
$validator = $this->validate($request,[
'inn' => 'required|min:10|max:12',
'kpp' => 'max:9',
'name' => 'required|min:5'
]);
После которого - создание сущности Organizatoin (также проверяется, нет ли уже такой организации по inn+kpp).
Теперь задача - привязать организации к пользователю, который ее создает.
Добавил таблицу UserOrganizations (id, id_user, id_organization), а также составной индекс id_user + id_organization
Перед записью проверяем наличие такой записи
$user_org = UserOrganizations::select()->where('user_id', Auth::id())->where('organization_id', $org->id)->first();
if ($user_org!==null){
//уже есть
}
При этом нужно добавить ошибку в стандартный массив errors и сделать redirect, чтобы на предыдущей странице выдать ошибку "К вам уже привязана эта организация" (через @errors)
Как это сделать? Создавать UserOrganizationController и там создавать свою валидацию, или можно как то попроще через стандартный validate? Или вообще не через validate можно добавить произвольный error?
Здесь синтаксис @extends такой же точно также как в @include@extends('master', ['title' => $title])после чего переменная $title будет определена в master.blade.php
Точно ведь! Причем так думал изначально и казалось что проверил этот вариант.
Спасибо.
А что за index? Мне переопределить надо стандартный маршрут.
Пока сделал так
public function callAction($method, $parameters) {
if($method == 'showRegistrationForm'){
return view('auth/register')->with([
'title'=>'Заголовок',
'description'=>'Описание'
]);
}
else{
Controller::callAction($method, $parameters);
return redirect('/');
}
}Но кажется очень кудряво... думаю, должны быть какие-то параметры класса, чтобы не переопределять методы.
Похоже разобрался... Нужно в классе прописать свой вызов
public function callAction($method, $parameters)
{
return view('auth/register')->with([
'title'=>'Заголовок',
'description'=>'Описание']);
}Есть стандартный контроллер RegisterController.
Есть шаблон для него register.blade.
Шаблон расширяется @extends('main'), внутри которого есть переменные, например {{$title}}
Каким образом в контроллере установить эту переменную?
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)