Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Please add a token for the blob's fingerprint.
It could be used as the node's URL.
A weakness in Drupal is that by default it uses an implementation-specific datum for identifying nodes, i.e the NID. Creating the URLs based on intrinsic data of the content, such as publishing date or a UUID is preferred. A token for the blob's fingerprint can facilitate this.
Comments
Comment #1
miglius commentedWell, I'm not sure about it. While blob's fingerprint allows uniquely identify the file, but the access control is done at the nodes layer. The same file can be saved several times and will be internally referenced by the same hash, but the access authentication will still be done based on the node's nid. If we expose only the hash in the url (with or without tokens) and there are several nodes (the same file is uploaded several times by different users) related to the same file, then we will have no way to distinguish them.
Comment #2
agharbeia commentedOf course.
Since the blob's fingerprint is a content-hash then what you're describing is likely to happen.
But if the fingerprint was a UUID, i.e. incorporating some other vector in addition to the file's content, then it would be safe.
Maybe it would be a good idea to have both. The hash for content comparison and validation, and UUID for differentiating an instance.
Comment #3
miglius commentedIf we would use a NID to generate an UUID, then why this new identifier would be better than a just NID?
Comment #4
Arto commentedBitcache is inherently about content-addressable identifiers, so that will not get changed to use UUIDs.
However, your suggestion about UUIDs in general is a good one, and as it happens, it looks like somebody has started a project that does just that: http://drupal.org/project/uuid
That module will give you UUIDs not just for file nodes but for all nodes - all the better. You could perhaps open an issue with that project to request the maintainer add Token module support. If you do, I will certainly chime in with a "yes, please".
Comment #5
Arto commentedComment #6
agharbeia commentedI just did that.
Comment #7
agharbeia commentedWell, for one thing, UUIDs have fixed width, which makes them better for indexing. They are cleaner-looking permalinks. Also, they don't impose upper-limit issues - no matter how theoretical - as do the serial NIDs.
Since a part of a UUID is a content hash, it could serve for content-addressing as well, provided that the other part is not a NID, but rather always known (domain?)
NIDs are bound to the database and are not intrinsic to the content, but are introduced by the system, which isn't bad in its own, but it would be great if we could do without them.
There's another issue here, however, which is the relationship between a Drupal node and - say - a photo file which is represented by this node.
Comment #8
Arto commentedGreat, I added a +1 in there. Meanwhile, I'm moving this issue over to the Bitcache project. I probably will eventually implement the token hooks in Bitcache, too; however, the UUID support will be better for your purposes, as Bitcache's support for Token wouldn't extend to nodes for the reasons Miglius mentioned above.
Comment #9
Arto commented