Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Auth::atempt() перебивает сессию новой авторизацией.
в принципе не страшно.
- берём старого auth::user() в переменную
если аттемпт успешный, то пихаем в массив суб-логинов.
если нет, то аттемптим сохранённую запись взад.
активной становится та авторизация, что успешна.
= и бага и фича.
Auth::validate() возвращает булеан, не удобно. могли бы вернуть пользователя или нул.
т.е. штатными средствами сделать можно, но будет не кошерно.
и обидно что общая авторизация уже завершена и менять её себе во вред ((
остался вопрос - как хранить суб-логины (объеты User)
сессии не импонируют...
идеи есть?
В догонку, как представляешь себе сторону БД ?
Ведь необходима таблица с данными вторичных авторизаций, относительно основной авторизации для восстановления данных сессии, если таковая по какой-то причине отсутствует.
Хранить user_id <=> user_id? как бы масло масленное.
Хех, проблема в том, что не ясно что с чем связать, если всё динамично двигается
(сессии в бд храню), да, думал связать с сессиями, но вдруг необходимо будет сессии в мемкеш выбросить... уже сложнее, а я не ищу сложных путей
А нет чтобы подумать свой головой, хочется сразу готового решения на блюдечке?
> А вот сам попробуй сделать вход, затем открой страницу логина, если получится...
Во-первых, страницу входа ты делаешь сам, и как сделаешь - так и откроется. Во-вторых, описанная мной схема отлично подходит под авторизацию в Laravel - первичный вход делается штатными средствами через Auth::attempt() и пр., таким образом ничего менять не нужно. Вторичный вход делается через твою собственную страницу, которая вместо или в дополнение к изменению Auth::user() изменяет переменную в сессии, где хранятся вторичные ID.> переключаться между авторизованными пользователями без передачи каких-либо данных типа логин/пароль.
Делается отдельная страница, которая принимает на вход ID вторичного пользователя, проверяет его наличие в переменной сессии и если он есть - делает ручной вход по ссылке в моём сообщении выше.> вот почему-то большинство не думает над проблемой, работают мозгом на уровне интерфейса, а не кода.
Скорее потому что кто-то не думает над проблемой вообще, и подсказки расценивает как доказательство своего превосходства.Рисуйте блок-схемы сами. Это форум программистов, а не доска взаимопомощи.
По порядку:
- Да, логично не изобретать велосипед. Если есть готовое решение, то любой здравомыслящий человек его будет использовать.
- То есть идея в том, чтобы (повторю) в 1й раз использовать штатный логин, затем использовать тот же Auth::attempt() с хранением результата работы в сессии (активные авторизации) и в БД, с коими и сверяться при переключении.
ОК. посоветуй пожалуста:
- что должно произойти, если я переключаюсь, если необходимо сублогин №842 сделать основным №1, а текущий (основной №1) сместить на вторичную позицию (положение не важно, просто сделать вторичным, впоследствии выбираемым)...
Мне не совсем всё понятно, что нужно сделать без последствий потери текущей сессии.
Опять Auth::attempt( №842 ) на позицию основного и повторить Auth::attempt( №1) на позицию вторичного ?
Я правильно понял идею ?
Не слетит ли сессия (пока обсуждаем теорию) или не произойдёт ли побочных проблем ?
В чём сложность? Все данные о вторичных входах хранятся в сессии (что это за данные зависит от задачи - можно просто список ID пользователей). Если надо читать оповещания всех пользователей - значит, в дополнение к Auth::user() страница должна перебирать вторичные логины в сессии. Переключение делается ручным входом, ((https://laravel.ru/docs/v4/security#%D1%80%D1%83%D1%87%D0%BD%D0%B0%D1%8F как тут)).
> При этом необходимо учесть безопасность аккаунта(ов)
Безопасность входа нескольких аккаунтов не отличается от безопасности одного - если безопасно хранить ID текущего пользователя в сессии, значит одинаково безопасно хранить и несколько таких ID.
По порядку.
1. А вот сам попробуй сделать вход, затем открой страницу логина, если получится...
1.1 Потом попробуй компилятором рест-запросов (плагин у браузера) протолкнуть пост в логин, а потом, когда успешно вошёл, второй раз.
1.2 Править код в /vendor желания нет, как бы
2. Сложность в том, что не представления, как
а) войти вторично
б) переключаться между авторизованными пользователями без передачи каких-либо данных типа логин/пароль.
вот почему-то большинство не думает над проблемой, работают мозгом на уровне интерфейса, а не кода.
повторно прошу давать осмысленные советы, где осмысленные означает обдумывать всю цепочку действий, рисовать блок-схемы хотя бы.
За ответ спасибо, но это не совет.
Есть нормально работающая авторизация/Регистрация + Вход через социалки. Тут всё отлично.
Необходимы действительно полезные советы, если нечего говорить, то и не стоит. Извините за прямоту.
Нужно сделать Multiple Authorization как у гугла/яндекса.
То есть, войди пользователем 1, добавить пользователя 2, 3, 4, .....
Чтобы впоследствии было возможным переключаться между ними в 1 клик.
Так же данные об этих (дополнительных, неактивных) пользователях должны быть доступны каким-либо образом, чтобы получать их уведомления либо другую инфу, не требующую создание контента.
При этом необходимо учесть безопасность аккаунта(ов), чтобы нельзя было перехватить логин/пароль (в плане хранения данных на стороне клиента, процесс передачи данных на каком-либо протоколе пока не волнует).
Есть какие-то мысли???
Все разобрался, все сделал
Ну вот, коли начал - договаривай.
Всем интересно 100500-е решение, глядишь ты и панацею сбацал )))
лучше Auth::user()->id
обращение к модельке кошернее, да и дёрнуть коллекцию/реляцию с неё можно, не создавая переменных "на один раз".
а что мешает сделать папки ru, eng и т.д., и там писать текст в виде констант/переменных? так же проще))) и при выборе языка просто бери текст из той папки, откуда нужно))) ИМХО
ничего не мешает.
вы видимо поторопились с выводами, - прочтите ещё раз "ТЗ" из первого поста.
если лень, то кратко, - цель определять и переключать, а не использовать, что является уже побочным действием определения и переключения локали.
а чего вы хотите от сырой версии?
пишите на форуме производителя - уверен исправят.
В компанию нужен разработчик
Основная деятельность frontend
Вторичная деятельность backend
Основняые требования:
1. Базово Laravel 4+ (Blade -шаблонизатор)
2. Bootstrap 3 | HTML5 | JS | CSS3
- Уметь писать jQuery плагины
- Знать, как сделать модальное, анимированное диалоговое окно с оверлеем только на css
3. Командная строка *NIX (у нас Debian) на уровне пользователя
4. Git / Mercurial
Вторичные требования (не обязательно):
1. Продвинуто Laravel 4 (у нас 5)
2. PostgreSQL - Писать хранимые процедуры / триггеры знать хотябы на уровне гугла
3. Командная строка *NIX (у нас Debian) на уровне системного администратора
Условия:
- Шаговая доступность от метро Динамо / Белорусская / Савёловская (не больше 10-15 минут пешком)
- График: 40 часов в неделю, гибко, но 100% между 12 и 18 надо быть.
- Офисное здание, есть столовая; чай, кофе, пряники
- ЗП белая.
Контакты:
- Резюме, пожалуйста, присылайте на re.factory@yandex.ru
ПС: Вакансия актуальна примерно неделю, завтра (24 фев) будет опубликована на хантере - спешите.
Привет!
Решил накатать статейку с кодом, как прикрутил локализации к L5.
ТЗ:
1) Адреса вида site.com/en/any-segment?any=argument определяют локализацию
2) Адрес без указания локализации уводит на ссылку с указанием локали, это СЕО-затычка, чтобы небыло двух одинаковых страниц по разным языкам.
3) Смена длкали через ссылку site.com/jp/set-language (language вместо locale понятней обывателю)
Побочный (не сильно приятный) эффект:
Все ссылки приходится генерить в шаблонах и в коде рукаами вида Request::secure( '/'.$locale )
(Возможно когда-нить поправлю код ядра, либо напишу какой-нить враппер, но я ленивый )
Реализация:
1. Установить пакет
"mcamara/laravel-localization": "1.0.*",
2. Исправить существующие файлы:
Публикуем конфиг нового пакета
/config/laravellocalization.php
Исправляем конфиг таким обазом (раскомментировать), чтобы включить язык 'en' и 'ru'
Отключаем:
'useAcceptLanguageHeader' => false, // мы используем наше значение конфига /config/app.php: locale=>en)
'useSessionLocale' => false, // мы берём локаль из адреса
'useCookieLocale' => false, // - отключаем чтобы не перебивало, когда меняем локаль (пояснение в конце)
/config/app.php
'locale' => 'en'
/app/Http/routes.php
Route::group(
[
'prefix' => LaravelLocalization::setLocale(),
'middleware' => 'setlanguage'
],
function()
{
// HomeController
Route::get( 'home', [ 'as' => 'home', 'uses' => 'HomeController@getIndex' ] );
Route::get( '/', [ 'as' => 'home', 'uses' => 'HomeController@getIndex' ] );
Route::get( 'about', [ 'as' => 'about', 'uses' => 'HomeController@getAbout' ] );
// SettingsController
Route::get( 'set-language', [ 'as' => 'set-language', 'uses' => 'SettingsController@setLocale' ] );
// AuthController
Route::controllers([
'auth' => 'Auth\AuthController',
'password' => 'Auth\PasswordController',
]);
}
);
/app/Http/Kernel.php
protected $routeMiddleware = [
// существующий код...
// лосле локализаций переопределяем локаль
'setlanguage' => 'App\Http\Middleware\SetLanguage',
3. Добавить новые файлы
/app/Http/Middleware/SetLanguage.php
<?php namespace App\Http\Middleware;
use Closure;
use Auth;
use LaravelLocalization;
use Config;
use Redirect;
class SetLanguage
{
public function handle($request, Closure $next)
{
$addrLocale = $request->segment(1);
$locales = LaravelLocalization::getSupportedLocales();
$locales = array_keys( $locales );
$defaultLocale = Config::get('app.locale');
if ( !Auth::guest() )
{
// ставим локаль из настроек пользователя, если она разрешена
$userLocale = Auth::user()->locale;
if ( in_array( $userLocale, $locales ) )
{
LaravelLocalization::setLocale($userLocale);
}
}
else
{
// ставим локаль из адреса, если она разрешена
if ( in_array( $addrLocale, $locales ) )
{
LaravelLocalization::setLocale($addrLocale);
}
else
{
// иначе отправляем на адрес с локалью по умолчанию
return Redirect::secure( '/'.$defaultLocale );
}
}
return $next($request);
}
}
/app/Http/Controllers/SettingsController.php
<?php namespace App\Http\Controllers;
use View;
use Request;
use Config;
use Auth;
use Redirect;
use LaravelLocalization;
use URL;
class SettingsController extends Controller
{
public function __construct()
{
// во всех конструкторах необходимо кинуть локаль и список поддерживаемых локалей в шаблонизатор, чтобы реализовать переключатель языка. Для примера бросил здесь, но лучше где-нить в Controller::constructor'е
View::share( 'locale', Lang::getLocale() );
View::share( 'locales', LaravelLocalization::getSupportedLocales() );
}
public function setLocale()
{
$addrLOCALE = Request::segment(1);
$cfgLOCALE = Config::get('app.locale');
$segments = Request::segments();
$locales = LaravelLocalization::getSupportedLocales();
$locales = array_keys( $locales );
$setLocale = null;
if ( in_array( $addrLOCALE, $locales ) )
{
// локаль в адресе действительна
// ставим её
$setLocale = $addrLOCALE;
}
else
{
// локаль в адресе НЕ действительна
// ставим дефолтную
$setLocale = $cfgLOCALE;
}
if ( Auth::check() )
{
// пользователь авторизован
// сохраняем в пользователя
$user = Auth::getUser();
$user->locale = $setLocale;
$user->save();
}
// ставим локаль в адрес
if ( !empty( $segments ) && $segments[1] == 'set-language' )
{
// ПОПЫТКА (!) уйти туда же откуда и пришли, заменив язык в адресе
// TODO: не совсем уместно, но на уровне REST'a проблем возникнуть не должно
$lc = implode('|',$locales);
$back = URL::previous();
$back = preg_replace( "#/([".$lc."].)#iu", "/{$setLocale}", $back );
return Redirect::secure( $back );
}
else
{
// простой переход на главную страницу
return Redirect::secure( '/'.$setLocale );
}
}
}
/resources/lang/en/*
остаётся как есть
/resources/lang/ru/*
копируем 'en' и переводим руками
========================
Шаблон переключателя локали
@if(!empty( $locales ))
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" aria-expanded="false">
<i class="fa fa-cog"></i>
{{trans('nav.sitelanguage')}}
</a>
<ul class="dropdown-menu" role="menu">
@foreach($locales AS $lc=>$ln)
<li class="@if($locale==$lc) active @endif">
<a href="/{{$lc}}/set-language">
<i class="fa @if($locale==$lc) fa-check-square-o @else fa-square-o @endif"></i>
<span class="">{{$ln['native']}}</span>
</a>
</li>
@endforeach
</ul>
</li>
@endif
При этом если установите css-спрайт с флагами, то сможете заменить голову меню на [Флаг] [Имя Языка] чтобы было красиво
Как-то так...
Пробуйте !
ПС:
1) если включить определение хедеров браузера - можно отказаться от определения дефолтного языка, однако потеряете возможность менять язык -- оно перебивает конфиг (во всяком случае у меня)
2) по такому же принципу можно менять шкурки, но значения хранить например в куках
Отвечу на вопросы, приму достойную и добрую критику.
hzone пишет:я уже занимаюсь на работе этим вопросом.
там походу жёстко прописан текст в классах.
жопа, но поправимо.Нет ты не прав, если глобально в config/app.php сменить на ru он начинает цеплять русские коды!
1) для того, чтобы заработало предложенное тобой, нужны УЖЕ локализованные файлы
2) вопрос был в том, чтобы найти где лежат эти сообщения, которые цепляет система
И лежат эти сообщения в /resources/lang/XX/validation.php
Естессно надо свою локализацию класть в resources/lang/ХХ
я уже занимаюсь на работе этим вопросом.
там походу жёстко прописан текст в классах.
жопа, но поправимо.
отбой. заработался )))
он ж сам его хеширует )))
да. Hash генерит по другому алгоритму...
Sentry 2 - https://cartalyst.com/manual/sentry/2.1
В примерах нет кода для смены пароля.
Есть подозрения, что надо использовать $user->password = Hash::make(Input::get('password'));
Но есть неуверенность...
Может кто-то решал эту тему ?