Skip to content

[pr] bugfix/bogus-quit-detected #3

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.

Sign up for GitHub

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

Merged
stephen-palmer merged 4 commits into from
Apr 13, 2018
Merged

[pr] bugfix/bogus-quit-detected #3

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
3c5eb20
- Fixed bug where a ‘q’ character is mis-interpreted as a quit comman…
stephen-palmer Apr 13, 2018
59d07c5
clarify code by using charCodeAt instead of the value
stephen-palmer Apr 13, 2018
49cde12
Add an additional ‘q’ char to the beginning of GUID
stephen-palmer Apr 13, 2018
f107896
simplifying an expression
stephen-palmer Apr 13, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion lib/server/client_stream_processor.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -122,7 +122,7 @@ class ClientStreamProcessor extends Transform {
if(!fillBufferWithData()) {

// Quit?
if (data[data.length - 1] === CMD_QUIT) {
if (!readState.didParseCmd && data[data.length - 1] === CMD_QUIT) {
Copy link

@pullrequest pullrequest bot Apr 13, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so just to clarify, the idea behind using the !readState.disParseCmd check first is that the q would always come at the start of the command, but not in subsequent characters? is it possible that this could still fail if the first character of the guid is a q?

Copy link
Owner Author

@stephen-palmer stephen-palmer Apr 13, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The real problem here is that the protocol should have made the QUIT command a 2 char length as well. So I think this is the best I can do - if a command (of a 2 char variety) is already parsed, then the QUIT command is effectively disabled until the state is reset. I think the only questionable assertion in this is if a 2 char command is not yet parsed, 'q' all by itself will signal a quit. The protocol tests seem really stable now, at any rate.

There might be an overall better way to architect this low level protocol parser to better encapsulate all of that logic .. I am loathe to re-write it at this point though :) suggestions welcome.

Copy link

@pullrequest pullrequest bot Apr 13, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha, yeah I can't really think of an easy solution given your point around needing 2 characters of data. I think your solution here is good and should help fix or at least make it much more rare to occur. Thanks for the info!

this.push('q');
}

Expand Down
5 changes: 5 additions & 0 deletions test/protocol.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -153,6 +153,11 @@ describe("Protocol", () => {

tests.forEach(function (test) {
it(`should store ${test.ext} data with a (${test.cmd}) command (client write packet size = ${test.packetSize})`, () => {
// Insert 'q' character ('Quit' command) into the GUID, to catch subtle protocol errors when packet size is 1
if(test.packetSize === 1) {
test.data.guid[0] = test.data.guid[test.data.guid.length - 1] = 'q'.charCodeAt(0);
}

const buf = Buffer.from(
encodeCommand(cmd.transactionStart, test.data.guid, test.data.hash) +
encodeCommand(test.cmd, null, null, test.data[test.ext]) +
Expand Down