-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Javascript: Improve Restify support and add new Spife support #10663
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
Conversation
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.
two quick comments from a quick read of the code.
The qldoc check is failing because you don't have a toplevel QLDoc in I think you should add a change-note to |
2ebba03
to
573cad4
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 great, just a few things I noticed from a first read through. I haven't done a detailed review and I'm not very familiar with these libraries so will need more time to digest this.
You have a few failing tests: |
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.
A lot of minor comments after a readthrough.
My suggestions will definitely cause the autoformatter to fail, so you need to run that.
reply.ref().(DataFlow::CallNode).getCalleeName() = | ||
["reply", "cookie", "link", "header", "headers", "raw", "status", "toStream", "vary"] and | ||
this = reply.ref().(DataFlow::CallNode).getArgument(0) and | ||
rh = reply.getRouteHandler() |
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.
Calling reply.ref()
two times gives you two different references, so you should only do that once here.
And I think you might have meant reply.ref().getAMethodCall(["reply", ...])
? (Similar to what I pointed out in CookieDefinition
).
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.
Thanks, will fix it!
TemplateObjectInput() { | ||
reply.ref().(DataFlow::MethodCallNode).getMethodName() = "template" and | ||
this = reply.ref().(DataFlow::MethodCallNode).getArgument(1) | ||
} |
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.
Don't call reply.ref()
twice, it gives two different references.
And I think this is right, I think you meant reply.ref().getAMethodCall("template")
. (Similar to what I pointed out in CookieDefinition).
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.
And there are also some other classes where you do eply.ref().(DataFlow::MethodCallNode)
.
Could you add tests for those so we are sure they are correct.
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.
Sure, thanks
RedirectInvocation() { | ||
this = reply.ref().(DataFlow::MethodCallNode) and | ||
this.getMethodName() = "redirect" | ||
} |
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.
Same as above.
exists(ReplySource reply | | ||
reply.ref().(DataFlow::MethodCallNode).getMethodName() = "template" and | ||
this = reply.ref() | ||
) |
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.
Same as above.
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 checked your test for this.
You have a call to reply.template(..)
in your tests, and on that you test for templateInstantiation
.
But your tests.ql
don't have a case for templateInstantiation
, so that is never tested.
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.
Nice, catch, thanks, will add it!
9d9efa6
to
e080d8f
Compare
reply.ref().(DataFlow::CallNode).getCalleeName() = | ||
["reply", "cookie", "link", "header", "headers", "raw", "status", "toStream", "vary"] and | ||
this = reply.ref().(DataFlow::CallNode).getArgument(0) and | ||
rh = reply.getRouteHandler() |
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.
Thanks, will fix it!
TemplateObjectInput() { | ||
reply.ref().(DataFlow::MethodCallNode).getMethodName() = "template" and | ||
this = reply.ref().(DataFlow::MethodCallNode).getArgument(1) | ||
} |
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.
Sure, thanks
exists(ReplySource reply | | ||
reply.ref().(DataFlow::MethodCallNode).getMethodName() = "template" and | ||
this = reply.ref() | ||
) |
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.
Nice, catch, thanks, will add it!
Co-authored-by: Erik Krogh Kristensen <erik-krogh@github.com>
e080d8f
to
b79f7f3
Compare
The qldoc check is complaining about missing documentation on |
Sorry I missed the notifications about the review comments. Will take a look ASAP |
Co-authored-by: Erik Krogh Kristensen <erik-krogh@github.com>
Thanks @erik-krogh I applied all suggestions, but had to revert 3 of them since there raised some ambiguity errors between parent types |
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.
Another round of comments.
Could you also do a merge with main
? your base-commit is getting old.
) | ||
} | ||
|
||
API::Node getHandlerByName(string name) { result = this.getParameter(0).getMember(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.
You also have to remove the rest of the uses of API::Node
in this class.
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.
@erik-krogh how would you rewrite this predicate? I thought about this result = this.getACallee().getParameter(0).(DataFlow::ObjectLiteralNode).getAPropertyRead(name)
but ObjectLiteralNode is not compatible with Parameter
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.
Just remove .(DataFlow::ObjectLiteralNode)
from your attempt and you should be good.
getAPropertyRead()
is defined on SourceNode
, and both ObjectLiteralNode
and ParameterNode
are SourceNode
s.
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.
Ok, I was not getting that option from the autocomplete menu, but I was missing a wrapping call to DataFlow::parameterNode()
Co-authored-by: Erik Krogh Kristensen <erik-krogh@github.com>
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.
One more comment, and then I think we're there.
I have done an evaluation, and that looks fine.
Co-authored-by: Erik Krogh Kristensen <erik-krogh@github.com>
You fixed the implementation in 4ba3190, but you didn't add any tests to match. Those tests can probably be added as inline test comments in |
Thought about adding some tests as you proposed but I thought it was already tested indirectly and we have plenty of tests for |
…odeql into restify_improvements
import semmle.javascript.heuristics.AdditionalRouteHandlers | ||
|
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.
import semmle.javascript.heuristics.AdditionalRouteHandlers |
This was the reason that your tests "worked" before the fix.
Your Spife::RouteSetup
and Spife::StandardRouteHandler
were effectively unused in your tests before the fix, because your tests don't distinguish between heuristic and non-heuristic route-handlers.
You have to distinguish between heuristic and non-heuristic, otherwise you're only testing the former.
You can try to delete Spife::StandardRouteHandler
, your tests still pass as they are right now.
You have a bunch of test failures when you delete this line, and I see three possible solution to that:
- Accept the new test output (including failures), to document that some things can only be detected using the heuristic route-handlers.
- Delete the tests lines are only detected by the heuristic route-handlers.
This is fine, our other heuristic route-handlers don't really have tests. - Add another test that tests the heuristic route-handlers.
(The above assumes that no other bug surfaces from this).
Sorry for figuring this out so late, but I didn't look that closely at your test implementations (or your tests).
import semmle.javascript.heuristics.AdditionalRouteHandlers | ||
|
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.
import semmle.javascript.heuristics.AdditionalRouteHandlers |
Same here.
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.
Lets get this merged.
I got a final confirmation evaluation running, but I'll do something if that doesn't turn out OK.
This PR improves Restify support and adds brand new support for Spife framework