Token-storing off-server magic vault thing

[Undo1]

Details to come. @Undo1 write some stuff here in the morning.

[ArtOfCode-]

I've been vaguely thinking about this. The root of the problem here is that any such system will rely on having a data store/environment that you can insert to, but that you cannot retrieve from. I can't think of any of those off the top of my head.

[thesecretmaster]

The idea was a lambda + dynamodb IIRC

[Undo1]

Whoever runs it will probably be able to access them, but the benefit from moving tokens over would be a much-reduced attack surface. It'd be only a few web routes, no DB access from metasmoke (so no attack surface for database dumps), no automatic deploys, etc. No way for even MS deployers to ever get access, so definitely no way for attackers to get it.

tl;dr - u.api_token is pretty easy for anyone with even a bit of access to run. This wouldn't be.

[ArtOfCode-]

If whoever's hosting will probably still be able to access them, that makes it significantly easier. Two options come to mind:

• Lambda + DynamoDB
• YAUWS (Yet Another Unstable Web Service)

Guess which one's probably the sensible option :)

[thesecretmaster]

I've built a little thing for this. It's got three routes:

1. /auth, does SE oauth and stores token
2. /auth/complete, also a part of SE oauth
3. POST /autoflag, keyed, MS uses this to cast flags (returns the same as the api). Needs account_id, comment, flag_option_id, post_id, post_type, site
4. GET /autoflag/options, keyed, MS uses this to get flag options (returns the same as the api). Needs account_id, site, post_id, post_type.

I also wasn't sure if we used no_expiry tokens or not, so the ones for this beta do expire.

Beta instance up here: https://btmi925fb2.execute-api.us-east-1.amazonaws.com/default

[Undo1]

Wow, that was fast @thesecretmaster. We do use no_expiry (

metasmoke/app/helpers/authentication_helper.rb

Line 11 in 131d242

auth_url('write_access,no_expiry', config['redirect_uri'])

), it makes managing things easier.

[thesecretmaster]

@Undo1 Do we want to just move over, or think of a neat gradual moving procedure?