# Usuários fora dos grupos permitidos de postagens de mídia incorporada podem ignorar a restrição de upload copiando o link da imagem carregada

**URL:** https://meta.discourse.org/t/users-not-in-embedded-media-post-allowed-groups-can-bypass-upload-restriction-by-copying-the-uploaded-image-link/387368
**Category:** Bug
**Created:** [1 Novembro , 2025 22:54 UTC](https://meta.discourse.org/t/users-not-in-embedded-media-post-allowed-groups-can-bypass-upload-restriction-by-copying-the-uploaded-image-link/387368 "2025-11-01T22:54:46Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![copymonopoly](https://avatars.discourse-cdn.com/v4/letter/c/4491bb/32.png) [@copymonopoly](https://meta.discourse.org/u/copymonopoly)
#### Post date: [1 Novembro , 2025 22:54 UTC](https://meta.discourse.org/t/users-not-in-embedded-media-post-allowed-groups-can-bypass-upload-restriction-by-copying-the-uploaded-image-link/387368/1 "2025-11-01T22:54:46Z")

</div>

### Passos para Reproduzir

1. **Defina `Newuser max embedded media` = 0**

- Isso **impede corretamente que novos usuários façam upload de imagens antes de enviá-las** ✅

1. **Configure `Embedded media post allowed groups`**

- Exclua certos grupos da lista de permissões
- Quando um usuário **não nos grupos permitidos** faz o upload de uma imagem:
  - A imagem pode **aparecer no editor**
  - **Somente ao enviar a postagem** ela é bloqueada ❌

1. **Problema**

- Durante a edição, o usuário pode **copiar o link da imagem enviada** para contornar a restrição de upload e publicá-la

### Comportamento Esperado

Nosso objetivo é impedir que os usuários façam upload de imagens. Usuários que não estão nos grupos permitidos não devem conseguir inserir nenhuma mídia incorporada no editor — o upload deve ser bloqueado no momento do upload, assim como quando `Newuser max embedded media = 0` é aplicado.

Caso contrário, eles podem copiar o link da imagem enviada e efetivamente contornar a restrição para enviá-la.

---

<div class="post-metadata">

### Author: ![unknown\_error](https://avatars.discourse-cdn.com/v4/letter/u/df705f/32.png) [@unknown\_error](https://meta.discourse.org/u/unknown_error)
#### Post date: [29 Dezembro , 2025 18:30 UTC](https://meta.discourse.org/t/users-not-in-embedded-media-post-allowed-groups-can-bypass-upload-restriction-by-copying-the-uploaded-image-link/387368/2 "2025-12-29T18:30:04Z")

</div>

Não sei se este é um problema novo, mas nós também acabamos de notar:

> **[Uploaded image in the Pluribus thread](https://boards.straightdope.com/t/uploaded-image-in-the-pluribus-thread/1026146/2)**
>
> Uploaded image in the Pluribus thread - About This Message Board - Straight Dope Message Board - December 29 @ 10-23-35 AM@2x|690x293 Whoa, weird! Turns out you actually can upload here, you just can’t embed the upload… but if you paste the...

Parece que o upload da imagem para o _bucket_ S3 (`cdck-file-uploads-global.s3.dualstack.us-west-2.amazonaws.com`) acontece assim que a imagem é colada. A verificação de incorporação (_embed check_) só ocorre quando a postagem é enviada, mas nesse momento a imagem já existe no _bucket_ e pode ser vinculada por qualquer um dos seguintes:

- Seu URL S3
- Seu URL curto do Discourse
- Seu URL gerado `upload://` (ou seja, simplesmente removendo o `!` do início do código de incorporação de upload gerado automaticamente)

Estou preocupado que isso signifique que até mesmo as incorporações falhas (ou seja, _uploads_ tentados que foram subsequentemente negados) foram carregadas no _bucket_ e estão secretamente contando para a cota de armazenamento do site **mesmo que o remetente tenha pensado que foi negado e mais ninguém possa ver o _upload_**.

---

<div class="post-metadata">

### Author: ![copymonopoly](https://avatars.discourse-cdn.com/v4/letter/c/4491bb/32.png) [@copymonopoly](https://meta.discourse.org/u/copymonopoly)
#### Post date: [14 Janeiro , 2026 06:03 UTC](https://meta.discourse.org/t/users-not-in-embedded-media-post-allowed-groups-can-bypass-upload-restriction-by-copying-the-uploaded-image-link/387368/5 "2026-01-14T06:03:58Z")

</div>

Infelizmente, este bug parece ter permanecido sem correção por um bom tempo.
