[BUG] Scripted fields with the name "constructor" cause issues

[jgough]

I am unable to create a scripted field with the name constructor.

On 1.3.2 I get the error "Script is invalid. View script preview for details". If I view the script preview then I get the error "Object contains forbidden prototype property". If I change the scripted field name to anything else then it works as expected.

On 2.0.0 I can create a scripted field called constructor, but if I view an object on the Discover tab then the object value is function Object() { [native code] }, and not the value of the scripted field.

To Reproduce
Steps to reproduce the behavior:

1. Go to Stack Management -> Index Patterns and select an index pattern
2. Click Scripted fields -> Add scripted field
3. Under Name type constructor
4. Under Script type return true
5. Click Create field

On 1.3.2: The error "Script is invalid" is returned
On 2.0.0: Click the Discover tab to view a document in this index and look at the value of the scripted field.

Expected behavior
Expected to be able to save and use a scripted field with the name constructor

OpenSearch Version
1.3.2 and 2.0.0

Dashboards Version
1.3.2 and 2.0.0

Screenshots
1.3.2:

2.0.0:

Host/Environment (please complete the following information):

• Docker
• Firefox 91.10.0esr

[joshuarrrr]

@jgough Thanks for the detailed reproduction steps, I reproduced the 2.0 behavior.

Is it actually necessary to support constructor (or any other reserved string) as a valid field name? Or do you think it would also be sufficient to have proper validation in the scripted field form that makes sure names don't collide with reserved property names?

[jgough]

I personally feel it's not essential to support it, but it seems odd that the code is done in a way that means some field names just aren't permitted here. What other reserved property names might cause collisions here? It would at least be good to give a warning when trying to use a reserved name.

I stumbled across this one by accident, genuinely trying to use that as a field name. Took a while to figure out what was going on and that I didn't have a bug in my script! A warning would have helped here.

[joshuarrrr]

Oh, yeah, I totally agree that it's an annoying and surprising bug. Whichever way we go, we'll want to solve for all currently reserved properties or names (because I also suspect that there are others).

[kavilla]

[Triage]: We should do the validation and prevent this.

[ZilongX]

Do we have an ECD for fixing this bug ?

[kavilla]

Hey @ZilongX, the current plan for this is to prevent users from setting a reserve word. It might still fail for existing items.

[ZilongX]

Thanks @kavilla , do we have a detailed list of reserved words or maybe a regex checking that customer should avoid using ?

[AMoo-Miki]

To me, it sounds like OpenSearch should ultimately validate and not accept these and if OpenSearch accepts them, Dashboards should honor them.

While it would be nice for Dashboards to do validations too, I don't think it fits the long-term plans.

[kavilla]

I have created a PR that we can backport to 1.x branch, however the second part of this issue I believe we can create another issue. It would appear it is more so a bug (along with other bugs) in the Discover window that prevents certain code from performing as expected. As we are targeted to rewrite the Discover page due to it being in Angular I believe we should create a separate issue to track this bug. Wdyt @ananzh

[ananzh]

I have created a PR that we can backport to 1.x branch, however the second part of this issue I believe we can create another issue. It would appear it is more so a bug (along with other bugs) in the Discover window that prevents certain code from performing as expected. As we are targeted to rewrite the Discover page due to it being in Angular I believe we should create a separate issue to track this bug. Wdyt @ananzh

I tagged it with discover. We will keep it open. Is this okay?