`/place` queries have been executing in a way where only the ID, but not
the layer, has been considered when returning records from
Elasticsearch.
It turns out this bug was introduced almost a year and a half ago in
https://github.com/pelias/api/pull/407. A little, relatively unimportant
bit of code was looking for a property called `layers`:
```
const cmd = req.clean.ids.map( function(id) {
return {
_index: apiConfig.indexName,
_type: id.layers,
_id: id.id
};
});
```
The correct property was `layer`, so no filtering on layer was done in
the resulting [mget](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-multi-get.html) query.
There was never an acceptance test for these sorts of queries, but there
is now one in https://github.com/pelias/acceptance-tests/pull/446. The
unit tests were enforcing the incorrect behavior.
Fixes https://github.com/pelias/pelias/issues/643
This header is only relevant if dealing with authentication via cookies
or other methods in HTTP requests. The Pelias API intentionally doesn't
deal with authentication at all, assuming anyone who wants
authentication will deal with it using a service placed between Pelias
and end users.
Additionally the CORS spec [does not allow](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Credentialed_requests_and_wildcards)
specifying this header while setting a wildcard for
`Access-Control-Allow-Origin`, so it can cause problems in some cases.
Fixes https://github.com/pelias/api/issues/971