https://github.com/jhnvlglmlbrt/server-side-session-auth

Server side session аутентификация с сохранением токена в куки
https://github.com/jhnvlglmlbrt/server-side-session-auth

cookie session session-cookie session-handler token

Last synced: 8 months ago
JSON representation

Server side session аутентификация с сохранением токена в куки

• Host: GitHub
• URL: https://github.com/jhnvlglmlbrt/server-side-session-auth
• Owner: Jhnvlglmlbrt
• License: mit
• Created: 2023-10-01T14:44:48.000Z (over 2 years ago)
• Default Branch: main
• Last Pushed: 2023-10-22T16:55:36.000Z (over 2 years ago)
• Last Synced: 2025-06-18T09:55:11.184Z (12 months ago)
• Topics: cookie, session, session-cookie, session-handler, token
• Language: Go
• Homepage:
• Size: 342 KB
• Stars: 0
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

          

# Создание Server side session аутентификации с сохранением токена в куки клиента

***

1. Склонируйте репозиторий на вашу локальную машину:

   ```bash

   git clone https://github.com/Jhnvlglmlbrt/server-side-session-auth

2. Перейдите в директорию проекта:

   ```bash

   cd server-side-session-auth

3. Установить зависимости:

    

    ```bash

    go get 

4. Запустите код: 

    ```bash

    make run

5. Запросы к ручкам:

    ```bash 

    POST http://localhost:8080/signin

    {"username":"user2","password":"password2"}

    GET http://localhost:8080/welcome

    POST http://localhost:8080/refresh

    GET http://localhost:8080/logout

***

### Структура приложения

Любое приложение, хранящее пароли, должно обеспечить безопасное хранение своих паролей. Вы не можете просто хранить пароли в виде обычного текста, и в идеале должно быть невозможно угадать пароли ваших пользователей, даже если у вас есть доступ к их данным.

Т.к. мы не можем хранить пароли наших пользователей в том виде, в котором их получаем. Нужно преобразовать каждый пароль таким образом, чтобы его было легко проверить , но нелегко угадать.

Для этого будет использоваться функция хеширования (алгоритм bcrypt). Преимущество в том, что легко преобразовать фрагмент текста в хеш, но почти невозможно угадать фрагмент текста по хешу.

![HASH!](images/hash1.png)

Во время входа в систему можем проверить правильность пароля для данного имени пользователя, получив хэш пароля для этого имени пользователя и используя функцию сравнения bcrypt для проверки данного пароля с помощью хеша:

![HASH!](images/hash2.png)

/signup примет учетные данные пользователя и надежно сохранит их в нашей базе данных.

![HASH!](images/hash3.png)

/signinбудет принимать учетные данные пользователя и аутентифицировать их, сравнивая их с записями в базе данных.

![HASH!](images/hash4.png)

Теперь схемы ниже должны чуть поменяться - данные будут храниться не в map в коде,а в бд. И входить нужно будет только по 1 пользователю.

![DIAG!](images/diag1.png)

Если пользователь успешно входит в систему, этот обработчик установит файл cookie на стороне клиента и в своей локальной памяти. Как только файл cookie установлен на клиенте, он отправляется вместе с каждым последующим запросом.

![DIAG!](images/diag2.png)

Теперь, когда информация о сеансе пользователя на его клиенте сохранена (в форме файла session_token cookie) и на сервере, напишем обработчик «приветствия» для обработки информации, специфичной для пользователя.

Из кода мы видим, что наш обработчик приветствия дает нам 401 статус «неавторизованный» (или ) при определенных обстоятельствах:

1. session_tokenЕсли вместе с запросом нет файлов cookie (это означает, что запрашивающая сторона не входила в систему)

2. Если токен сеанса отсутствует в памяти (это означает, что запрашивающая сторона отправляет нам недопустимый токен сеанса)

3. Если срок сеанса истек

Аутентификация на основе сеанса обеспечивает безопасность сеансов ваших пользователей несколькими способами:

1. Поскольку токены сеанса генерируются случайным образом, злоумышленнику практически невозможно взломать сеанс пользователя.

2. Если токен сеанса пользователя каким-либо образом скомпрометирован, его нельзя будет использовать после истечения срока его действия. Вот почему время истечения ограничено небольшими интервалами (от нескольких секунд до пары минут).

![DIAG!](images/diag3.png)

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

Конечно, нельзя ожидать, что пользователь будет входить в систему каждый раз, когда истечет срок действия его токена. Чтобы решить эту проблему, можно создать другой маршрут, который принимает текущий токен сеанса пользователя и выдает новый токен сеанса с обновленным сроком действия.

![DIAG!](images/diag4.png)

Если пользователь решит выйти из нашего приложения, нам необходимо удалить его токен сеанса из нашего хранилища, а также из клиента пользователя.