In redacting an API key from a post (link for SO mods and employees), I found a nice obscure bug. At the start, revision history looked like this:

The first revision contains the API key that I wanted to redact. Here's the chain of events I went through:

  1. Redact revision #1 using the standard procedure (and got it approved)

  2. Looked at the post after the redaction was approved. The API key was still present in the post as displayed on the site.

  3. Redacted revision #2, and received the automatic redaction screen with expected contents. I accepted that, but the redaction diff in the redaction approval flag was blank and couldn't be approved.

    I'm guessing this was because the tag-only edit doesn't actually store the body of the post, but the automatic redaction tool assumes it does.

  4. Retracted the redaction for revision #2

  5. Started to edit the post (using the normal edit link from the post page). At this point, the markdown box showed the properly redacted API key.

  6. Made a trivial change and reverted it within the grace period.

  7. Post body is rendered as properly redacted.

I'm guessing that this is a simple optimization gone awry. I'd bet that the current redaction code tries to be clever and only re-renders the post if the latest revision is redacted. This mostly works. In this case, though, the revision that controls the body of the post wasn't the most recent.

Since redactions are relatively rare, could we just re-render the post after any redaction is approved?

  • 4
    See, this is why I like folks to edit out the information first. Well, that and it means I can just copy their work instead of having to worry about missing it. – Shog9 Jan 16 '19 at 3:02

You must log in to answer this question.

Browse other questions tagged .