U
а нормально, что на стороне клиента можно увидить этот самый токен?
Size: a a a
2019 October 11
DT
get может быть небезопастным?
по теории get не вносит изменения в данные
b
а нормально, что на стороне клиента можно увидить этот самый токен?
SL
а нормально, что на стороне клиента можно увидить этот самый токен?
Он же динамический
U
Еще вопрос по поводу http ответов:
вот если юзер залогинился нужно отправить код 200?
А если логин/пароль не подошел то нужно отправлять 401(401 Unauthorized («не авторизован (не представился)»))?
вот если юзер залогинился нужно отправить код 200?
А если логин/пароль не подошел то нужно отправлять 401(401 Unauthorized («не авторизован (не представился)»))?
S
get может быть небезопастным?
если следовать идеологии REST то не может быть, но тебе никто не мешает через get изменять данные, но так делать конечно же не нужно
PV
Ребята , такой вопрос юзаю JWT для auth, кидает json из refresh и access по access провожу auth , но после нескольких перезагрузок страницы он умирает. Правильно ли я понимаю что в этом же Json если передать не access а refresh auth пройдет успешно . И как можно словить ошибку джанги ( not auth) в js , чтобы потом передать рефреш вместо access
b
Еще вопрос по поводу http ответов:
вот если юзер залогинился нужно отправить код 200?
А если логин/пароль не подошел то нужно отправлять 401(401 Unauthorized («не авторизован (не представился)»))?
вот если юзер залогинился нужно отправить код 200?
А если логин/пароль не подошел то нужно отправлять 401(401 Unauthorized («не авторизован (не представился)»))?
SL
если следовать идеологии REST то не может быть, но тебе никто не мешает через get изменять данные, но так делать конечно же не нужно
Как это возможно ?
b
Ребята , такой вопрос юзаю JWT для auth, кидает json из refresh и access по access провожу auth , но после нескольких перезагрузок страницы он умирает. Правильно ли я понимаю что в этом же Json если передать не access а refresh auth пройдет успешно . И как можно словить ошибку джанги ( not auth) в js , чтобы потом передать рефреш вместо access
1) Авторизуешься, получаешь токен
2) Используешь токен в заголовках
3) Рефрешь токен используешь для рефшер роута, чтобы получить новый аксес
4) Пользуешься новым аксес, чтобы делать запросы
2) Используешь токен в заголовках
3) Рефрешь токен используешь для рефшер роута, чтобы получить новый аксес
4) Пользуешься новым аксес, чтобы делать запросы
b
Там же очевидная прям документация
U
А насколько важно в ответ прописывать код результата?
S
Как это возможно ?
чисто технически ты можешь создавать объекты модели, получая данные через get, но опять же - так делать не нужно
DT
А насколько важно в ответ прописывать код результата?
ты про статус коды ?
U
ты про статус коды ?
да
S
А насколько важно в ответ прописывать код результата?
важно
DT
да
ну как правило ты их не прописываешь руками
A
Celery же это более лучшая альтернатива django-cron? Последний использовался ли вообще здесь находящимися?