Add GitHub signup oracle #41
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "feature/github-signup"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This adds a GitHub oauth signup oracle that allows users to create a new contributor profile through a oauth verification.
hubot implements an API and the oracle to create the contributor. The frontend is handled by kredits-web.
Flow:
kredits web -> reditects to on hubot:
/kredits/signup/github/connect/github
-> user gets redirected to github -> redirected to kredits web with access token -> API call to hubot POST/kredits/signup/github
to create the contributor.I finished the implementation. This should all work together with 67P/kredits-web#142 now.
When creating the Github OAuth app, the Authorization callback URL should be the base URL of HAL8000 (e.g. http://localhost:8888 for development).
When starting HAL8000, set the following new ENV vars:
GITHUB_KEY
GITHUB_SECRET
KREDITS_WEB_URL
(http://localhost:4200 for development)I haven't tested the actual creation of the contributor yet (i.e. this part), because I don't have a full local Kredits contracts setup yet. For testing, I just added the
contributorAttr
object to the response and logged it in Kredits Web.@ -175,0 +219,4 @@
headers: {
'Accept': 'application/vnd.github.v3+json',
'Authorization': `token ${accessToken}`
}
why don't you directly reditect to kredits-web? - using the grant callback option?
@ -175,0 +219,4 @@
headers: {
'Accept': 'application/vnd.github.v3+json',
'Authorization': `token ${accessToken}`
}
That first redirect should go to the backend server, because that one only contains a (temporary) code that you can then use together with the client secret to exchange it for the actual access token. But you shouldn't put the client secret in a client-side web app.
@ -175,0 +219,4 @@
headers: {
'Accept': 'application/vnd.github.v3+json',
'Authorization': `token ${accessToken}`
}
Also, the endpoint to retrieve the access token using the code and client secret (POST https://github.com/login/oauth/access_token) doesn't have CORS headers, so requests from Web apps wouldn't work.
Noice! Added some code comments and questions.
I think we need to define the signup paths here, if we don't want to apply these things to all hubot routes.
This function could easily go in its own file.
I think default options should be set at the top of the file instead of directly in a router function.
Why JSON? Shouldn't
sendStatus(200)
be enough?@ -175,0 +246,4 @@
contributorAttr.github_username = user.login;
contributorAttr.github_uid = user.id;
kredits.Contributor.add(contributorAttr, { gasLimit: 350000 })
Would be useful to know from where and how the contributor was added exactly. We use the
[hubot-kredits]
prefix in the other files. And could add something like "Contributor added from GitHub signup".However, creating the contributor needs to be separated from the GitHub hook, because in order to create a more complete profile, we should be able to add more accounts before creating the contributor on chain. This is important, because the bot shouldn't have permission to update hashes afterwards, only to create new contributor records.
Splitting that out can be done in a future PR, of course, but maybe it makes sense to at least split out the functionality from the route already.
@ -16,0 +16,4 @@
"express": "^4.17.1",
"express-session": "^1.16.2",
"grant-express": "^4.6.1",
"group-array": "^1.0.0",
Why do we have to import express, when hubot comes with express by default?
I used
status(200)
without the JSON, but that didn't work. I'll givesendStatus(200)
a try.@ -16,0 +16,4 @@
"express": "^4.17.1",
"express-session": "^1.16.2",
"grant-express": "^4.6.1",
"group-array": "^1.0.0",
Whoops, that's a leftover of something I tried to fix a problem.
Yeah,
status
only sets the status, but doesn't send a response by itself.@ -16,0 +16,4 @@
"express": "^4.17.1",
"express-session": "^1.16.2",
"grant-express": "^4.6.1",
"group-array": "^1.0.0",
Correction: when removing that line, I actually get an error when starting HAL8000
Found a better solution using a middleware. With that it was easy to just add the CORS headers to the routes that need it.
Done
@ -175,0 +246,4 @@
contributorAttr.github_username = user.login;
contributorAttr.github_uid = user.id;
kredits.Contributor.add(contributorAttr, { gasLimit: 350000 })
I changed the log message. But apart from adding the CORS headers I didn't work on the signup route itself. So I don't know exactly how or what to split out. Maybe @bumi can jump in here?
Did anybody try this out yet?
I have just successfully tried this, until the screen that asks for an ETH address, I stopped there because my local kredits-web couldn't be configured to use my local chain (https://github.com/67P/kredits-web#3-kredits-web)
I had to generate a wallet and copy it to my test hubot's root and set
addresses: { Kernel: '0x... }
in index.js for hubot to startThose docs are wrong or outdated.
npm run start:local
always uses the local contracts, but you need to always setKREDITS_KERNEL_ADDRESS
to the DAO address that you can show inkredits-contracts
by runningnpm run dao:address
.Yes, hubot-kredits needs a wallet that is allowed to create contributors in your local contracts. That part is missing entirely from the instructions here, unless I missed it.
Also, I think we still have to hardcode the local DAO address in its code, unless I missed that as well.
It would be extremely useful if the authors of this PR had actually tested it from end to end themselves.
I merged support for setting the local DAO address via the
KREDITS_DAO_ADDRESS
env var into this branch, making it much easier to test.I had to add the
gasLimit
option to theContributor.add
method, similar to what kredits-web is doing. Otherwise I would get this error when trying to create a new contributor:With the
gasLimit
option it works now.Unfortunately, I get the following error from the callback loading:
@galfert @bumi Sure this shouldn't be a
kredits-3
by now?(Btw, I don't want kredits for my commits. Was just drive-by fixing stuff in my review and mostly doing the Web part of this.)
Oh, and I think this is good to merge, right?
Yes, you're right. I changed the label.
I think we are good to go.
need to add more documentation, then we merge.
I added an issue for it. We can wait with tagging the release until the new feature is documented properly.