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 }})

Hakerh400

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

@joyeecheung

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(

@Hakerh400

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.

@joyeecheung

@Hakerh400

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

@Hakerh400

Thanks. Applied the suggestion & added a test.

jdalton

TimothyGu

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

joyeecheung

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.

gabrielschulhof

@Hakerh400

@Hakerh400

Rebased and resolved the conflict that has just appeared.
BTW, is anything pending here? This PR has been open for two weeks...

@addaleax

@addaleax addaleax added the author ready

PRs that have at least one approval, no pending requests for changes, and a CI started.

label

Mar 1, 2019

@addaleax

Landed in e9ed6b9, thanks for the PR! 🎉

addaleax pushed a commit that referenced this pull request

Mar 1, 2019

@Hakerh400 @addaleax

Ref: #25987

PR-URL: #26096 Refs: #25987 Reviewed-By: Joyee Cheung joyeec9h3@gmail.com Reviewed-By: Gabriel Schulhof gabriel.schulhof@intel.com

@addaleax

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.

@Hakerh400

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

Mar 4, 2019

@Hakerh400 @BridgeAR

Ref: #25987

PR-URL: #26096 Refs: #25987 Reviewed-By: Joyee Cheung joyeec9h3@gmail.com Reviewed-By: Gabriel Schulhof gabriel.schulhof@intel.com

@BridgeAR

I backported this directly to the staging branch.

@BridgeAR

@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

author ready

PRs that have at least one approval, no pending requests for changes, and a CI started.

console

Issues and PRs related to the console subsystem.