What is the reason the source_topic_id that is added to internal oneboxes?

Support
1

In a private site I am noticing that internal links are mangled with the addition of ?source_topic_id=XYZ

  • Why does this happen?

  • How can I disable?

5 Likes
2

A link to OP on CURRENT topic

https://meta.discourse.org/t/what-is-the-reason-the-source-topic-id-that-is-added-to-internal-oneboxes/71722

A link to OP on a different topic

https://meta.discourse.org/t/inconsistent-onebox-rendering/70788

https://meta.discourse.org/t/inconsistent-onebox-rendering/70788

3

A link to a NON OP post in the current topic

https://meta.discourse.org/t/what-is-the-reason-the-source-topic-id-that-is-added-to-internal-oneboxes/71722/2

A link to a NON OP post in a DIFFERENT topic

https://meta.discourse.org/t/inconsistent-onebox-rendering/70788/2
https://meta.discourse.org/t/inconsistent-onebox-rendering/70788/2

4

The onebox engine uses the URL as a key for the cache, it is responsible for generating the onebox.

The URL mangling exists to ensure that the cache key for the onebox is distinct when you link off topic posts vs on topic posts. If it was not distinct we would be forced to render the above the same way. (and the title “inconsistent onebox rendering” would not show up on @codinghorror’s link)

We (I) added the ?source_topic_id param to every internal link prior to the onebox engine attempting to resolve. This allows for the fix above.

Unfortunately as a BIG side effect, if you do not have permission to see a topic or post the cooked markdown is already changed :frowning: so you see an ugly ?source_topic_id

https://meta.discourse.org/t/lets-see-if-i-can-repro-this-onebox-image-issues/70901/13

The situation is not ideal, there are some possible improvements we could make

  1. Stop using onebox engine to render internal links

  2. Amend onebox engine cache to key on BOTH url AND another secret key if provided

  3. Figure out if we can feed in a change that only amends the href but leaves the title as it used to be. (possibly revert cooked on onebox miss)

  4. (worst solution) render every onebox the same regardless of it being in the OP or not

There is no trivial fix here for now.

5 Likes
5

Thanks for explaining this. I thought it was a configuration error on my end.

Unfortunately as a BIG side effect, if you do not have permission to see a topic or post…

Actually, the issue applies to cross posting any links between private categories even if you DO have permission on both categories.

One workaround is just build the links with the editor or markdown if you cant live with the ugly ish link. Fair enough. Oneboxing private categories is a potential security issue.

6

This is where it gets tricky.

Say you have permission to the topic but later on someone edits your post and does not have permission to the topic you linked to? User breaks your onebox?

7

I have this issue too after the upgrade to beta 13.

I can understand that a link to a topic in a private category linked to a public category not become onebox (no preview, no excerpt, if a user click on it he see the warning message that that topic is private).

In the same way I can understand that a link from a private category (X) posted in a private category (Z) not become onebox because the 2 private categories have different permissions

But I don’t understand why a link from the private category X posted in another topic of the Y category remains with ?source_topic_id=XYZ appended IF both categories have the same permissions

…and regardless of all these types of links are really ugly… :speak_no_evil:

4 Likes
11

This source topic id stuff is now gone thanks to @zogstrip!

https://github.com/discourse/discourse/commit/f028ffaf29d871c54d3a50e25cae077e0ed7c591

5 Likes