Всего 125 681 комментарий

Павел Бигель
11 апреля 2021, 21:46
+2
Вот вроде и минус ставить не хочется (человек старался + олд + по содержательности явно лучше многих статей тут), но и лайк ставить не за что.
Практического смысла и применения в этом околонулевая
Іван Клімчук
11 апреля 2021, 20:47
0
Я уже отписал в PR, чтобы это была часть рефакторинга, переезд на PSR-4, следовательно имена классов теперь «правильные», с учетом регистра, поэтому и пути к actions теперь с учетом регистра. Это правили, но видимо не везде нашлось.
Іван Клімчук
11 апреля 2021, 20:44
+7
Бля, а интеграторам потом сиди и ломай голову, нахрена оно там нужно? 2 строки пояснения написать — жопа не отвалится, ну серьезно. Нам больше делать нечего, как сидеть и гадать на картах Таро, что там автор имел ввиду. Мы не за зарплату там сидим, есть дела и поважнее. Ты ж вроде говоришь, что активно в open source серьезном участвуешь, так там считается правилом хорошего тона описать твое изменение и зачем оно нужно, иначе просто закрывают PR, как формально не соответствующий правилам. Не только твое время дорого стоит. Никто ж не требует простыни писать, для ленивых даже сделали удобный шаблон, чтобы максимально не думать о структуре, а просто написать 2 ответа и все.
Fi1osof
Fi1osof
11 апреля 2021, 19:13
+1
К слову, еще одна причина почему не хочется заниматься кодингом в ядро: я отправил ПР, но видите ли не достаточно хорошо его оформил (точнее совсем не оформил). Почему я должен на это тратить время? Это не issue, где бы я спрашивал «А как мне сделать то-то». Это PR. То есть я потратил не мало своего времени, нашел проблему, пофиксил ее, и еще должен что-то там разжевывать? А мейнтейнеры на что? Это уже не программисты, а менеджеры какие-то. Как будто все это должно мне быть важнее, чем им.
Fi1osof
Fi1osof
11 апреля 2021, 19:01
0
Я в комменте написал.
Сергей Шлоков
11 апреля 2021, 18:56
0
И никак не думал, что сам Джейсон такую засаду сделает :)
Бывает со всеми.

Отправил простенький PR. Лечит проблему.
Я видел. Я же теперь интегратор ) Ну ты хоть в описании опиши. )
Fi1osof
Fi1osof
11 апреля 2021, 18:51
+1
Я докопался до проблемы :)
Я конечно же все это проверял, но не достаточно глубоко. Попробовал как должно быть, не сработало, подумал никогда и не было. А оказывается было. Во второй вертке проверяет
$isLogin = $target == 'login' || $target == 'security/login';
а в 3-ей (на которой я и экспериментировал) уже вот так:
$isLogin = $target == 'Login' || $target == 'Security/Login';
Но в коннекторе-то проверяется именно на 'security/login', чтобы выставить define('MODX_REQP', false);

И никак не думал, что сам Джейсон такую засаду сделает :)

Всегда считал его мегаконсервативным в плане изменения кода, а тут фигак и в продакшн.

Отправил простенький PR. Лечит проблему.
Сергей Шлоков
11 апреля 2021, 18:09
+1
MODX под рукой нет.

Теоретически, вот тут определяется константа, которая позволяет пройти твоё блокирующее условие.
Fi1osof
Fi1osof
11 апреля 2021, 18:05
0
Покажи пример запроса. Я action=security/login первым делом проверял. И в статье показывал скриншопы, что без кукиса даже из админки через модалку не залогиниться. Вот здесь отбивает же запрос.
Fi1osof
Fi1osof
11 апреля 2021, 18:02
0
Хотя 401 означает — требуется аутентификация, а код для отсутствия прав — 403.
Люто плюсую.
Сергей Шлоков
11 апреля 2021, 18:01
+1
нет средств проверить авторизован ты или нет
Такого API нет.

Но проблема тут в том, что у нас неоднозначная система доступов, и легко могут быть случаи, когда интерфейс загружен, а на определенный запрос нет прав.
Я по этому поводу уже говорил, что в MODX нет корректного кода ответа — на все действия он отвечает кодом 401. Хотя 401 означает — требуется аутентификация, а код для отсутствия прав — 403.
Fi1osof
Fi1osof
11 апреля 2021, 18:00
0
По случаю проглядываю старый комменты. Андрей, вы довольно близки были к правде, и подобная сборка появилась, хоть и на Next+React, а не на Nuxt+Vue: github.com/prisma-cms/nextjs

На нем вот и небольшой эксперимент с MODX-админкой делался: modx.pro/development/21732
Сергей Шлоков
11 апреля 2021, 17:56
0
Я в курсе этого механизма. Поэтому и говорю, его оставить, через него залогиниться, а дальше работать со своей реализацией. Но у тебя будет и токен и куки.

Кстати, чтобы не блокировало, нужно передать в форме action = «security/login».
Fi1osof
Fi1osof
11 апреля 2021, 17:46
+2
Я его взял потому что довольно хорошо знаю его, и знаю, что роутинг на файлах для него — совсем не обязательная штука. К примеру вот этот роутер обрабатывает вообще все УРЛы, который не попали в логику явного роутинга, и в зависимости от типа ресурса я выдаю ту или иную конечную вьюху. И да, это MODX-ресурсы, берущиеся из таблицы site_content, только уже не средствами MODX (но это не особо важно).

А вот здесь и вовсе прописана обработка входящих запросов еще до вызова некста. Так что некст — это следствие, а не причина.

А некст я взял, потому что посмотрев имеющиеся решения на рынке, он больше всего понравился своей относительной минималистичностью и гибкостью в кастомизации.
Fi1osof
Fi1osof
11 апреля 2021, 17:39
0
Либо я тебя не понимаю, либо ты меня. Я выше писал, что одного только токена не достаточно, нужен еще и кукис (во всяком случае для обращения к MODX). Во-вторых, сам этот токен получить — не просто так.

Еще и по сути нет средств проверить авторизован ты или нет, то есть нет метода типа Security/User/GetCurrentUser. В чем проблема здесь? В том, чтобы понять когда ты авторизован, а когда нет. Единственный вариант тут — это просто реагировать на 401-ые ошибки (как это сейчас MODX делает). Но проблема тут в том, что у нас неоднозначная система доступов, и легко могут быть случаи, когда интерфейс загружен, а на определенный запрос нет прав. То есть ты запросил что-то, а в ответ получил 401-ый код серверный (что MODX делает много где) и это одновременно может быть признаком того, что ты не авторизован, хотя не гарантирует это (ты на самом деле авторизован, но нет прав на этот запрос и получил 401). В общем, все это делает работу с API неудобной и неоднозначной.
Fi1osof
Fi1osof
11 апреля 2021, 17:34
0
П.С. На странице админки для действия «security/login» блокировки вроде нет.
Проверь сам. Я ссылку на кусок кода дал, там блокируются вообще все запросы на коннектор, если пользователь не авторизован. А авторизация в админку работает через обычную форму с POST-запросом на саму страницу, а не через Ajax-запрос, и авторизация выполняется на уровне контроллера самой админки, а не через коннектор. При заходе на страницу админки, ответ обрабатывается через modManagerResponse, и если пользователь не авторизован, то вызывается контроллер security/login, и если отправляются данные авторизации, срабатывает handleLogin(), и там уже вызывается процессор Security/Login. То есть этот механизм не через коннекторы работает.
Артем
11 апреля 2021, 17:06
+1
Как заготовка — прикольно, но для админки, на мой взгляд, NextJS лишний, тем более со своим файловым роутингом, который на больших проектах заставляет страдать.
Ты взял NextJS потому что привык и удобно, либо из-за какой-то его конкретной фичи?
Сергей Шлоков
11 апреля 2021, 16:33
0
Так наоборот вроде проще. Нажал «Войти», загрузилась SPA страница с токеном и работой на здоровье.
Fi1osof
Fi1osof
11 апреля 2021, 16:31
0
Да не, можно. Но это как-то ненадежно. Хотелось бы поменьше костылей.
Сергей Шлоков
11 апреля 2021, 16:25
0
А почему нельзя для аутентификации использовать текущий подход с редиректом? Я понимаю про всякие приложения — нужен нормальный вариант через REST. Но тут же речь про админку.

П.С. На странице админки для действия «security/login» блокировки вроде нет.