🍪 Cookies vs Sessions: В чем разница и как мы "остаемся залогиненными"?

Протокол HTTP не имеет памяти (stateless). Если вы ввели логин и пароль, при переходе на следующую страницу сервер вас уже «забудет». Чтобы этого не происходило, придумали механизмы сохранения состояния. Разбираем наглядную шпаргалку! 👇

1️⃣ Как работают Куки (Cookies)?

(Верхняя часть схемы)

• Логин: Вы вводите данные, сервер их проверяет.
• Ответ: Сервер отправляет вашему браузеру cookie - небольшой фрагмент данных (например, информацию о пользователе или токен).
• Следующий запрос: Когда вы переходите на другую страницу, браузер автоматически прикрепляет эту cookie к запросу. Сервер читает её и понимает: "Ага, это снова тот самый юзер, пускаем!".

💡 Суть: Сами данные хранятся на стороне клиента (в вашем браузере) и летают туда-сюда при каждом запросе.

2️⃣ Как работают Сессии (Sessions)?

(Нижняя часть схемы)

• Логин: Вы авторизуетесь на сервере.
• Создание сессии: Сервер создает сессию и сохраняет все ваши данные у себя (в специальной базе - Session Store).
• Ответ: Сервер отправляет браузеру cookie, но в ней лежит только уникальный ID сессии, а не сами данные!
• Следующий запрос: Браузер отправляет cookie с ID. Сервер смотрит в свою базу, находит по этому ID вашу сессию, проверяет её и выдает нужную страницу.

💡 Суть: Данные хранятся на сервере. У клиента в браузере лежит только "билетик" (ID), по которому сервер его узнаёт.

Что выбрать?

• Куки хороши для некритичных данных (тема оформления, язык, корзина товаров для неавторизованных), так как они не нагружают память сервера.
• Сессии нужны для безопасности (авторизация, банковские операции). Злоумышленник не сможет подделать данные, так как они надежно лежат на сервере.

Как правило, в современных веб-приложениях они работают в паре: сессия хранит данные на бекенде, а куки доставляют ID этой сессии в браузер.

#webdev #backend #frontend #база #шпаргалка #cookies #sessions

📲 Мы в MAX

👉 @Bookflow

🔐 Путеводитель по аутентификации: от Cookies до OAuth 2.0

Разбираться в способах входа пользователя в систему можно бесконечно, но эта шпаргалка отлично раскладывает всё по полочкам. Давайте разберем эволюцию методов «узнавания» пользователя.


1. WWW-Authenticate (Basic Auth)
Самый древний способ. Браузер запрашивает логин/пароль и отправляет их в каждом заголовке.

• Минус: Невозможно нормально управлять жизненным циклом сессии (сложно разлогиниться).


2. Session-cookie
Классика веба. После входа сервер создает сессию в базе, а браузеру отдает Session ID в куках.

• Проблема: Плохо масштабируется и «не дружит» с мобильными приложениями, которые не всегда умеют работать с куками так же, как браузеры.


3. Token & JWT
Чтобы не дергать базу данных каждый раз, придумали токены.

• Token: Обычная строка, которую проверяет отдельный сервис валидации.

• JWT (JSON Web Token): «Умный» токен. Он содержит внутри хедер, полезную нагрузку (данные пользователя) и подпись. Серверу не нужно лезть в базу, чтобы проверить его валидность - достаточно проверить подпись.


4. SSO (Single Sign-On)
Когда у вас много сайтов (a.com, b.com), а логин один. Центральный сервис аутентификации (CAS) берет на себя проверку личности и перенаправляет пользователя между ресурсами без повторного ввода пароля.


5. OAuth 2.0
Стандарт для предоставления доступа сторонним приложениям (например, «Войти через Google»). Основные сценарии:

• Authorization Code: Самый безопасный (через браузер и сервер).

• Client Credentials: Для общения между двумя серверами.

• Implicit Grant: Упрощенный путь для мобильных и JS-приложений (сейчас считается менее безопасным).

• Password Grant: Прямая передача логина/пароля (используется только в доверенных приложениях).

#backend #security #jwt #oauth #webdev

♻️ Сделай репост, чтобы помочь другим.

📲 Мы в MAX

👉 @Bookflow

🍪 Cookies vs Sessions: В чем разница и как мы "остаемся залогиненными"?

Протокол HTTP не имеет памяти (stateless). Если вы ввели логин и пароль, при переходе на следующую страницу сервер вас уже «забудет». Чтобы этого не происходило, придумали механизмы сохранения состояния. Разбираем наглядную шпаргалку! 👇

1️⃣ Как работают Куки (Cookies)?

(Верхняя часть схемы)

• Логин: Вы вводите данные, сервер их проверяет.
• Ответ: Сервер отправляет вашему браузеру cookie - небольшой фрагмент данных (например, информацию о пользователе или токен).
• Следующий запрос: Когда вы переходите на другую страницу, браузер автоматически прикрепляет эту cookie к запросу. Сервер читает её и понимает: "Ага, это снова тот самый юзер, пускаем!".

💡 Суть: Сами данные хранятся на стороне клиента (в вашем браузере) и летают туда-сюда при каждом запросе.

2️⃣ Как работают Сессии (Sessions)?

(Нижняя часть схемы)

• Логин: Вы авторизуетесь на сервере.
• Создание сессии: Сервер создает сессию и сохраняет все ваши данные у себя (в специальной базе - Session Store).
• Ответ: Сервер отправляет браузеру cookie, но в ней лежит только уникальный ID сессии, а не сами данные!
• Следующий запрос: Браузер отправляет cookie с ID. Сервер смотрит в свою базу, находит по этому ID вашу сессию, проверяет её и выдает нужную страницу.

💡 Суть: Данные хранятся на сервере. У клиента в браузере лежит только "билетик" (ID), по которому сервер его узнаёт.

Что выбрать?

• Куки хороши для некритичных данных (тема оформления, язык, корзина товаров для неавторизованных), так как они не нагружают память сервера.
• Сессии нужны для безопасности (авторизация, банковские операции). Злоумышленник не сможет подделать данные, так как они надежно лежат на сервере.

Как правило, в современных веб-приложениях они работают в паре: сессия хранит данные на бекенде, а куки доставляют ID этой сессии в браузер.

#webdev #backend #frontend #база #шпаргалка #cookies #sessions

♻️ Сделай репост, чтобы помочь другим.

📲 Мы в MAX

👉 @Bookflow

🔐 Путеводитель по аутентификации: от Cookies до OAuth 2.0

Разбираться в способах входа пользователя в систему можно бесконечно, но эта шпаргалка отлично раскладывает всё по полочкам. Давайте разберем эволюцию методов «узнавания» пользователя.


1. WWW-Authenticate (Basic Auth)
Самый древний способ. Браузер запрашивает логин/пароль и отправляет их в каждом заголовке.

• Минус: Невозможно нормально управлять жизненным циклом сессии (сложно разлогиниться).


2. Session-cookie
Классика веба. После входа сервер создает сессию в базе, а браузеру отдает Session ID в куках.

• Проблема: Плохо масштабируется и «не дружит» с мобильными приложениями, которые не всегда умеют работать с куками так же, как браузеры.


3. Token & JWT
Чтобы не дергать базу данных каждый раз, придумали токены.

• Token: Обычная строка, которую проверяет отдельный сервис валидации.

• JWT (JSON Web Token): «Умный» токен. Он содержит внутри хедер, полезную нагрузку (данные пользователя) и подпись. Серверу не нужно лезть в базу, чтобы проверить его валидность - достаточно проверить подпись.


4. SSO (Single Sign-On)
Когда у вас много сайтов (a.com, b.com), а логин один. Центральный сервис аутентификации (CAS) берет на себя проверку личности и перенаправляет пользователя между ресурсами без повторного ввода пароля.


5. OAuth 2.0
Стандарт для предоставления доступа сторонним приложениям (например, «Войти через Google»). Основные сценарии:

• Authorization Code: Самый безопасный (через браузер и сервер).

• Client Credentials: Для общения между двумя серверами.

• Implicit Grant: Упрощенный путь для мобильных и JS-приложений (сейчас считается менее безопасным).

• Password Grant: Прямая передача логина/пароля (используется только в доверенных приложениях).

#backend #security #jwt #oauth #webdev

♻️ Сделай репост, чтобы помочь другим.

📲 Мы в MAX

👉 @Bookflow