Fi1osof

то получаю бесконечные аякс запросы:

Зато в них видно, что кукисы летят. Осталось только сервер нормально настроить.

P.S. я ушел к Морфею, так что отвечу только через несколько часов, если еще будут комменты.

Так не надо поднимать его на 80-ом. На 80-ом у вас сайт крутится, а сокет-сервер крутится на своем 2025-ом. Запросы у вас должны идти на /api/ вашего сайта, а не сокет-сервера. Просто на уровне сервера вы запросы на /api/ которые идут проксируете на 2025-ый порт. Для фронта это все неведомо, фронт ничего не знает про то, что и как там на сервере. Но отправляя на /api/ текущего домена, передаются и кукисы, потому что это тот же самый домен, а не другой. На уровне nginx вы /api/ запросы проксируете на 2025, вместе с кукисами они улетают, не доходя напрямую на сайт. А вот на уровне сокет-сервера, получив таким образом запрос с кукисами, вы уже должны получить $modx с инициализацей.

Велика вероятность в том, что у вас разные хосты. Домен один, а порты разные. Сам сайт на 80-ом порту, а запросы идут на порт 2025. Скорее всего это проблема именно в этом. Я делаю так: создаю на уровне nginx подмену для адреса /api/ и все запросы сокета летят туда, а там уже проксируется на сокет-порт. Пример конфига:

location /api/ {
        
    
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 36000;

        rewrite ^/api/(.*) /$1 break;
        proxy_pass http://localhost:4000;
        proxy_redirect     off;
        proxy_set_header   Host $host;

        proxy_set_header X-Real-IP $remote_addr ;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    }

Попробуйте для начала без конфига настроить сокет-запросы на тот же домен, просто посмотрите будут ли передаваться кукисы в запросах или нет. Ответа корретного не будет, но хотя бы в запросах кукисы должны появиться. Если появятся, то уже проксирование настраивать. А пока куки не будут передаваться, то и ловить на стороне сервера нечего.

Николай, я не знаю как именно у вас реализована работа MODX-API внутри сокет-сервера, то надо учитывать несколько моментов:

1. По умолчанию может не быть включена передача кукисов в заголовках, или могут быть проблемы кросс-доменных запросов (CORS). Убедитесь, что в сокет-запросах заголовки передаются, а главное, передается кука сессии.


2. На стороне сокет-сервера, где вы подключаете MODX-API, вам надо поймать куку PHPSESSID и скормить в инициализацию $modx. Так же убедитесь, что у вас эта кука там в наличии, а главное, инициализация $modx идет с контекстом, в котором пользователь авторизован.

3. У вас сокет-соединение не понимает авторизацию вообще всегда, или после авторизации если перезагрузить страницу, то все ОК, а просто проблема именно после авторизации без перезагрузки страницы? Просто это важный момент, так как сокет-соединение не отсылает кукисы в каждом запросе. Кукисы отправляются только при установке сокет-соединяния. То есть после авторизации и на логаут надо сокет-соединение реконнектить. Надо смотреть в сторону socketio.close(false, false);

В общем, подробней распишите что и как получилось сделать, а на какой стадии какие затыки. Наверняка разобраться можно будет, но здесь не все так просто и парой строчек кода не отделаться.

Не полная расшифровка получилась… Еще ищет и с условием, что топик содержит в тексте «pdoTools»

Не за что.
Так же и конец строки можно проверять /(.+|$)/

Бага: ссылка вида https://домен/topics/modx-klub-2.14.0-filtry-by-@prisma-cms/filters.html разбивается на две части. Ты выше писал, почему так происходит, но это не оправдание, надо проверять маской /(^| )\@/ или типа того, то есть упоминание должно работать только если символ @ в начале строки или после пробела. Все остальное не должно восприниматься как упоминание.
Даблбага: если на произвольном тексте создавать ссылку через кнопочку и вставлять такую ссылку с собачкой в середине строки, ссылка формируется на отправку почты.

Пожалуйста.

Не соглашусь. Возьмите любой средний магазин с популярными вопросами «а как мне получить категории, в которых есть товары» или «где есть такие-то опции» и т.д. и т.п. Каждый день здесь же куча вопросов на эту тему. И каждый пишет свои костыли. Но когда система полностью клиент-серверно стандартизирована, подобных вопросов становится значительно меньше. Выигрыш в итоге не в скорости работы, а в скорости разработки, надежности и простоте сопровождения. Ну и взаимосовместимость различных модулей. Когда все они боле менее придерживаются стандартов, их удобно совместно использовать.

В том числе и это. То есть можно в одном запросе получить данные сразу из разнызх источников. Условно, мы не задумываемся о том, где и как сервер получает данные. Мы просто смотрим схему, пишем запрос в соответствии с ней и получаем ответ. Запросить что-то лишнее (отсутствующее в схеме) не получится. Это исключает распространенные случаи с классическим REST, когда на сервере логика и структура данных уже поменялась, а с фронта все еще прилетают старые запросы и мы получаем не ясно что.

Таки да.

Вот так мы подошли к ключевой разнице. GraphQL — это client-first API, то есть основная его часть активная в плане составления запросов уходит на сторону клиента. Приведу поясняющий пример. Возьмем этот же запрос

query {
  posts { # это массив
    title
    body
    author { # мы может пойти глубже
      name
      avatarUrl
      profileUrl
    }
  }
}

На стороне сервера при его обработке GraphQL выполнит запрос на получение топиков, а потом, пробегаясь по каждому результату, будет получать авторов. (Это базовая процедура и конечно же может сильно отличаться в зависимости от подхода конечного разработчика, но в большинстве случаев будет работать именно так). Но если мы пошлем туда же этот же запрос, только исключим из него авторов, то есть вот такой запрос:

query {
  posts { # это массив
    title
    body
  }
}

то и получать и отдавать сервер будет только топики. А вот авторов он не будет получать. То есть нет лишней нагрузки.

В случае же с приведенным примером на MODX Graph, серверный запрос всегда будет получать все описанные в исходном запросе данные. И всегда отдавать их все. То есть если и использовать с этим GraphQL, то в лучшем случае мы получим меньше данных в запросе (сэкономим трафик), но нагрузка от этого сильно не упадет. И второй момент: мы не сможем получить больше, то есть запрос полный описан уже, и если мы туда что-то забыли прописать на серверной части, то больше запросить и не сможем. В полноценной же реализации можно получать результаты с очень большой вложенностью.

Мне не посетители нужны в цифровом исчислении, а обратная связь. Просто я что-то сделал опять нормальное и хочу поделиться. Но как это часто бывает, не многие могут понять сразу. Обычно потом, через год-два-три начинается «О, а вроде норм штука». Видимо опять тот случай. Ну ладно, кому-нибудь может все же будет интересно.