-
Notifications
You must be signed in to change notification settings - Fork 75
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
add per-ticket API authentication scheme #514
add per-ticket API authentication scheme #514
Conversation
80af5c3
to
d3f119e
Compare
38e6e8e
to
145d222
Compare
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 don't really have an opinion on this, but it is the policy of dcrstakepool to use naked returns as little as possible. I've marked all the naked return I saw with "Naked."
I have a few questions about this idea in general, but I want to get through #515 before I say anything.
@@ -16,6 +16,7 @@ import ( | |||
wallettypes "github.com/decred/dcrwallet/rpc/jsonrpc/types" | |||
|
|||
"github.com/decred/dcrd/rpcclient/v3" | |||
"github.com/decred/dcrd/txscript" |
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 think this should be using txscript/v2
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.
Using txscript/v2
will require using chaincfg/v2
, especially for AppContext.Params
(type *chaincfg.Params
) which will cause issues in other existing usages of AppContext.Params
.
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.
try /v2 again; dcrd has updated since.
string MultiSigAddress = 1; | ||
string VspFeeAddress = 2; | ||
string OwnerFeeAddress = 3; | ||
} |
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.
We might want to start tracking txids in the db, as we want to become more self-sufficient. Although I am aware that you want to reduce the communication between the db and stakepoold, because it is on another machine. A centralized area to track tickets is needed, imo. What do you think? It should be discussed somewhere... I'll make an issue after a little more thought.
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 not sure we can totally remove reliance on dcrwallet; unless that's possible and is something we're working towards, I'd prefer that where possible, we not store information that we can deduce by making 1 or 2 RPC calls. But you can open an issue for this and we can discuss it more and see what we can come up with.
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.
As I later commented below, this may be a good idea after all. I can proceed to implement in this PR if that's agreed.
5cf2dba
to
ff84b02
Compare
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.
rebase needed.
log.Errorf("GetTicketInfo: MsgTxFromHex failed for %v: %v", res.Hex, err) | ||
return nil, err | ||
} | ||
|
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.
missing check to verify tx is a vote.
@@ -16,6 +16,7 @@ import ( | |||
wallettypes "github.com/decred/dcrwallet/rpc/jsonrpc/types" | |||
|
|||
"github.com/decred/dcrd/rpcclient/v3" | |||
"github.com/decred/dcrd/txscript" |
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.
try /v2 again; dcrd has updated since.
system/api-auth.go
Outdated
"time" | ||
|
||
"github.com/decred/dcrd/dcrutil" | ||
"github.com/decred/dcrwallet/wallet" |
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.
try /v3 again, since its already used. post compile errors here or ask on matrix.
a166eef
to
0975667
Compare
f07943e
to
8672b4f
Compare
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.
Good to see you back at this! Left some comments.
I get a panic after this runs for a bit panic
|
I created a consumer for this api here: decred/tinydecred#121 |
1b6bd32
to
ae0e4ce
Compare
ae0e4ce
to
f5bbac5
Compare
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.
Looks good to me!
Works great. Is versatile and clients can choose to use it or not. I can't find any holes in the model.
If you could just up the stakepoold api version major to 10, I will approve.
Thanks for the review, mate.
Thinking a minor version bump will suffice? Since there are no backwards-incompatible changes introduced, just new functionality that is backward-compatible. |
Yeah? well ok. It does add a function to stakepoold that will cause dcrstakepoold to fail if it can't get a response, but if it's not something anyone is using yet, I suppose minor is fine. The more times I read the semver suggested usage the more I doubt myself. Minor is fine with me. |
Yeah... will also bump the dcrstakepool |
Closed in favour of #625 |
Current API routes are mounted on
/api/v1/*
and/api/v2/*
; and authentication is carried out by providing an API access token in theAuthorization
request header field in the format:Authorization: Bearer <api key>
.This PR adds a new API authentication scheme (
TicketAuth
) as an alternative to the currentBearer
auth scheme. The addedTicketAuth
scheme performs per-ticket authentication before executing requested actions on protected API endpoints such as/getpurchaseinfo
. It's worth mentioning that the new auth scheme works as expected with all existing API endpoints and the changes introduced in this PR do not break backwards compatibility.The new auth scheme uses the wallet built-in message signing capability and signs a msg which content is the current timestamp, allowing old msgs to be invalidated by the server so they are resistant to replay attacks.
The format for the
TicketAuth
scheme is:Authorization: TicketAuth SignedTimestamp=1564531200, Signature=frJIUN8DYpKDtOLCwo, TicketHash=591b17ed03afc916f274669939924e12ed5ac90d8cc602172fb53237b8a20522
Where;
This authorization header format matches that defined in RFC2617. See this SO answer.
User's ticket reward address
A ticket purchased with voting rights shared with a vsp has 2
sstxcommitment
outputs for receiving staking reward. One of these addresses belongs to the vsp wallet, while the other belongs to the ticket owner's wallet. This second address belonging to the ticket owner is what is used in preparing theSignature
passed in the authentication header as described above.Recovering redeem scripts for restored wallets
This ticket-level authentication makes recovering redeem scripts for restored wallets much easier. Instead of logging in to the vsp server to get the redeem script for a ticket or api key for an account, a client app can simply make an API request to
/getpurchaseinfo
using theTicketAuth
scheme to retrieve the redeem script for a ticket - provided the ticket was purchased with the vsp.Resolves #291. Part fix for #274 and decredcommunity/issues#100.