-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite and test Github auth logic, separating standard and search quota #1205
Rewrite and test Github auth logic, separating standard and search quota #1205
Conversation
# Conflicts: # lib/github-auth.js # package-lock.json # package.json # server.js
# Conflicts: # package-lock.json # package.json
# Conflicts: # package-lock.json
# Conflicts: # lib/github-auth.js
# Conflicts: # lib/github-auth.js # package-lock.json # package.json # server.js
I'm eager to get this shipped, though I'm hesitant to do it until I get access to logs… |
lib/github-auth/acceptor.js
Outdated
})); | ||
} | ||
|
||
function constEq(a, b) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm new to node in general but why not use crypto.timingSafeEqual(a, b) instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't write this, just moved it. Yes, happy to switch that over. It seems like that solves the same problem.
This was designed as part of a rewrite of the Github auth code in #1205 which is stalled because I don't want to deploy it without access to server logs. The need for token rotation came up recently in #541, so I picked up this code, removed the github-specific bits, and pulled it in. Ordinarily I wouldn't merge helper code without a use, though sadly it seems like the best way to move forward this rewrite.
Since we have access to errors through Sentry, I think I will revive this and see if we can't nudge it forward. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little over half way through, but figured I'd go ahead and share my current thoughts/questions
@@ -23,21 +22,28 @@ class FsTokenPersistence extends TokenPersistence { | |||
} | |||
|
|||
const tokens = JSON.parse(contents) | |||
tokens.forEach(tokenString => { | |||
githubAuth.addGithubToken(tokenString) | |||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My first time looking at this part of the code, but it looks like this change here decouples this persistence engine from github specifics, which creates the possibility of this being reusable for other services?
I've no idea if there's a similar need in other services, but 👍 either way!
expected.push(newToken) | ||
|
||
await persistence.initialize() | ||
githubAuth.addGithubToken(newToken) | ||
await persistence.noteTokenAdded(newToken) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i know that the function name noteTokenAdded
here wasn't something modified in this PR, but it felt a little strange to me. seeing this for the first time I wasn't clear what exactly the function does from the name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we change it to add()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I'd vote for add()
or addToken()
(and definitely add()
if we can/will add things other than tokens)
I've made it through my first pass and added some inline comments. Although beware, there are more questions for my own understanding than there is useful feedback for you 😁 |
Avoiding knowledge bottlenecks is fully half of why we do this :) |
I think this is good to go, will do another pass here in a bit and approve |
body: { shieldsSecret: fakeShieldsSecret, token: fakeAccessToken }, | ||
}) | ||
|
||
expect(onTokenAccepted).to.have.been.calledWith(fakeAccessToken) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was a herculean effort! ✨ 🎉 👏
It looks good to me as is, only pending comment was the potential rename of noteTokenAdded
function to add
, but that's not a blocker
Thanks so much! Will be glad to close this out… and see if it really works. Let’s one of us tackle the renames in a follow-on. |
I'll merge and deploy this in the afternoon when we get past peak usage time, in case anything breaks. |
The TokenProvider abstraction was refactored away during #1205 and is now obsolete. Other users of token pooling should use TokenPool and TokenPersistence directly.
The TokenProvider abstraction was refactored away during #1205 and is now obsolete. Other users of token pooling should use TokenPool and TokenPersistence directly.
Summary:
Todo:
lib/github-auth.js
To handle in follow on work:
Token