<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=599766) </details> <!--IssueSummary end--> <!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary **I do not have an account on https://gitlab.gnome.org/** yet I can construct a Mastondon verification URL as per the [documentation](https://docs.gitlab.com/user/profile/#add-a-mastodon-handle) which is indistinguisable from one constructed by someone who *does*. {width=592 height=238} Note that, unlike `https://github.com/rjw57`, adding my Mastodon profile to my GitLab profile does not allow `https://gitlab.com/rjw57` to be verified which is, I think, the intended behaviour for Mastodon verification. So Mastodon verification in its current form is either misleading or worthless in that - anyone can construct a verified URL on any public instance (misleading) and - the verified URL doesn't in any way relate to any user on the GitLab instance (worthless). The MR which introduced this feature (!164006) even has a video showing that the user does not actually end up with their `https://gitlab.com/{user}` URL being verified. <!-- Summarize the bug encountered concisely. --> ### Steps to reproduce 1. URL encode your Mastodon (or other fediverse) profile URL, e.g. `https%3A%2F%2Fmastodon.social%2F%40richwareham`. 2. Select any GitLab instance which you do not have an account on, e.g. https://gitlab.gnome.org/. 3. Construct the URL `https://{instance}/-/external_redirect?rel=me&url={profile}`. E.g. `https://gitlab.gnome.org/-/external_redirect?rel=me&url=https%3A%2F%2Fmastodon.social%2F%40richwareham` 4. Follow the [GitLab documentation](https://docs.gitlab.com/user/profile/#add-a-mastodon-handle) to add that verification URL to your Mastodon profile. 5. Your Mastodon account is verified in a manner indistinguishable from that of a legitimate user which followed the [GitLab documentation](https://docs.gitlab.com/user/profile/#add-a-mastodon-handle). <!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. --> ### Example Project N/A <!-- If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report. If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version. --> ### What is the current *bug* behavior? <!-- Describe what actually happens. --> Mastodon has a conceptually simple approach to verification. If you say "my profile on site X is https://somesite.invalid/username" and that URL has a `link` or `a` tag somewhere on the page with `rel="me"` set and which points back to the mastodon profile, the link is decorated with a green tick. In this manner I verify on my mastodon profile that said profile matches `https://github/rjw57`. GitLab claims in [the documentation](https://docs.gitlab.com/user/profile/#add-a-mastodon-handle) that Mastodon verification is possible. But one cannot verify `https://gitlab.com/{user}` and the URL which one *can* verify says nothing about which GitLab user it relates to. To re-state: anyone may construct a URL for a public instance which appears to verify their Mastodon handle irrespective of whether they have an account on the instance. This is the approach encouraged by the current documentation. This is a "null" verification in that it merely verifies that the external redirect to a mastodon profile does indeed redirect to the profile. It says nothing about whether any particular user on an instance has claimed to be associated with the mastodon profile. It looks like some attempt has been made to allow the "correct" behaviour of having `https://gitlab.com/{user}` be verified since the HTML source contains the `me` tag in `rel`, e.g.: ```html <a class="gl-text-default" title="Mastodon" target="_blank" rel="noopener noreferrer nofollow me" <!-- <= note the "me" here --> href="/-/external_redirect?rel=me&amp;url=https%3A%2F%2Fmastodon.social%2F%40richwareham"> @richwareham@mastodon.social </a> ``` However the target of the `a` tag is not the mastodon profile itself but is the external redirect URL mentioned before. So, in summary: * One cannot verify the user-specific URL which one *wants* to verify, `https://gitlab.com/{user}`. * One can only verify the generic `external_redirect` URL which will happily verify _any_ Mastodon profile and is not specific to any user. This doesn't appear to be an attempt at restricting GitLab users from having arbitrary `href` targets for `a` tags either. I can set an arbitrary URL for my website, for example, which appears on the profile page, also with the `me` value set for `rel`: ```html <a class="gl-text-default" target="_blank" rel="me noopener noreferrer nofollow" itemprop="url" href="https://richwareham.com/"> richwareham.com/ </a> ``` So, for example, if I set my _personal_ webpage to `https://mastodon.social/@richwareham`, I can then verify `https://gitlab.com/rjw57`, but I also have to have `https://mastodon.social/@richwareham` set as my webpage and, confusingly _not_, my mastodon handle. {width=310 height=78} ### What is the expected *correct* behavior? <!-- Describe what you should see instead. --> If a user adds a mastodon profile to their user profile, they should be able to verify, e.g., `https://gitlab.com/{user}` on their mastodon profile. It should work _identically_ to the current "personal website" field. Just as I can provide any URL and cause `https://gitlab.com/{user}` to have an `a` tag with `rel="me"` and `href` pointing to the site, adding a mastodon site should do the same. If one does not want to have user-controlled URL available for the mastodon link in particular, one could also, _in addition to the current `a` tag_ have: ```html <link rel="me" href="https://mastodon.social/@richwareham" /> ``` ### Relevant logs and/or screenshots N/A beyond the screenshots above. <!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise. --> ### Output of checks <!-- If you are reporting a bug on GitLab.com, uncomment below --> This bug happens on GitLab.com <!-- and uncomment below if you have /label privileges --> <!-- /label ~"reproduced on GitLab.com" --> <!-- or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not --> #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`) </pre> </details> #### Results of GitLab application Check <!-- Input any relevant GitLab application check information if needed. --> <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:check SANITIZE=true`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`) (we will only investigate if the tests are passing) </pre> </details> ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> One of: * Add a `<link>` tag to the [sidebar template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/views/users/_profile_sidebar.html.haml#L77) containing the full mastodon profile URL. * Remove `external_redirect_path` from the [mastodon_url helper function](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/helpers/application_helper.rb#L391). ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->