# Вопрос безопасности/конфиденциальности: Email раскрыт в URL перенаправления провайдера DiscourseConnect

**URL:** https://meta.discourse.org/t/security-privacy-concern-email-exposed-in-discourseconnect-provider-redirect-url/397980
**Category:** Feature
**Tags:** pr-welcome
**Created:** [09.Март.2026 18:05:25 UTC](https://meta.discourse.org/t/security-privacy-concern-email-exposed-in-discourseconnect-provider-redirect-url/397980 "2026-03-09T18:05:25Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![JACK\_ZHANG](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jack_zhang/32/492350_2.png) [@JACK\_ZHANG](https://meta.discourse.org/u/JACK_ZHANG)
#### Post date: [09.Март.2026 18:05:25 UTC](https://meta.discourse.org/t/security-privacy-concern-email-exposed-in-discourseconnect-provider-redirect-url/397980/1 "2026-03-09T18:05:25Z")

</div>

**Описание ошибки**

При использовании Discourse в качестве [поставщика DiscourseConnect (поставщика SSO)](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974) адрес электронной почты пользователя раскрывается в URL-адресе перенаправления 302 для доверяющей стороны. Это происходит из-за того, что метод `populate_user_data` в файле `lib/second_factor/actions/discourse_connect_provider.rb` всегда устанавливает значение поля email:

```ruby
  def populate_user_data(sso)
    sso.name = current_user.name
    sso.username = current_user.username
    sso.email = current_user.email # <-- Всегда включается
    sso.external_id = current_user.id.to_s
    # ...
  end

```

Затем этот email кодируется в Base64 и включается в URL-адрес перенаправления:  
`https://target-site.com/callback?sso=<base64_payload>&sig=<hmac_signature>`

Декодирование полезной нагрузки Base64 раскрывает адрес электронной почты в открытом виде.

Влияние

1. История браузера: адрес электронной почты сохраняется в истории браузера.
2. Логи Nginx: полный URL-адрес записывается в логи доступа nginx.
3. Логи целевого сайта: доверяющая сторона получает адрес электронной почты без явного согласия пользователя.
4. Ожидания пользователей: пользователи обычно авторизуются, чтобы подтвердить «Я легитимный пользователь» — они не ожидают, что их адрес электронной почты будет передан.

Ожидаемое поведение

Пользователи должны иметь возможность контролировать, передается ли их адрес электронной почты доверяющей стороне. Должна быть предусмотрена конфигурационная опция, аналогичная `discourse_connect_overrides_groups`, `discourse_connect_overrides_avatar` и т. д.

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

Шаги для воспроизведения

1. Включите `enable_discourse_connect_provider`.
2. Настройте `discourse_connect_provider_secrets` (например, `*.example.com|secret123`).
3. Выполните вход пользователя через поставщика [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true).
4. Проверьте URL-адрес перенаправления 302 — адрес электронной почты виден в параметрах URL.

URL-адрес перенаправления выглядит следующим образом:  
`https://relying-party.com/sso?sso=bm9uY2U9xxx&sig=xxx`

Декодирование параметра `sso` раскрывает:  
`nonce=xxx&return_sso_url=xxx&email=user@example.com&external_id=123`

Окружение

- Версия Discourse: (последняя)
- Размещение на собственном сервере

Предложения по возможному исправлению

1. Добавить настройку сайта, например `discourse_connect_provider_includes_email` (по умолчанию: true для обратной совместимости), чтобы контролировать, включается ли адрес электронной почты в ответ.
2. Или реализовать обратный вызов на основе POST вместо перенаправления 302 через GET, чтобы избежать записи URL в логи.

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [09.Март.2026 18:10:58 UTC](https://meta.discourse.org/t/security-privacy-concern-email-exposed-in-discourseconnect-provider-redirect-url/397980/2 "2026-03-09T18:10:58Z")

</div>

> [@JACK\_ZHANG](#):
>
> Затем этот email кодируется в Base64 и включается в URL перенаправления:  
> `https://target-site.com/callback?sso=<base64_payload>&sig=<hmac_signature>`
> 
> Декодирование полезной нагрузки Base64 раскрывает адрес электронной почты в открытом виде.

> [@JACK\_ZHANG](#):
>
> Или реализуйте обратный вызов на основе POST вместо перенаправления 302 через GET, чтобы избежать ведения журналов URL.

Разве это тоже не зашифровано с использованием общего секрета?

---

<div class="post-metadata">

### Author: ![JACK\_ZHANG](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jack_zhang/32/492350_2.png) [@JACK\_ZHANG](https://meta.discourse.org/u/JACK_ZHANG)
#### Post date: [09.Март.2026 18:17:57 UTC](https://meta.discourse.org/t/security-privacy-concern-email-exposed-in-discourseconnect-provider-redirect-url/397980/3 "2026-03-09T18:17:57Z")

</div>

Привет, Фалько,

HMAC-подпись гарантирует лишь то, что полезная нагрузка не была изменена — она не шифрует данные. Base64 — это кодирование, а не шифрование, поэтому любой может декодировать его и прочитать содержимое.

Суть проблемы в следующем: мы не хотим раскрывать ненужную информацию о пользователях (например, электронную почту) «сторонним сайтам, использующим Discourse для входа через SSO». Пользователи авторизуются только для того, чтобы подтвердить: «Я легитимный пользователь». Они не ожидают, что их электронная почта будет передана.

Подойдёт ли нам настройка сайта, позволяющая контролировать, возвращается ли электронная почта?

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [09.Март.2026 18:19:28 UTC](https://meta.discourse.org/t/security-privacy-concern-email-exposed-in-discourseconnect-provider-redirect-url/397980/4 "2026-03-09T18:19:28Z")

</div>

> [@JACK\_ZHANG](#):
>
> Основная проблема заключается в следующем: мы не хотим раскрывать ненужную информацию о пользователях (например, адрес электронной почты) «сторонним сайтам, использующим Discourse для входа через SSO». Пользователи авторизуются только для того, чтобы подтвердить: «Я легитимный пользователь» — они не ожидают, что их email будет передан.

Мне интересно, кто этот сторонний сервис, который реализовал наш пользовательский протокол SSO?

> [@JACK\_ZHANG](#):
>
> Будет ли приемлемо добавить настройку сайта для управления тем, возвращается ли email?

Я считаю, что это #pr-welcome, при условии, что это не будет включено по умолчанию, чтобы мы не сломали существующие сайты.

---

<div class="post-metadata">

### Author: ![JACK\_ZHANG](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jack_zhang/32/492350_2.png) [@JACK\_ZHANG](https://meta.discourse.org/u/JACK_ZHANG)
#### Post date: [09.Март.2026 18:27:00 UTC](https://meta.discourse.org/t/security-privacy-concern-email-exposed-in-discourseconnect-provider-redirect-url/397980/5 "2026-03-09T18:27:00Z")

</div>

Спасибо за обратную связь!

Чтобы дать вам контекст: наш форум является «кампусным форумом», и один из студентов создал бесплатный веб-сайт для использования другими студентами. Они хотят использовать наш форум на базе Discourse для подтверждения того, что пользователь действительно является студентом нашей школы — по сути, доказывая: «Я легитимный студент здесь».

В этом сценарии внешнему веб-сайту нужно лишь знать, что «это валидный пользователь нашего кампусного форума». Им не обязательно нужен email пользователя, так как это конфиденциальная информация, которой не следует делиться без необходимости.

Я займусь созданием PR, который добавит настройку сайта для управления этим поведением, с значением по умолчанию, обеспечивающим обратную совместимость для существующих установок.

---

<div class="post-metadata">

### Author: ![JACK\_ZHANG](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jack_zhang/32/492350_2.png) [@JACK\_ZHANG](https://meta.discourse.org/u/JACK_ZHANG)
#### Post date: [05.Май.2026 08:43:47 UTC](https://meta.discourse.org/t/security-privacy-concern-email-exposed-in-discourseconnect-provider-redirect-url/397980/6 "2026-05-05T08:43:47Z")

</div>

Вот ссылка на PR

> <https://github.com/discourse/discourse/pull/38382>
>
> Adds a new site setting \`discourse\_connect\_provider\_provides\_email\` (default: tr…ue) to control whether user email is included in the SSO redirect URL. This maintains backward compatibility while allowing admins to disable email exposure for privacy reasons.
> 
> See: https://meta.discourse.org/t/security-privacy-concern-email-exposed-in-discourseconnect-provider-redirect-url/397980