Javascript.RU

Создать новую тему Ответ
 
Опции темы Искать в теме
  #1 (permalink)  
Старый 28.08.2017, 07:10
Аватар для Ваяс
Аспирант
Отправить личное сообщение для Ваяс Посмотреть профиль Найти все сообщения от Ваяс
 
Регистрация: 29.12.2011
Сообщений: 67

Установить сессию в nodejs из стороннего сервиса
Основная задача состоит в том, что бы узнавать от какого пользователя приходят данные, возможно тот подход который я использую в данном примере не подойдёт.

Пытаюсь установить сессию для пользователя из одного сайта в другой, есть site1 написанный на php и site2 написанный на nodejs. C site1 я отправляю ajax запрос на url http://site2:3000/send, там устанавливается сессия.
$.ajax({
        type: 'GET',
        url: "http://site2:3000/send",
        dataType: 'html',
        success: function (data) {
            $.ajax({
                type: 'GET',
                url: "http://site2:3000/test-send",
                dataType: 'html',
                success: function (data) {
                    alert(data);
                }
            });
        }
    });


Но как только я обращаюсь на следующий URL http://site2:3000/test-send той сессии которая ставилась для http://site2:3000/send больше нет. Код самого nodejs следующий
router.get('/send', function(req, res, next) {
req.session.test_req = "red";
console.log(req.session.test_req); // После обращения через site1 сессия в консоли есть
res.end();});

router.get('/test-send', function(req, res, next) {
console.log(req.session.test_req);  // После обращения через site1 сессии здесь уже нет
res.end();});

Если обращаться на site2 напрямую через браузер, то сессии ставятся корректно и сохраняются.
Возможно ли решить задачу таким образом, что бы создать сессию для пользователя отправив ajax запрос через другой сервис или необходимо какое-то иное решение?

Я задавал подобный вопрос на stackoverflow https://ru.stackoverflow.com/questio...B8%D1%81%D0%B0 Но решение которое они предложили, мне пока не очень понятно, может быть у кого-то будут ещё решения?
Ответить с цитированием
  #2 (permalink)  
Старый 28.08.2017, 14:42
Аватар для destus
Профессор
Отправить личное сообщение для destus Посмотреть профиль Найти все сообщения от destus
 
Регистрация: 18.05.2011
Сообщений: 1,207

Ваяс,
на /send подписываешь токен, отправляешь на клиента. На клиенте сохраняешь в каком-нибудь sessionStorage и ко всем последующим запросам добавляешь этот самый токен.
Ответить с цитированием
  #3 (permalink)  
Старый 29.08.2017, 17:32
Профессор
Отправить личное сообщение для Audaxviator Посмотреть профиль Найти все сообщения от Audaxviator
 
Регистрация: 28.04.2017
Сообщений: 214

По-моему, сама постановка задачи не правильная.
"Сессия" - это сохранение какой-то составляющей состояния связи между браузером - и сервером, отдавшим именно этому браузеру страницу.
В данном случае браузеру страницу отдал один сервер, а поддерживать "состояние" при следующих запросах требуется от другого сервера.

Специалисты говорят о "токенах", но не понятно, как это может работать? Токен, опять же, отдаёт на страницу сервер - вместе с отдачей страницы по GET-запросу. Если эту страницу (с токеном) отдал один сервер - откуда другой сервер может знать этот токен, и был ли он там вообще?

Короче, можно попробовать идентифицировать сам браузер - каждый браузер имеет уникальный номер и ещё какие-то фишки. Информацию о браузере легко отправить на любой сервер с помощью navigator в javascript-коде, отданном со страницей.
Т.е. идентифицировать не сессию - а сам браузер, с которого идут запросы. Вот такая у меня чиста теоретическая идея.
Ответить с цитированием
  #4 (permalink)  
Старый 29.08.2017, 18:50
Профессор
Отправить личное сообщение для Audaxviator Посмотреть профиль Найти все сообщения от Audaxviator
 
Регистрация: 28.04.2017
Сообщений: 214

Токен - это просто ещё один куки-секрет, случайно генерируемый. Он в браузере при получении страницы и значится в консоли - в разделе Cookies.
Как пример, стандартная "проверка на кросс-доменные атаки" (csrf) - сервер отправил токен со страницей, а потом его же проверил-идентифицировал при POST-запросе. Всё просто: он отдал - он же и проверил. И вот эта система в принципе не работает без установки модуля express-session - потому что сама "сессия" основана на куках (или токенах - что, практически, тупо одно и то же).
Ответить с цитированием
  #5 (permalink)  
Старый 29.08.2017, 19:15
Аватар для destus
Профессор
Отправить личное сообщение для destus Посмотреть профиль Найти все сообщения от destus
 
Регистрация: 18.05.2011
Сообщений: 1,207

Цитата:
Специалисты говорят о "токенах", но не понятно, как это может работать? Токен, опять же, отдаёт на страницу сервер - вместе с отдачей страницы по GET-запросу. Если эту страницу (с токеном) отдал один сервер - откуда другой сервер может знать этот токен, и был ли он там вообще?
Почитайте про jwt. Я подписываю секретным ключом обьект с данными и отправляю на клиента. Клиент его может декодировать (base64), выводить эти самые данные в любом месте моего приложения и т.д. При отправке этого самого токена на сервер, сервер его расшифровывает этим самым секретным ключом, т.е. проверяет как бы на валидность.
Ответить с цитированием
  #6 (permalink)  
Старый 30.08.2017, 11:31
Аватар для Ваяс
Аспирант
Отправить личное сообщение для Ваяс Посмотреть профиль Найти все сообщения от Ваяс
 
Регистрация: 29.12.2011
Сообщений: 67

Сообщение от Audaxviator Посмотреть сообщение
По-моему, сама постановка задачи не правильная.
Я немного не корректно описал задачу, но общий смысл её думаю все поняли. Суть в том что мне необходимо идентифицировать пользователя отправляющего запросы с site1 на site2
Сообщение от Rise Посмотреть сообщение
Заголовок доступа итак будет пропускать запросы только с site1 что еще надо какие токены...
Да всё правильно, тут проблема в том, что бы прямо с самого сайта пользователь находясь на site1 под своим аккаунтом не смог получить данные которые ему не принадлежат (подделав запросы).
На php.ru предложили как я думаю самое оптимальное решение, которое мне необходимо.

Формируем на site1 хеш который создаём из времени + номер юзера + секретное слово.
Потом отправляем время, номер и хеш в браузер посетителю. Он там это дело отправляет запросом на второй сервак.
Второй сервак берёт из этого только время + номер юзера, добавляет опять свой секрет (который одинаковый на обоих сайтах, но пользователи сайта его никогда не видят).
Сравниваешь хеш присланный и хеш получившийся. Если совпал - значит на обоих серваках хешировались одинаковые строки, т.е. секрет правильный использовался. А это значит, что токен настоящий.

Проверяем время, чтобы с одним токеном больше пары минут нельзя было заходить. Если токен не старый - значит всё правильно.
Ответить с цитированием
  #7 (permalink)  
Старый 30.08.2017, 11:38
Аватар для destus
Профессор
Отправить личное сообщение для destus Посмотреть профиль Найти все сообщения от destus
 
Регистрация: 18.05.2011
Сообщений: 1,207

Ваяс,
Ну так это и есть JSON Web Token. Считайте что ваш номер юзера - это объект с данными. И вы его подписываете секретным ключом. Не изобретайте велосипедов. Умные люди его до вас давно изобрели.
Ответить с цитированием
  #8 (permalink)  
Старый 30.08.2017, 16:57
Профессор
Отправить личное сообщение для Audaxviator Посмотреть профиль Найти все сообщения от Audaxviator
 
Регистрация: 28.04.2017
Сообщений: 214

Да нормально всё. Дело не в том, что неправильно описал задачу - дело в самом слове "сессия".
Речь о том, что нужно "подделать сессию", т.е. сделать "какбэ сессию" из того, что ей не является.
То, что вы написали, и является "подделкой сессии" - если это понятно и работает, то и хорошо: отличный опыт (и лично я, кстати, буду иметь его в виду).
Спасибо за тему.

Последний раз редактировалось Audaxviator, 30.08.2017 в 17:23.
Ответить с цитированием
Ответ



Опции темы Искать в теме
Искать в теме:

Расширенный поиск