Алексей Черемисин: P.S. Работу клиента по авторизации реализовал на jQuery. Не стал городить громозкости в виде фреймворков вроде Angular, Aurelia, хотя советовали.
Алексей Черемисин: Приветствую, Алексей. Спасибо вам большое за подсказки! Примерно на 50% проект выполнен. С помощью flask-security удалось реализовать генерацию токена при успешной регистрации и авторизации пользователя через signin/signup форму. Сам токен сохраняю в local storage для последующих запросов к API.
Далее, по условию задачи, необходимо реализовать отправку/получение сообщений в чат через RabbitMQ.
Вот теперь возник такой вопрос - каким образом нужно реализовать воркеры, чтобы они обрабатывали очередь и отсылали эти сообщения каждому подключенному клиенту? Что-то вот тут я никак не могу сообразить какая связка и последовательность должна быть.
Создал новый ресурс /api/send, к которому есть доступ только при наличии валидного токена. Этот ресурс принимает json-ом сообщение, которое предназначено для отправки в чат. Далее, в самой вьюхе я вызываю функцию, которая будет слать сообщение в RMQ. Очередь будет создаваться уникальная, по имени пользователя.
По условию задачи, клиент должен получать сообщения через /api/receive.
Я предполагал сделать так - при входе в чат, создается/запускается воркер, который и будет слушать очередь и отсылать сообщения клиенту при поступлении в очередь.
Подскажите пожалуйста, в правильном ли направлении я двигаюсь? Что-то меня смущает, то, что я буду создавать кучу воркеров, количество которых равно количеству онлайн пользователей в чате. Или все правильно, и так и должно быть?
Алексей Черемисин: Вот что я наметил исходя из беседы и прочитанного: при входе на сайт, вьюха index рендерит и отправляет в браузер шаблон. В шаблоне будет подключаться js скрипт. Далее, по нажатию на submit браузер отправляет ajax запрос на сервер. Сервер возвращает токен. Клиент как-то этот токен сохраняет и держит для последующих запросов к api. Я правильно все спланировал? Если да, то еще один вопрос-как клиенту хранить токен для будущих запросов?
Алексей Черемисин: Хорошо. Спасибо, что помогли разобраться с одним из вопросов. Тогда буду использовать flask-security. Попробую по крайней мере. Просто у меня тут одним из условий является то, что в качестве базы данных нужно использовать Mongo. Надеюсь, это не будет помехой для работы сторонних библиотек.
Алексей Черемисин: И это всё можно реализовать таким образом, чтобы сервер предоставлял отдельные АПИ ресурсы? /register, /auth, /send(для отправки сообщений в чат), /recv(для опроса новых сообщений)
Правильно ли я понимаю, что для того, чтобы было разделение клиента и АПИ сервиса, клиент должен слать ajax запросы, быть написан на JS или любом js-фреймворке, который бы отправлял запросы на ресурсы АПИ сервиса?
Алексей Черемисин: Спасибо!
На самом деле не то, чтобы без редиректов, мне разницы особо нет так как я собственно вообще даже не знаю как оно может всё быть реализовано. Поэтому и спрашиваю как это все желательно и нужно делать.
Пока что, на текущий момент я усвоил как работает авторизация - после отправки данных из формы на сервер, сервер передает клиенту токен и каждый последующий запрос от клиента должен производится с этим токеном. С этим вроде бы прояснилось. Пойду погляжу ссылку. А клиент как должен хранить этот самый токен? Как-то в куки?
Хотелось бы чем проще тем лучше))
Вот например на текущий момент форма сверстана на бутстрапе. Рендерится из темплейта.
Вот эта вьюха, где index.html это шаблон с формой авторизации:
@app.route("/")
def index():
if 'username' in session:
# If user already logged in then redirect to main chat window.
return redirect(url_for('chat'))
else:
return render_template('index.html')
В принципе я не против JS, jQuery, хочется сразу и к этому прикоснуться, чтоб иметь хоть какое-то представление о том как работает клиент в связке с апи.
Тэкс, давайте теперь по порядку :)
1) Пользователь заходит на главную страницу сайта, видит авторизационную форму для ввода логина и пароля. Вот эту форму кто доставляет в браузер? Вьюха от фласка?
Спасибо.
Да, это-то понятно, что нужно все сериализовывать и отправлять на клиент.
Но вот как быть с регистрацией и авторизацией клиента?
Сделать простую вьюху которая будет рендерить шабон с формой регистрации, а потом что происходит?
За ссылочки большое спасибо. Приятный курс на Udacity.
А вот в статье Мигеля, нашел кое, что интересное:
"The easiest way to secure our web service is to require clients to provide a username and a password. In a regular web application you would have a login form that posts the credentials, and at that point the server would create a session for the logged in user to continue working, with the session id stored in a cookie in the client browser. Unfortunately doing that here would violate the stateless requirement of REST, so instead we have to ask clients to send their authentication information with every request they send to us."
Кажется оно самое.
Люто плюсую. Foooon: Я как и вы примерно с 6 класса не знаю математику. Я просто поехал в букинистический магазин и набрал кучу школьных советских учебников. По секрету скажу набрал я с 5 класса т.к. элементарные вещи пришлось осваивать и освежать в памяти. Тут самое главное это время...не важно сколько это займет, самое главное выделить определенное время для занятий и не бросать это дело. У меня не получилось пока. Работа, семья, обучение программированию. До математики не удается пока добраться.
