Как реализовать авторизацию по паролю/логину через WebSocket + WebStorage и без Cookie?

Question

[Рузэль Давлетяров]

Друзья товарищи Node.
Поделитись примерами для моего проекта (курсач) на NodeJS.

Хочу понять правильный принцип реализации аутинтификации с авторизации с использованием новых решении. На сервере у меня велосипед на Node. Через модуль ws я хочу реализовать пока что (username/password) авторизации.
Потом прибавит в весе еще и (social oauth 2.0).

Суть вот в чем. Нужно сделать связь через WebSocket с сервером, на клиенте использовать только WebStorage для хранения. Без куки.

Вот только покажите пожалуйста примеры если у вас конечно они есть :) Буду благодарен очень на любую информацию или код.

Я пробовал по такой схеме. Исли есть поддержка вебсокета то соединяюсь с сервером если нет то показываю отдельную страничку типа "Обновите браузер".
При успешном соединения на сервер передаю данные (name/pass) из формы. На сервере сверяю из БД. При успешном аутификации делаю простой файл в специальном папке где имя файла это (User ID + Соль). Дальше по сокету передаю имя этого файла. На клиенте на Local-storage храню его как (sid/data). Дальше при каждом запросе или отправке данных на сервер, я вместе с данными отправляю созданный json обьект как (sid/data) которые я парсю на сервер вытаскиваю data и пытаюсь найти такой файл с таким именим.
Но что-то блин не получается, вроде мнимизировал как мог. Курсач делается на Node + Leveldb и только для Chromium.

Answer 1

[Саша Грунин]

0) Этап авторизации по паролю и логину верный.
1) Как я понимаю, в файле хранится токен аутентификации. Это должен быть результат хеш-функции взятый, допустим из соли+email юзера. (Пароля там точно не должен быть).
2) Токен должен быть уникальным и длинным. Удостовериться в уникальности можно простыми запросами к базе на этапе генерации.
3) Токен стоит хранить не в файле, а в базе, в той же таблице что и другие данные юзеров.
4) Как передаётся токен - не понятно. Надо просто саму строку токена передавать в заголовке запросов и в сервере на этапе аутентификации оттуда вытаскивать и находить в базе юзера по токену.
5) С локал-стораджем на клиенте проблем быть не должно для такой задачи, если я всё верно понимаю. Просто сохранять/брать значение тогда, когда это нужно.

Comments

[Саша Грунин]

Чтобы всё получалось, пиши так:
Сначала серверную часть и протестируй с помощью любого Rest-клиента (например Advanced Rest Client для хрома) с подсунутыми в него данными. Когда серверная часть готова - пиши клиент.

[Рузэль Давлетяров]

@authorised тупой вопрос конечно, а у вебсокета есть внутренний ID. Вот представьте Клиент и Сервер успешно соединились по вебсокету. Что-бы в обе стороный НЕ гнать один и тот же JSON обьект. Нельзя ли идентифицироть так. Сервер при первом успешном соединении хранит в сессии так (ID socket/Tocken). И при последующий соединениях я просто через код выдергиваю ИД сокета и ищу в сессии(БД) а есть ли у меня такой ИД. Если есть все значит это пользователь auth прошел. Т.е. вебсоты ведь это грубо говоря постоянное соединении. Или нет!? если можно конечно какое нить ИД или что-либо подобное. Или ядро Linux гарантию не даст что предыдущий сокет канал с каким нить ИД будет участвовать именно с тем соединении.

[Рузэль Давлетяров]

@authorised по сути должно же быть такое решении, хоть на низком уровне. Можно сделать демон на Си, он будет типа решать если есть такое соединение то передать управлении Node. А в Node мы передадим токен уже и будет в дальнейшем сам сокетом работать. Демон на Си типа будет играть роль "проверяющего".

[Алексей Ярошевич]

@authorized +, только для сессий пользователей реляционные БД подходят не очень, лучше использовать key-value хранилки, типа memcached, redis, и т.п.

[Алексей Ярошевич]

@Ruzel можно так: используете url соединения websocket как уникальный ID транзакции и все ок.

[Рузэль Давлетяров]

@qfox да вы правы. Я так и сделал.

Answer 2

[maxfox]

Я не понимаю, вы пытаетесь реализовать cookies через local storage? Зачем? Даже если так, то вам нужно просто хранить достаточно длинный случайно сгенерированный токен, и отправлять его с запросом. По нему сервер будет определять пользователя. Та же session cookie, только с педалями..
Если уж пишете свой велосипед, реализуйте что-нибудь интересное, например challenge-response authentication.

Comments

[Рузэль Давлетяров]

А что есть альтернатива?

[Алексей Ярошевич]

@Ruzel автор имеет в виду. что куки для этих целей подходят лучше, потому что они встроены в браузер.