Skip to content
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 missing REST endpoints for SignMessage and VerifyMessage #2148

Merged
merged 1 commit into from Dec 4, 2018

Conversation

Projects
None yet
3 participants
@xsb
Copy link
Contributor

commented Nov 4, 2018

Fixes #2096

rpc VerifyMessage (VerifyMessageRequest) returns (VerifyMessageResponse);
rpc VerifyMessage (VerifyMessageRequest) returns (VerifyMessageResponse) {
option (google.api.http) = {
post: "/v1/verifymessage"

This comment has been minimized.

Copy link
@Roasbeef

Roasbeef Nov 5, 2018

Member

Perhaps this should be a GET instead as it doesn't mutate any state, doesn't produce anything new, and is also a stateless operation?

This comment has been minimized.

Copy link
@xsb

xsb Nov 5, 2018

Author Contributor

Both SignMessage and VerifyMessage could in theory be implemented as GET. Problem is, as GET requests are not supposed to have a body this implies the message needs to go in the URL. Which produces potentially very long URLs and in certain scenarios the user could find limits on the size of the message that can be passed to these functions. What do you think?

This comment has been minimized.

Copy link
@xsb

xsb Nov 5, 2018

Author Contributor

Thinking more about it, URL size limits are defined in clients not servers, and afaik only old browsers are problematic in that sense. So I guess this is not a real issue? I'd prefer to use the correct http verb here but I am just not 100% sure it's not an issue to pass messages in URLs.

This comment has been minimized.

Copy link
@xsb

xsb Nov 12, 2018

Author Contributor

@Roasbeef I can make it a GET but I have a question. The field msg is of type bytes. Should I change it to string instead as it needs to be passed through a URL? Looks like that would break other stuff.

This comment has been minimized.

Copy link
@wpaulino

wpaulino Nov 12, 2018

Collaborator

bytes fields are encoded as base64 strings, but they're not URL safe, so perhaps it's better to keep it as a POST? Either that or we can note that the base64 string should be padded so that it's URL safe (https://stackoverflow.com/questions/1374753/passing-base64-encoded-strings-in-url), but this isn't very user friendly IMO.

@wpaulino

This comment has been minimized.

Copy link
Collaborator

commented Nov 12, 2018

Needs a rebase!

@xsb xsb force-pushed the xsb:rest-endpoints branch from 6251123 to f9df845 Nov 12, 2018

@xsb xsb force-pushed the xsb:rest-endpoints branch from f9df845 to ebc34a9 Nov 12, 2018

@xsb

This comment has been minimized.

Copy link
Contributor Author

commented Nov 12, 2018

@wpaulino rebased

@Roasbeef
Copy link
Member

left a comment

LGTM 🔑

@Roasbeef Roasbeef merged commit 127bc71 into lightningnetwork:master Dec 4, 2018

1 of 2 checks passed

coverage/coveralls Coverage decreased (-0.006%) to 55.901%
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.