Fix DOS when rendering issue/MR comments See merge request gitlab/gitlabhq!3152
Prior to https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29889, only the project context were set for the Markdown renderer. For a note on an issuable, the group context was set to `nil` because `note.noteable.try(:group)` attempted to get the issuable's group, which doesn't exist. To make group notifications work, now both the project and group context are set. The context gets passed to `RelativeLinkFilter`, which previously assumed that it wasn't possible to have both a group and a project in the Markdown context. However, if a group were defined, it would take precedence, and the URL rendered for uploads would be `/group/-/uploads` instead of `/group/project/uploads/`. This led to 404s in e-mails. However, now that we have both project and group in the context, we render the Markdown giving priority to the project context if is set. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/63910
If we put the emoji filter before the reference filters, each emoji will have a wrapper element that prevents the reference filter from detecting the presence of the emoji. As the emoji filter now runs after the reference filters, references must contain a literal emoji, not the GitLab Flavored Markdown versions (:100`, for example). A weird side-effect is that if you have a label with the 100 emoji, and a label named :100:, then trying to reference the latter will work (link to the correct label), but will render with the 100 emoji. I'm comfortable with that edge case, I think.
This allows using `CacheMarkdownField` for models that are not backed by ActiveRecord. When the including class inherits `ActiveRecord::Base` we include `Gitlab::MarkdownCache::ActiveRecord::Extension`. This will cause the markdown fields to be rendered and the generated HTML stored in a `<field>_html` attribute on the record. We also store the version used for generating the markdown. All other classes that include this model will include the `Gitlab::MarkdownCache::Redis::Extension`. This add the `<field>_html` attributes to that model and will generate the html in them. The generated HTML will be cached in redis under the key `markdown_cache:<class>:<id>`. The class this included in must therefore respond to `id`.
Reject slug+uri concat if slug is deemed unsafe See merge request gitlab/gitlabhq!3108
Fix url redaction for issue links See merge request gitlab/gitlabhq!3091
First reported: https://gitlab.com/gitlab-org/gitlab-ce/issues/60143 When the page slug is "javascript:" and we attempt to link to a relative path (using `.` or `..`) the code will concatenate the slug and the uri. This MR adds a guard to that concat step that will return `nil` if the incoming slug matches against any of the "unsafe" slug regexes; currently this is only for the slug "javascript:" but can be extended if needed. Manually tested against a non-exhaustive list from OWASP of common javascript XSS exploits that have to to with mangling the "javascript:" method, and all are caught by this change or by existing code that ingests the user-specified slug.