@Glorfindel Allow me to provide some trivial: Sir Patrick Steward (aka. Captain Picard/Professor X/world renowned Shakespeare actor), will voice the poop emoji in the upcoming Emoji movie
@Undo no, self-rolled. Needed to backup sqlite3 in the end, not mysql, so I sorta copied and patched from the one you linked and wrote some terrible bash and hoped it worked
I think I got the script itself working, actually, but cron refuses to run or something
I'm running a service with ~300 write-authenticated access tokens. It's terrifying.
As part of running such a service, I'd like to be able to cycle API tokens - so that if, heaven forbid, one makes an escape attempt and wasn't caught, it'd only be valid for a minimal period of time.
/access-tok...
@Undo Not disagreeing with you, but my guess is that's the answer. What you are asking for doesn't accomplish a whole lot from SE's point of view. If you've been compromised once, either you are still compromised, can be recompromised or are safe. I'm guessing the default assumption isn't "Oh they are safe now"
Resetting the tokens doesn't help in outcomes 1 and 2
Here's the real world example: When giving a dump to @ArtOfCode, it'd be great to be able to refresh tokens after zipping up the dump and before making it public, and be 100% insulated from any kind of leak that could come from that.
@ArtOfCode The solution in this case is to invalidate and force the user to retrust you, not to allow you - who were just compromised - to regenerate the password for me
@ArtOfCode Reseting tokens doesn't solve that though. The token resetting is just something that has to occur. Whether through invalidate/explicit reauth or automated reset. The problem that has to be fixed is how the tokens were compromised
Resetting tokens does solve that issue, though. I probably don't know your password, but you should go change it now just in case I do. The tokens Undo's holding probably aren't compromised, but it'd be nice to be able to change the lot at once just in case they are.
But, by allowing a dev to reset a token, it allows them to hide potential compromises. "Oh, if we're compromised, I just reset everything." That's good...but it doesn't force you to think about the next step - securing it in the future.
Yeah. It provides an extra layer of security for while you're not being compromised, but it potentially limits security improvements because you don't have to tell everyone why they have to re-auth and trust you again.
I suppose we're talking about the different levels of trust we give developers. I figure that if a developer isn't trustworthy enough to invalidate instead of reset, they may not be trustworthy enough to invalidate at all
Uncaught SyntaxError: Unexpected token o in JSON at position 1
at JSON.parse (<anonymous>)
at Array.socketOnMessage (eval at <anonymous> (:1:1), <anonymous>:789:25)
at WebSocket.conn.onmessage (charcoal-se.org/userscripts/metapi.js?v=0.3.8:2:372)
Well that got me a bunch of info. So, @Cerb, thisis what you think it is - the FIRE button. $(this).data("report") is undefined when your call to openReportPopup fires. Don't know why. On the other (JSON) bug: at least one trigger is the feedback messages.
I'm running a service with ~300 write-authenticated access tokens. It's terrifying.
As part of running such a service, I'd like to be able to cycle API tokens - so that if, heaven forbid, one makes an escape attempt and wasn't caught, it'd only be valid for a minimal period of time.
/access-tok...
