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.

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

id field is ObjectID #5

Open
benbarclay opened this issue Dec 11, 2013 · 4 comments
Open

id field is ObjectID #5

benbarclay opened this issue Dec 11, 2013 · 4 comments
Assignees

Comments

@benbarclay
Copy link

Did an update form an older version of fortune-mongodb to the latest version, and it appears that there has been a backwards incompatible(ish) change that the ID field returned in objects from the adapter is the raw ObjectID type from the DB. Previously the ID was cast to a string before the application consumed it.

@ghost ghost assigned gr0uch Dec 11, 2013
@jlcarvalho
Copy link

In the new version the following code ids.map((id)=>new ObjectID(id)) should fix this.

@gr0uch gr0uch closed this as completed May 31, 2015
@harryjubb
Copy link

I am not sure but think something similar is still happening. I am getting very odd URLs for documents in JSON-API responses:

"links": {
    "self": "/db_collection/_bsontype,ObjectID,id,V%C3%8B%3Dru%C3%9B%22%C2%98%C3%98%C3%9C%C2%A6%C2%B2,toHexString,function%20()%20%7B%0A%20%20if(ObjectID.cacheHexString%20%26%26%20this.__id)%20return%20this.__id%3B%0A%0A%20%20var%20hexString%20%3D%20''%3B%0A%0A%20%20for%20(var%20i%20%3D%200%3B%20i%20%3C%20this.id.length%3B%20i%2B%2B)%20%7B%0A%20%20%20%20hexString%20%2B%3D%20hexTable%5Bthis.id.charCodeAt(i)%5D%3B%0A%20%20%7D%0A%0A%20%20if(ObjectID.cacheHexString)%20this.__id%20%3D%20hexString%3B%0A%20%20return%20hexString%3B%0A%7D,get_inc,function%20()%20%7B%0A%20%20return%20ObjectID.index%20%3D%20(ObjectID.index%20%2B%201)%20%25%200xFFFFFF%3B%0A%7D,getInc,function%20()%20%7B%0A%20%20return%20this.get_inc()%3B%0A%7D,generate,function%20(time)%20%7B%0A%20%20if%20('number'%20%21%3D%20typeof%20time)%20%7B%0A%20%20%20%20time%20%3D%20parseInt(Date.now()%2F1000%2C10)%3B%0A%20%20%7D%0A%0A%20%20var%20time4Bytes%20%3D%20BinaryParser.encodeInt(time%2C%2032%2C%20true%2C%20true)%3B%0A%20%20%2F*%20for%20time-based%20ObjectID%20the%20bytes%20following%20the%20time%20will%20be%20zeroed%20*%2F%0A%20%20var%20machine3Bytes%20%3D%20BinaryParser.encodeInt(MACHINE_ID%2C%2024%2C%20false)%3B%0A%20%20var%20pid2Bytes%20%3D%20BinaryParser.fromShort((typeof%20process%20%3D%3D%3D%20'undefined'%20%3F%20Math.floor(Math.random()%20*%20100000)%20%3A%20process.pid)%20%25%200xFFFF)%3B%0A%20%20var%20index3Bytes%20%3D%20BinaryParser.encodeInt(this.get_inc()%2C%2024%2C%20false%2C%20true)%3B%0A%0A%20%20return%20time4Bytes%20%2B%20machine3Bytes%20%2B%20pid2Bytes%20%2B%20index3Bytes%3B%0A%7D,toString,function%20()%20%7B%0A%20%20return%20this.toHexString()%3B%0A%7D,inspect,function%20()%20%7B%0A%20%20return%20this.toHexString()%3B%0A%7D,toJSON,function%20()%20%7B%0A%20%20return%20this.toHexString()%3B%0A%7D,equals,function%20equals(otherID)%20%7B%0A%20%20var%20id%3B%0A%0A%20%20if(otherID%20%21%3D%20null%20%26%26%20(otherID%20instanceof%20ObjectID%20%7C%7C%20otherID.toHexString))%20%7B%0A%20%20%20%20id%20%3D%20otherID.id%3B%0A%20%20%7D%20else%20if(typeof%20otherID%20%3D%3D%20'string'%20%26%26%20ObjectID.isValid(otherID))%20%7B%0A%20%20%20%20id%20%3D%20ObjectID.createFromHexString(otherID).id%3B%0A%20%20%7D%20else%20%7B%0A%20%20%20%20return%20false%3B%0A%20%20%7D%0A%0A%20%20return%20this.id%20%3D%3D%3D%20id%3B%0A%7D,getTimestamp,function%20()%20%7B%0A%20%20var%20timestamp%20%3D%20new%20Date()%3B%0A%20%20timestamp.setTime(Math.floor(BinaryParser.decodeInt(this.id.substring(0%2C4)%2C%2032%2C%20true%2C%20true))%20*%201000)%3B%0A%20%20return%20timestamp%3B%0A%7D,generationTime,1456160114"
  }
}

@gr0uch
Copy link
Member

gr0uch commented Mar 1, 2016

It seems that this adapter doesn't work correctly with ObjectIDs, so I'll re-open this issue. I'm always curious why people use this, since they leak the creation time of the document which may be bad for security reasons.

@gr0uch gr0uch reopened this Mar 1, 2016
@myartsev
Copy link

I'm always curious why people use this, since they leak the creation time of the document which may be bad for security reasons.

It's the default and recommended way of setting IDs in MongoDB, so it's not an unreasonable assumption that people are going to use it. Plus there are storage & performance tradeoffs in using ObjectIDs.

True, the creation time could be a security issue but just as well it could be a wanted feature. Or it could be of no concern at all. It's dependent on the application under development. A general purpose library like this shouldn't be making that decision.

Anyhow - just a +1 to get ObjectIDs working!

myartsev pushed a commit to myartsev/fortune-mongodb that referenced this issue Sep 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants