Rethink token scanning #86
Description
Based on @gregose's feedback in #81:
Another item would be to have someone commit an access token and have it revoked with the credential scanning feature... but thats a bit tricky to implement in a safe way. I'm not sure what we could do there. Maybe a dummy token we could scan for? @ptoomey3 (not part of this org yet) may have some ideas.
This is something we started with, but took out. The possible benefits would be:
- Raise awareness of token scanning as a feature
- Let people know they shouldn't be committing tokens
The reasons we decided to take them out are:
- For the flow to happen as a step, we would actually ask them to commit a token, which ultimately isn't a behavior we want users to do. In general, if a user shouldn't do it in every day life, we don't want them to practice it during a course
- When the token is added to a repository, the user who added the token isn't notified at all. The notifications (from what I understand) all take place on the other end, so that the service provider who owns that token will be the one notified, and the token can be revoked. To a user, it would be anticlimactic and we wouldn't see anything happen in reaction to that commit immediately
This is definitely still not a perfect case, because I think we could do a better job of talking about token scanning and tokens in general. Maybe some different verbage around the .gitignore? Or, if I've misunderstood how the alerts would be sent when a token is committed, maybe we should rethink this completely? I still worry about instructing a user to commit a dummy token, but we could have the bot do it, and have the user fix it.