Tip for generating a direct URL to an entity

So I was doing something like the JavaScript below for generating a URL to an entity, which when clicked opens the entity in a new tab…

function makeEntityUrl(spaceDb, entityName, entityPubId) {
  const entity = entityName.replace(/[^\d\w_\-!$*()+',.]+/g, "-") + `-${entityPubId}`;
  return `https://test-sandbox.fibery.io/${spaceDb.replace(" ", "_")}/${entity}`;
}

But during testing just now it seems like you don’t even need to include the entity name so this works just as well (as far as I can tell without extensive testing):

/**
 * @param spaceDb - in format 'space/database'
 * @param entityPubId - the public ID, a number
 */
function makeEntityUrl(spaceDb, entityPubId) {
  return `https://test-sandbox.fibery.io/${spaceDb.replace(" ", "_")}/${entityPubId}`;
}

const r = makeEntityUrl('Example Space/Database A', 2)
console.log(r) // https://test-sandbox.fibery.io/Example_Space/Database_A/2
1 Like

Entity Id is enough, since you can rename the entity and URL has to work

1 Like

Indeed - there should be one unique ID facing the public (i.e. URLs).

I just wonder that fibery is exposing the sequential IDs.

The issue is that it demonstrates some context.

In some projects we used internal IDs (could be sequential ints) and assigned “public” IDs (uuids).

By that we solved - non exposing ID context and always working URLs.

Might be a suggestion for improvement?

I’m curious to know what sensitive info you think is exposed by having sequential identifiers?
Given that they are not re-used, it doesn’t tell you how many entities exist in a given database (since 101 might be created and 100 deleted).
It doesn’t tell you when they were created (in date/time terms) although you can deduce that one entity was created after another.

Typically business related stuff. In those cases you do not delete the previous entries, you change their status as closed or irrelevant.
Hence you expose the amount when someone tries to reach the top number.

Additional advantage of UUIDs is that you do not need to add entity name into the URL. It can be like:
company.fibery.io/e/6ad4e412-270f-4278-a5c3-d9ed0179c328

And thus the URL always works even when you rename the space (app) , folder, move the entity among spaces, etc.

I am not saying replace the context aware URLs (those are for some visual and browser tab completion convenience), I am saying for the links sharing - UUIDs are better.

I’m not sure I understand what you mean by ‘reaching the top number’. Are you saying that users can deduce the total number of entities in a given database?
That is not quite the case, as I said, since it only tells you how many have been created todate, and not how many are actually in use.
If that bothers you, then you can randomly create a whole bunch of dummy entities and immediately delete them to obfuscate this information(!)

FYI, the Fibery URLs for entities do not actually need the name, as Dimitri points out above.

Also, because of the way UUIDs are formed, they actually reveal more info than the public ID :frowning:

FYI, the Fibery URLs for entities do not actually need the name, as Dimitri points out above.

Apologies I misplaced entity and database in the Fibery terms.

Also, because of the way UUIDs are formed, they actually reveal more info than the public ID :frowning:

I am not sure what you are referring to in relation to UUID v4.

1 Like

Ah, sorry, I had a recollection that it was UUID v1 in use.

So to wrap it: Just imagine these differences as to be seen during screensharing within online calls etc:

https://company.fibery.io/B2BRealtions/PotentialClients/4

vs

http://company.fibery.io/e/6ad4e412-270f-4278-a5c3-d9ed0179c328

So it’s the space name/database name that is particularly sensitive, more so than the entity id?
It wouldn’t be so bad if it showed the following, right?

https://company.fibery.io/af3d5/98eb2/4

That is one positive.

The other is as mentioned:

Additional advantage of UUIDs is that you do not need to add space/database name into the URL. It can be like:
company.fibery.io/e/6ad4e412-270f-4278-a5c3-d9ed0179c328

And thus the URL always works even when you rename the space (app) , folder, move the entity among spaces, etc.