CAT, special auth token for landings

Goal

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

User stories

1. Returning Visitor Story

Как пользователь, я могу переходить по разным рекламным офферам одного продукта. К примеру:

• catland.com/land1 - лендинг
• mirrorcatland.com/land2 - другой лендинг
• cat2go.com/ - редиректор, который определяет пользователя на ближайшее зеркало
• cat.com/ - основной сайт продукта
• catmirror.com/ - зеркало основного сайта

Сценарий:

• Как пользователь, я посещаю лендинг catland.com/land1 и прохожу регистрацию.
• После успешной регистрации меня перенаправляют на редиректор cat2go.com.
• Редиректор определяет мое гео и перенаправляет на основной сайт продукта cat.com.
• Затем, я перехожу по другой рекламе и попадаю на mirrorcatland.com/land2.

Текущая ситуация: я могу зарегистрироваться заново.

Желаемое поведение: попав на новый лендинг, система должна определить, что я уже зарегистрирован, автоматически залогинить меня и перенаправить на редиректор, который затем отправит меня на активное зеркало в залогиненом состоянии.

2. Personal promotion Story

Некоторые пользователи возвращаются на один и тот же промо оффер через длительное время. Мы хотим персонализировать их опыт:

• Пользователей со статусом VIP необходимо перенаправлять на отдельное VIP-зеркало.
• Пользователям с более чем четырьмя депозитами необходимо показывать баннер, рекламирующий турнир, вместо регистрационной формы.
• Пользователям, входящим в определенные группы, требуется показывать специальные бонусы.

Эти примеры иллюстрируют лишь часть возможных сценариев.

Implementation proposal

Special landing token

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

Добавление нового токена

Рекомендуется дополнить методы POST /profiles (регистрация) и PUT /auth (логин) дополнительным cookie с новым токеном:

headers.append("Set-Cookie", `__Host-landingauth=${token}; Path=/; HttpOnly; Max-Age=2629800; sameSite=None; secure=true`);

Ключевые моменты:

• sameSite=None позволяет cookie быть доступным для всех лендингов (кросс-доменные cookie).
• HttpOnly предотвращает возможность кражи cookie с помощью JavaScript.
• Префикс __Host- гарантирует дополнительную безопасность в соответствии со спецификацией cookie prefixes .

Таким образом, после регистрации или логина у пользователя сохраняется cookie со специальным токеном, который не может быть прочитан с помощью JavaScript.

Безопасность

Установленные cookie работают только если наш домен включен в список разрешенных в CORS. Это предотвращает возможность доступа к нашему API для получения токена авторизации с любого партнёрского сайта.

Добавить метод /restore

Необходимо добавить новый метод /restore, который будет вызываться при загрузке лендинга. Если у пользователя нет cookie, метод вернет ошибку или пустой объект. При наличии cookie __Host-landingauth, метод авторизует пользователя.

headers.append("Access-Control-Allow-Credentials", "true");

Метод /restore должен возвращать информацию пользователя (данные из /userInfo) и новые токены для авторизаци (refresh и jwt): Пример ответа:

{
	"jwtToken": "3cxdfcxsxsxfc",
	"refreshToken": "dxsxdsxsdx",
	"userInfo": {
		"balance": 0,
		"tags": ["someTags","someTags"],
	    "loyalty": {
	        "IDUser": "3045047524",
	   },
	    "email": "[email protected]",
	    // ... more fields
	}
}

Этот метод позволит нам принимать решения о показе дополнительного промо, основываясь на информации о пользователе, и создавать ссылки для автоматического логина.

Conclusion

Предложенный механизм минимизирует риски безопасности и сокращает необходимость доработок платформы.

Задачи для платформы:

• Добавить новую сущность, landingToken
• Добавить генерацию и возвращение landingToken в методы login и signUp
• Создать новый метод /restore для получения информации о пользователе по landingToken и получения актуальных refresh и JWT токенов.

Предложенное решение покрывает описанные сценарии и может быть расширено путём добавления новых данных для принятия решений в методе /restore.

3rd party cookies

Хотя долго обсуждался отказ от третьесторонних cookies, Гугл решил продолжать их использовать : https://www.singlegrain.com/blog/google-stops-third-party-cookie-deprecation.