# SSO без хранения личных данных пользователей в моей собственной базе данных

**URL:** https://meta.discourse.org/t/sso-without-storing-personal-user-data-in-my-own-database/121665
**Category:** SSO
**Created:** [29.Июнь.2019 19:26:55 UTC](https://meta.discourse.org/t/sso-without-storing-personal-user-data-in-my-own-database/121665 "2019-06-29T19:26:55Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![rmens](https://avatars.discourse-cdn.com/v4/letter/r/3ab097/32.png) [@rmens](https://meta.discourse.org/u/rmens)
#### Post date: [29.Июнь.2019 19:26:55 UTC](https://meta.discourse.org/t/sso-without-storing-personal-user-data-in-my-own-database/121665/1 "2019-06-29T19:26:55Z")

</div>

Привет, друзья,

Наверняка вы слышали о GDPR в Европе. Мой вопрос как раз связан с этим. Вот ситуация:

- Наш сайт использует WordPress как систему входа, и мы хотим оставить её для наших _редакторов_.
- Из-за GDPR мы не хотим хранить какие-либо персональные данные _читателей_ в базе данных WordPress. Мы хотим хранить их в Discourse.

Использование Discourse как отдельного форума — это нормально. Однако мы также хотим, чтобы люди входили в систему через Discourse на нашем основном сайте, чтобы комментировать статьи. Идея заключается в том, чтобы позволить им комментировать статьи прямо под ними, не перенаправляя их на Discourse. У каждой статьи есть тема как «центр комментариев», и комментарии будут публиковаться и загружаться под статьями через API Discourse. Мы готовы разработать собственное решение для этого, но не хотим хранить персональные данные пользователей в базе данных WordPress из-за GDPR.

Насколько я понимаю, при реализации SSO через wp-discourse, где Discourse выступает провайдером SSO, пользователи будут создаваться в WordPress. Я пытался придумать креативные способы решения этой проблемы, например, используя cookie `_t`. Но он недоступен в домене WordPress. Есть какие-нибудь идеи, которые могли бы прояснить ситуацию?