Skip to content
Snippets Groups Projects
Select Git revision
  • renovate/cropperjs-2.x
  • weblate
  • develop default protected
  • renovate/sinon-chai-4.x
  • renovate/ruffle-rs-ruffle-0.x
  • renovate/node-22.x
  • renovate/eslint-plugin-vue-10.x
  • renovate/playwright-monorepo
  • sss-objects
  • real-vote-counts
  • audio-viz
  • emoji-pack-upload
  • tusooa/1222-in-reply-to
  • separate-admin-build
  • master protected
  • release/2.7.x
  • appearance-tab
  • cherry-pick-631c2532
  • 1289-button-text
  • release/2.6.x
  • 2.7.1
  • 2.7.0
  • 2.6.1
  • 2.6.0
  • 2.5.0
  • 2.4.2
  • 2.4.0
  • 2.3.0
  • 2.2.3
  • 2.2.2
  • 2.2.1
  • 2.2.0
  • 2.1.2
  • 2.1.1
  • 2.1.0
  • 2.0.5
  • 2.0.3
  • 2.0.2
  • 0.9.999
  • 0.9.99
40 results
Search by author
  • Any Author
  • Duponin Duponin Duponin
  • HJ HJ hj
  • Haelwenn Haelwenn lanodan
  • Sean King Sean King seanking
  • feld feld feld
  • href href href
  • lain lain lambadalambda
  • mkljczk mkljczk
  • **** project_1_bot_009dbc9f905582badff289f06f46865f
  • renovate-bot renovate-bot
  • tusooa tusooa tusooa
  • vaartis vaartis vaartis
  • weblate bot weblate-bot
13 authors
  1. Jan 09, 2022
  3. Dec 28, 2021
  5. Dec 12, 2021
    • Ilja's avatar
      Allow canceling a follow request · 4587f37d
      Ilja authored 
      When a follow request is sent, but not (yet) accepted, the behaviour is now to cancel the request instead of re sending.

The reason is double
* You couldn't cancel a follow request if you change your mind and the request wasn't answered yet
* Instances don't always correctly process a new follow request when the following is already happening. If something went wrong (e;g. the target server thinks you're following, but your instance thinks you're not yet), it's better to first sent an unfollow. This is the behaviour that Mastodon and most probably most other clients have. Therefore this flow is more tested and expected by other instances.
      4587f37d
  7. Dec 03, 2021
  9. Nov 16, 2021
    • HJ's avatar
      Merge branch 'fix/escape-display-name' into 'develop' · ea0887a1
      HJ authored 
      entity_normalizer: Escape name when parsing user

See merge request !1415
      ea0887a1
    • rinpatch's avatar
      entity_normalizer: Escape name when parsing user · d36b45ad
      rinpatch authored 
      In January 2020 Pleroma backend stopped escaping HTML in display names
and passed that responsibility on frontends, compliant with Mastodon's
version of Mastodon API [1]. Pleroma-FE was subsequently modified to
escape the display name [2], however only in the "name_html" field. This
was fine however, since that's what the code rendering display names used.

However, 2 months ago an MR [3] refactoring the way the frontend does emoji
and mention rendering was merged. One of the things it did was moving away
from doing emoji rendering in the entity normalizer and use the unescaped
'user.name' in the rendering code, resulting in HTML injection being
possible again.

This patch escapes 'user.name' as well, as far as I can tell there is no
actual use for an unescaped display name in frontend code, especially
when it comes from MastoAPI, where it is not supposed to be HTML.

[1]: !1052
[2]: pleroma!2167
[3]: !1392
      d36b45ad
  11. Sep 09, 2021
  13. Sep 07, 2021
  15. Sep 05, 2021
  17. Sep 02, 2021
  19. Aug 30, 2021