AA
JSCookie.set('_session_id', token, {path: '/'});Size: a a a
2020 August 25
AA
Наприклад, так
VY
Є два гарні варіанти захищеного ключа авторизації:
1. Зберігати його в Cookie: HttpOnly; Secure; SameSite=Lax/Strict
2. Пересилати його через Authorization, зберігати, де зручно, але оновлювати з певним малим інтервалом: сесія + раз на годину, можна менше.
Обидва варіанти досить важкі в реалізіції.
1. Зберігати його в Cookie: HttpOnly; Secure; SameSite=Lax/Strict
2. Пересилати його через Authorization, зберігати, де зручно, але оновлювати з певним малим інтервалом: сесія + раз на годину, можна менше.
Обидва варіанти досить важкі в реалізіції.
VY
Якщо зберігати Cookie без HttpOnly, є можливість крадіжки ключа через XSS атаку, або подібні.
Саме тому в другому варіанті ключ треба регуляно оновлювати. Це передбачає OAuth 2.0, якщо я не помиляюся.
Саме тому в другому варіанті ключ треба регуляно оновлювати. Це передбачає OAuth 2.0, якщо я не помиляюся.
VY
Ключ на клієнті не обов’язковий. Права доступу можна отримувати із сервера разом із запитами, наприклад, так:
- при переході на сторінку (точку API) отримувати 401, якщо доступ анонімний
- якщо користувач неавторизований (неанонімний, але не має права на ресурс) — 403
- при переході на сторінку (точку API) отримувати 401, якщо доступ анонімний
- якщо користувач неавторизований (неанонімний, але не має права на ресурс) — 403
VY
Тримати логіку доступу до ресурсу на клієнті, на мій погляд, неправильно. Так порушуються принципи побудови ПЗ: DRY, SRP, OCP
VY
Але все ж, якщо треба зберігати ключ на клієнті, я би мабуть робив
1. через local storage, але довелося б для безпеки його оновлювати самому
2. через відкриту захишену куку, до якої є доступ, але її сервер мав би оновлювати з кожним запитом, наприклад
3. мати точку типу
1. через local storage, але довелося б для безпеки його оновлювати самому
2. через відкриту захишену куку, до якої є доступ, але її сервер мав би оновлювати з кожним запитом, наприклад
3. мати точку типу
/user, яка повертає токен і дані про користувача за сесійним ключем, і токен з неї вже включається в Authorization-заголовокVF
Є два гарні варіанти захищеного ключа авторизації:
1. Зберігати його в Cookie: HttpOnly; Secure; SameSite=Lax/Strict
2. Пересилати його через Authorization, зберігати, де зручно, але оновлювати з певним малим інтервалом: сесія + раз на годину, можна менше.
Обидва варіанти досить важкі в реалізіції.
1. Зберігати його в Cookie: HttpOnly; Secure; SameSite=Lax/Strict
2. Пересилати його через Authorization, зберігати, де зручно, але оновлювати з певним малим інтервалом: сесія + раз на годину, можна менше.
Обидва варіанти досить важкі в реалізіції.
дуже дякую за відповідь, намагатимусь щось з цього реалізувати
2020 August 28
ВК
Оу, а цей чат помер : ( ?
Дп
за 3 дня?
ВК
Ну і до цього активності тут було мало
ВК
Просто якщо тут є людей 10, які вивчають щось одне - можна ж робити групами проекти - це набагато ефективніше🤷♂
E
На подумать - признаки незрелой компании: 1. Разработчики общаются с клиентами (именно с бизнесом) 2. Отсутствует документация (проекты,процессы) 3. Текучка
E
4. ПМ даёт указания на словах -"как оно должно быть" без письменного подтверждения
E
5. ПМ шлёт скриншоты в Скайп без пояснений с криком: апятьбаг
IT
Просто якщо тут є людей 10, які вивчають щось одне - можна ж робити групами проекти - це набагато ефективніше🤷♂
собственно у нас как раз для этого пир-ту-пир есть. Те, кто проходят наш курс самостоятельно, обычно там пытаются организоваться
BK
В чому ти міряєш ефективність ?)
+ У кожного свій темп, графік і тд. Не всім підходить робити проекти.
+ У кожного свій темп, графік і тд. Не всім підходить робити проекти.
ВК
собственно у нас как раз для этого пир-ту-пир есть. Те, кто проходят наш курс самостоятельно, обычно там пытаются организоваться
суть в том, что когда сам проходишь курс - шанс того что ты его окончишь минимален, а если в тиме (не в группе а именно в тиме) то шанс того, что ты не закончишь минимален
IK
Общение напрямую с бизнесом очень важно чтобы не играть в испорченный телефон
ВК
В чому ти міряєш ефективність ?)
+ У кожного свій темп, графік і тд. Не всім підходить робити проекти.
+ У кожного свій темп, графік і тд. Не всім підходить робити проекти.
Так це ж стандартна відмазка ...