console: prevent constructing console methods by Hakerh400 · Pull Request #26096 · nodejs/node (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation19 Commits1 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Ref: #25987
This PR defined all console methods (except the ones intended for internal use) as methods rather than constructible functions. It prevents constructing methods of console instance, except for the global console (opened as separate PR as per #25987 (comment)).
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes- tests and/or benchmarks are included
- commit message follows commit guidelines
Can you add a test?
Also, I don't think the current patch fixes the issue for the global console, as all console methods are wrapped using consoleCall
unconditionally, so to fix the global console, the FunctionTemplate
for that method in inspector::Initialize
needs to use v8::ConstructorBehavior::kThrow
.
env->SetMethod(target, "consoleCall", InspectorConsoleCall); |
---|
env->SetMethod( |
Can you add a test?
Sure.
Also, I don't think the current patch fixes the issue for the global console
It's mentioned in the PR description: "It prevents constructing methods of console instance, except for the global console". Please read the relevant discussion in #25987. I will open separate PR for ConstructorBehavior::kThrow
, since it affect many other things.
It's mentioned in the PR description: "It prevents constructing methods of console instance, except for the global console".
Sorry for not reading the PR description carefully *_*
I will open separate PR for
ConstructorBehavior::kThrow
, since it affect many other things.
https://github.com/Hakerh400/node/commit/f084076963c7cdb0dbdcf8ad281c557021f50fc1 affects many other things because the behavior change is done in env-inl.h
which gets reused by other internal code - I don't think we can simply replace that wholesale though, that could break a lot of hidden use cases. You can fix the console call without affecting others by manually instantiating a FunctionTemplate
in inspector::Initialize
instead of using env-SetMethod
Thanks. Applied the suggestion & added a test.
const v8::NewStringType type = v8::NewStringType::kInternalized; |
---|
v8::Localv8::String name_string = |
v8::String::NewFromUtf8(env->isolate(), "consoleCall", type) |
.ToLocalChecked(); |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could probably use FIXED_ONE_BYTE_STRING
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe an env.h string?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added FIXED_ONE_BYTE_STRING
for consistency with conn_str
from inspector::Initialize
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with a nit
}; |
---|
for (const method of Reflect.ownKeys(consoleMethods)) |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you put this near the end of the file and keep most of the implementation closer to where they used to be to preserve more git blame history?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added two new lines to align some diffs. All methods are in the same order as before, but console.table
pretty much destroys the rest. Not sure if that is fixable.
Rebased and resolved the conflict that has just appeared.
BTW, is anything pending here? This PR has been open for two weeks...
addaleax added the author ready
PRs that have at least one approval, no pending requests for changes, and a CI started.
label
Landed in e9ed6b9, thanks for the PR! 🎉
addaleax pushed a commit that referenced this pull request
Ref: #25987
PR-URL: #26096 Refs: #25987 Reviewed-By: Joyee Cheung joyeec9h3@gmail.com Reviewed-By: Gabriel Schulhof gabriel.schulhof@intel.com
Should this be backported to v11.x-staging
? If yes please follow the guide and raise a backport PR, if not let me know or add the dont-land-on
label.
Should this be backported to v11.x-staging?
To whom the question is directed? If the general opinion is biased towards backporting, I'll open PR.
BridgeAR pushed a commit that referenced this pull request
Ref: #25987
PR-URL: #26096 Refs: #25987 Reviewed-By: Joyee Cheung joyeec9h3@gmail.com Reviewed-By: Gabriel Schulhof gabriel.schulhof@intel.com
I backported this directly to the staging branch.
@Hakerh400 most of the time the person who originally opened the PR is also the best to backport it and to judge if it makes sense to backport something. But anybody could come along and just do that, so it's a generic question about how people feel about backporting something.
Labels
PRs that have at least one approval, no pending requests for changes, and a CI started.
Issues and PRs related to the console subsystem.