You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Prevent new documents from having the _id_index, either by rejecting those documents, or mapping the string _index to another internally managed string. Affected apis: createDocumentbulkDocuments
when a retrieveDocument request arrives, either reject the lookup for _index or map the string similar to aforementioned mapping
IF the mapping approach is taken, the document's _id would need to be reverse mapped back to the string _index on any retrievals. Affected apis: retrieveDocument, listDocuments, queryDocuments
add a test case for each
The easier of the two is just to reject any documents with an _id set to _index, but is arguably leaking impl details to the consumer.
So something I discovered today that probably should not be allowed?
If I have a hyper data service, I can retrieve all of the indexes that exist on the database by calling GET /data/default/_index. This gets handled by the "get document by id" route, which calls retrieveDocument on the adapter.
Ultimately the CouchDB adapter does:
asyncFetch(`${config.origin}/${db}/${id}`,...)
with _indexas the id.
Of course, there isn't a document with _id _index, BUT that does map to the route on the CouchDB API that lists all of the indexes for the DB: https://docs.couchdb.org/en/stable/api/database/find.html#get--db-_index. And since the data port says anything can be returned from the retrieveDocument API, hyper simply returns that response and you get something like:
We would need to:
_id
_index
, either by rejecting those documents, or mapping the string_index
to another internally managed string. Affected apis:createDocument
bulkDocuments
retrieveDocument
request arrives, either reject the lookup for_index
or map the string similar to aforementioned mapping_id
would need to be reverse mapped back to the string_index
on any retrievals. Affected apis:retrieveDocument
,listDocuments
,queryDocuments
The easier of the two is just to reject any documents with an
_id
set to_index
, but is arguably leaking impl details to the consumer.Background
Related Issue: hyper63/hyper#486
So something I discovered today that probably should not be allowed?
If I have a hyper data service, I can retrieve all of the indexes that exist on the database by calling
GET /data/default/_index
. This gets handled by the "get document by id" route, which callsretrieveDocument
on the adapter.Ultimately the CouchDB adapter does:
with
_index
as the id.Of course, there isn't a document with _id _index, BUT that does map to the route on the CouchDB API that lists all of the indexes for the DB: https://docs.couchdb.org/en/stable/api/database/find.html#get--db-_index. And since the data port says anything can be returned from the
retrieveDocument
API, hyper simply returns that response and you get something like:The text was updated successfully, but these errors were encountered: