Pull to refresh

Comments 23

Более подробная установка MODX Revo, вернее, сервер под MODX Revo описана в этой статье.

Мультисайтовость здесь описано, в кратко говоря:
<?php /* don't execute if in the Manager */ if ($modx->context->get('key') == 'mgr') { return; } switch ($modx->getOption('http_host')) { case 'domain2.tld:80': case 'domain2.tld': // if the http_host is of a specific domain, switch the context $modx->switchContext('domain2.tld'); break; default: // by default, don't do anything break; } ?>
Тоже вещать на OnHandleRequest, тут код более понятен и не нужно лишние параметры создавать.
Лишнее написали, в общем-то.

А вот ЧПУ (правда, пример бы привели, как будет) и авторизация на всех контекстах для новичков — спасибо.
За код извиняюсь.
<?php
/* don't execute if in the Manager */
if ($modx->context->get('key') == 'mgr') {
    return;
}
 
switch ($modx->getOption('http_host')) {
    case 'domain2.tld:80':
    case 'domain2.tld':
        // if the http_host is of a specific domain, switch the context
        $modx->switchContext('domain2.tld');
        break;
    default:
        // by default, don't do anything
        break;
}
?>
Это вариант 2.1, который я описывал.
Цитирую:
жёстко задаётся список доменов, которые обрабатываются жёстко заданным списком контекстов..

Насчёт примера по ЧПУ — получается примерно так:
example.com/myresource.html/param1-value1/param2-value2/param3-value3/
жёстко задаётся список доменов, которые обрабатываются жёстко заданным списком контекстов..

С плагином, который я взял с rtfm всё также. Контексты показываются только у своего домена, если домен не указан — то показывается контекст web.
Ну так я про то и говорю. Мой вариант более гибкий — он соответствует варианту 2.2, который я и описывал. Тогда как ваш (взятый с rtfm) — соовтетствует варианту 2.1.
Люди, которые минусуют статью! Просьба сказать, что именно вам в ней не понравилось!
Я не минусовал, да и не хочется, но статья на самом деле странная.
Вы начали в общих чертах описывать систему, потом перешли к ЧПУ, а закончили плагином. Не увидел стройности мысли.
Это некие «заметки на полях» о разных аспектах MODX. По тем вещам, которые заставили меня порыться в гугле, документации, на форуме и в исходниках.
Наверно тогда лучше было бы разнести по разным постам материал, например: «Моя настройка nginx для MODx», «Модернизация ЧПУ для МОДх».
Честно говоря, не очень люблю плодить кучу постов. :)
Опять какие то странные изобретения. Расписывать долго, остановлюсь на авторизации.

Логин:
$data = array(
	'username' => $username,
	'password' => $password,
	'rememberme' => 1
	'login_context' => 'web'
	'add_contexts' => 'en,ua,fr'
);

$response = $modx->runProcessor('/security/login', $data);
if ($response->isError()) {
	$modx->log(modX::LOG_LEVEL_ERROR, 'login error. Username: '.$username.' Message: '.$response->getMessage());
}


Логаут:
$response = $modx->runProcessor('/security/logout');
if ($response->isError()) {
	$modx->log(modX::LOG_LEVEL_ERROR, 'logout error. Username: '.$modx->user->get('username').', uid: '.$modx->user->get('id').'. Message: '.$response->getMessage());
}

Подробнее покопаться можно тут. Так же сделан вход\выход и в сниппете Login. Еще, на будущее — мои заметки про использование процессоров: раз и два.

Я понимаю, что вам нравится система и вы спешите поделиться своей радостью. Но вы же учите плохому.
В MODX Revolution отличное API и система процессоров, которые позволяют делать очень многое просто и красиво.

Мой вам совет — поучитесь еще, прежде чем писать такие рецепты.

P.S. плюсую все равно, ибо в хабе MODX очень тихо.
В том-то и вся гибкость моего решения, что не нужно забивать названия контекстов прямо в сниппете, как здесь у вас.
Строчка 'add_contexts' => 'en,ua,fr' не требуется в данном случае — всё делается через плагин.
А за ссылки по процессорам спасибо — очень интересно.
Что мешает добавить имена контекстов в массив перед авторизацией? И не быстрее ли, один раз их руками написать, чем при каждом входе лазить в базу? У вас новые контексты каждый день создаются и надо во все логиниться?


И неужели вы не поняли, что я вам говорю про использование системного процессора для входа и выхода, вместо вашего ручного формирования сессии?

Что вы будете делать со своими велосипедами в MODX 2.2,4 или в MODX 2.3? Там сессия может и поменяться, а процессоры будут работать как ни в чем не бывало.
MODX 2.2.5, конечно же, ил ив любой другой будущей версии.
То, что я хочу хранить это именно в настройках контекстов, а не где-то ещё. И использовать не только для авторизации, а например и при создании пользователей — да мало ли ещё где!
Или вы предлагаете в том же моём плагине вместо addSessionContext вызывать процессор? А не будет ли больше оверхеда в таком случае? Фактически для других контекстов придётся заново пройти всю процедуру авторизации.
И я не хочу везде вставлять кучу кода для поддержки загрузки нужного списка контекстов из кучи сниппетов. Хочется вставить только один кусок кода — в данном случае сниппет — и чтобы оно автоматом подхватилось везде где только можно. Мой вариант это позволяет. Тем более, что addSessionContext вполне себе документированная функция API.
Я предлагаю использоваться для логина, логаута, работы с юзерами, ресурсами и прочих системных действий системные же процессоры.

Откуда вы их вызываете: плагина ли, сниппета, консольного скрипта — не важно. Важно то, что они все сделают правильно. Проверят права доступа, системные настройки, вызовут плагины и прочее.

Очень советую посмотреть в код процессоров, и вы увидите, что они делают.
Сейчас вы изобретаете собстенный велосипед, с квадратными колесами. Да и на здоровье!

Но не надо этому учить новичков. Вы только отпугнете юзеров от MODX, который и так считают сильно сложным.

Пожалуйста, набросайте простенькую реализацию плагина с использованием процессоров, если не очень сложно. А то я лично вижу тут две фундаментальные проблемы:
1. Плагин OnWebLogin будет вызываться каждый раз, когда я буду вызывать процессор, надо как-то запретить это наверное?
2. У плагина OnWebLogin нет информации о пароле польователя. Можно, конечно, вместо этого использовать событие OnWebAuthentication, куда передаются данные в том числе о введённом пароле, но… Зачем заставлять заново проверять уже один раз проверенный пароль для каждого контекста?
Вы не понимаете суть. Это процессор security/login вызывает событие OnWebLogin (исходник).

Сейчас у вас:
1. Авторизация через Login
2. Login запускает процессор security/login, тот вызывает OnWebLogin
3. Срабатывает ваш плагин и вы добавляете нужные контексты юзеру

Замечу еще, что у сниппета Login, есть настройка, котрая позволяет юзера сразу авторизовать в разные контексты.

В вашем случае нужно или вызвать верно Login, или просто выкинуть его и самому всех авторизовать.
1. Юзер шлет куда-то логин\пароль.
2. Ваш сниппет ловит их и передает процессору. В зависимости от ответа — вход или ошибка.

Плагин ваш — просто лишняя нагрузка.
Я знаю, что процессор вызывает OnWebLogin, в этом-то и проблема.
Ещё раз повторяю — я НЕ ХОЧУ править все сниппеты чтобы туда по необходимости включать те или иные контексты. Более того, я не хочу даже увеличивать текст тега для сниппета Login — я хочу, чтобы вся обработка всех лог инов и лог аутов происходила в одном единственном месте — в данном случае в моём плагине, а настройки на эту тему хранились в другом месте — где им и положено, в настройках контекстов. Фактически, я хочу чтобы с моим кодом автоматически оказался совместим фактически ЛЮБОЙ сниппет БЕЗ его изменения, будь то Login, чей-то самопальный, Loginza или ещё чего.
Не надо сарказма. Или вы хотите сказать, что мой способ не позволяет этого сделать?
Sign up to leave a comment.

Articles