Skip to content
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

Jump to bottom

Index creation requests can accept malformed mappings. #38266

Closed
jtibshirani opened this issue Feb 3, 2019 · 3 comments
Closed

Index creation requests can accept malformed mappings. #38266

jtibshirani opened this issue Feb 3, 2019 · 3 comments
Labels
>bug :Search Foundations/Mapping Index mappings, including merging and defining field types Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch

Comments

@jtibshirani
Copy link
Contributor

jtibshirani commented Feb 3, 2019 •
edited
Loading

CreateIndexRequest#source(Map<String, Object>, ... ), which is used when deserializing index creation requests, is too lenient and accidentally accepts mappings that are nested twice under the type key:

{
  "mappings": {
    "my_type": {
      "my_type": {
        "properties": { ... }
      }
    }
}

We will soon be trying to remove types completely from the server code, so it is likely not high-priority to fix. But it seemed worth filing an issue as the behavior is quite confusing and has lead to some surprising bugs when trying to introduce typeless create index requests.

The method PutIndexTemplateRequest#source has the same issue as well.
@jtibshirani jtibshirani added >bug :Search Foundations/Mapping Index mappings, including merging and defining field types :Data Management/Indices APIs APIs to create and manage indices and templates labels Feb 3, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search

@jtibshirani jtibshirani mentioned this issue Feb 3, 2019
Merged
jtibshirani added a commit that referenced this issue Feb 5, 2019
@jtibshirani
Make sure to reject mappings with type _doc when include_type_name is…
3ce7d2c 
… false. (#38270)

`CreateIndexRequest#source(Map<String, Object>, ... )`, which is used when
deserializing index creation requests, accidentally accepts mappings that are
nested twice under the type key (as described in the bug report #38266).

This in turn causes us to be too lenient in parsing typeless mappings. In
particular, we accept the following index creation request, even though it
should not contain the type key `_doc`:

```
PUT index?include_type_name=false
{
  "mappings": {
    "_doc": {
      "properties": { ... }
    }
  }
}
```

There is a similar issue for both 'put templates' and 'put mappings' requests
as well.

This PR makes the minimal changes to detect and reject these typed mappings in
requests. It does not address #38266 generally, or attempt a larger refactor
around types in these server-side requests, as I think this should be done at a
later time.
jtibshirani added a commit to jtibshirani/elasticsearch that referenced this issue Feb 6, 2019
@jtibshirani
Make sure to reject mappings with type _doc when include_type_name is…
f5403ca 
… false.

`CreateIndexRequest#source(Map<String, Object>, ... )`, which is used when
deserializing index creation requests, accidentally accepts mappings that are
nested twice under the type key (as described in the bug report elastic#38266).

This in turn causes us to be too lenient in parsing typeless mappings. In
particular, we accept the following index creation request, even though it
should not contain the type key `_doc`:

```
PUT index?include_type_name=false
{
  "mappings": {
    "_doc": {
      "properties": { ... }
    }
  }
}
```

There is a similar issue for both 'put templates' and 'put mappings' requests
as well.

This PR makes the minimal changes to detect and reject these typed mappings in
requests. It does not address elastic#38266 generally, or attempt a larger refactor
around types in these server-side requests, as I think this should be done at a
later time.
@jtibshirani jtibshirani mentioned this issue Feb 6, 2019
Merged
jtibshirani added a commit that referenced this issue Feb 6, 2019
@jtibshirani
Make sure to reject mappings with type _doc when include_type_name is…
fcdc509 
… false. (#38484)

`CreateIndexRequest#source(Map<String, Object>, ... )`, which is used when
deserializing index creation requests, accidentally accepts mappings that are
nested twice under the type key (as described in the bug report #38266).

This in turn causes us to be too lenient in parsing typeless mappings. In
particular, we accept the following index creation request, even though it
should not contain the type key `_doc`:

```
PUT index?include_type_name=false
{
  "mappings": {
    "_doc": {
      "properties": { ... }
    }
  }
}
```

There is a similar issue for both 'put templates' and 'put mappings' requests
as well.

This PR makes the minimal changes to detect and reject these typed mappings in
requests. It does not address #38266 generally, or attempt a larger refactor
around types in these server-side requests, as I think this should be done at a
later time.
@jtibshirani jtibshirani removed the :Data Management/Indices APIs APIs to create and manage indices and templates label Feb 9, 2019
@jtibshirani
Copy link
Contributor Author

Revisiting this issue, I think it can be addressed as part of our types removal work for 8.0 (#41059) and doesn't need a targeted fix. I'll close it out, as I don't think it's worth tracking on its own.

@jtibshirani jtibshirani mentioned this issue Aug 5, 2019
Merged
@jpountz jpountz mentioned this issue Aug 5, 2019
Closed
66 tasks
@pgomulka pgomulka mentioned this issue Mar 25, 2020
Closed
66 tasks
@javanna javanna added the Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch label Jul 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
>bug :Search Foundations/Mapping Index mappings, including merging and defining field types Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@javanna @jtibshirani @elasticmachine