Skip to content
  • Hjem
  • Seneste
  • Etiketter
  • Populære
  • Verden
  • Bruger
  • Grupper
Temaer
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Kollaps
FARVEL BIG TECH
  1. Forside
  2. Ikke-kategoriseret
  3. I had a dumb thing in my #ActivityPub implementation.

I had a dumb thing in my #ActivityPub implementation.

Planlagt Fastgjort Låst Flyttet Ikke-kategoriseret
activitypub
2 Indlæg 2 Posters 0 Visninger
  • Ældste til nyeste
  • Nyeste til ældste
  • Most Votes
Svar
  • Svar som emne
Login for at svare
Denne tråd er blevet slettet. Kun brugere med emne behandlings privilegier kan se den.
  • squinky@teh.entar.netS This user is from outside of this forum
    squinky@teh.entar.netS This user is from outside of this forum
    squinky@teh.entar.net
    wrote sidst redigeret af
    #1

    I had a dumb thing in my #ActivityPub implementation.

    I was getting these broadcast Delete announcements tied to Person objects from servers out in the wild, and was dutifully trying to validate their signatures. I didn't have the key here, and they're signed by the deleted Person, so loading the key gave a 404.

    So the next thing it tried to do was see if loading the Person remotely gave a 404, and if so, it's a legitimate Delete, problem solved.

    But what I think was happening was that the attempt to load the Key, then the attempt to load the Person, both flagged the remote server "hey this guy doesn't know about the Delete", and it received another copy of the Delete action. It's possible each Delete caused two copies of itself to get re-queued. Holy forkbomb.

    So I stuck a little bit at the top of Delete validation that checks to see if I have the target object, and chucks the message in the bin if not. This was in my original implementation but got lost when I did some refactoring.

    It sat for an hour, just processing THOUSANDS of backed up Delete messages.

    julian@community.nodebb.orgJ 1 Reply Last reply
    0
    • squinky@teh.entar.netS squinky@teh.entar.net

      I had a dumb thing in my #ActivityPub implementation.

      I was getting these broadcast Delete announcements tied to Person objects from servers out in the wild, and was dutifully trying to validate their signatures. I didn't have the key here, and they're signed by the deleted Person, so loading the key gave a 404.

      So the next thing it tried to do was see if loading the Person remotely gave a 404, and if so, it's a legitimate Delete, problem solved.

      But what I think was happening was that the attempt to load the Key, then the attempt to load the Person, both flagged the remote server "hey this guy doesn't know about the Delete", and it received another copy of the Delete action. It's possible each Delete caused two copies of itself to get re-queued. Holy forkbomb.

      So I stuck a little bit at the top of Delete validation that checks to see if I have the target object, and chucks the message in the bin if not. This was in my original implementation but got lost when I did some refactoring.

      It sat for an hour, just processing THOUSANDS of backed up Delete messages.

      julian@community.nodebb.orgJ This user is from outside of this forum
      julian@community.nodebb.orgJ This user is from outside of this forum
      julian@community.nodebb.org
      wrote sidst redigeret af
      #2

      squinky@teh.entar.net oh god that sounds nuts… also a weird sort of thing for the other server to do isn’t it. Seems like just sending the message once would be enough!

      1 Reply Last reply
      0
      Svar
      • Svar som emne
      Login for at svare
      • Ældste til nyeste
      • Nyeste til ældste
      • Most Votes


      • Log ind

      • Har du ikke en konto? Tilmeld

      • Login or register to search.
      Powered by NodeBB Contributors
      Graciously hosted by data.coop
      • First post
        Last post
      0
      • Hjem
      • Seneste
      • Etiketter
      • Populære
      • Verden
      • Bruger
      • Grupper