but work in body text &

  • Cosmicomical@kbin.social
    link
    fedilink
    arrow-up
    0
    arrow-down
    1
    ·
    1 year ago

    That’s the problem, then. You shouldn’t store entities in the db, the table is likely already utf8, which supports all characters

    • Max-P@lemmy.max-p.me
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      I think 0.19 is reverting that behaviour, because it was indeed a certified bad idea.

      I think the idea was to attempt to bulletproof potentially crappy clients especially after the XSS incident, but the problem is it’s simply not even always rendered in a web context which makes the processing kind of a pain.

      Wouldn’t surprise me if it becomes double and triple encoded too at times because of the federation. Do you encode again or trust that the remote sent you urlencoded data already?

      Best format is the original format and transform as late as possible, ideally in clients where there’s awareness of what characters are special. It is in web, not so much in an Android or terminal app.

      I don’t think the Lemmy devs are particularly experienced web developers in general. There’s been a fair amount of dubious API design decisions like passing auth as a GET parameter… Thankfully they also fixed that one in 0.19.

      • Cosmicomical@kbin.social
        link
        fedilink
        arrow-up
        0
        arrow-down
        1
        ·
        1 year ago

        Sorry for the late reply, it’s been a week… but yeah passing creds in the Get is very bad for multiple reasons. For instance if you pass the creds on a page that contains ads or trackers, they are probably going to store the url AND your credentials and propagate them to a million systems of third parties. That’s. Not. Good.