Currently we don’t support UUID on SQL databases (yet) nor do we support Int IDs on MongoDB, we did have this feature but it was removed before we went stable and do plan to take another look in Q3. The reason for this was due to a lot of refactoring required within the code base to remove hard coded type checks (Int vs string).
Currently, we will try to adjust some code within your codebase to integrate with our current database model. I hope that you can finish the code refactoring in Q3 following your release plan so that we can upgrade to the very clean code version of Strapi.
It would be great, if this feature is implemented on the next releases, having the flexability to change the current incremental auto generated unique ID…
I believe it’s in the plans just not for the initial release of the v4. Once we get that first release out the door we can start evaluating the time and complexity required to do something like this (as I would like to see it added as well)
No not at this time and not that I know of in the near to medium term future. You’ll likely never be able to get rid of the unique auto-incremented ID within Strapi but you can add other fields to use for filtering/ect. We internally use those auto-increment IDs for many features that are not optional.
I am not an expert in API designs, however, it feels like incremental id’s are a bad idea in an authenticated setting, users might just be able to change an id (to the next incremental value) and view information that they were not meant to see. I am sure you have probably thought of this, hence, is there a better design pattern I should employ? if so, could you give a brief example for completeness.
you would normally block your content behind authorization (example: Bearer token) so only allowed users could fetch data.
Or you could add custom route that would accept only uuid input and then return only data that is connected to that uuid
Thanks for your response @WardenCommander. The latter is a good workaround. However, does this not cause inefficiencies in the database? Where the user now has to search for a uuid (potentially across multiple tables) that is not indexed and optimised for searching, such as an id column.
over 1000’s of rows, limited db resources and potentially concurrent users, this adds up? Throwing more compute power at the problem is not cost effective.
I am not an expert in API designs, however, it feels like incremental id’s are a bad idea in an authenticated setting, users might just be able to change an id (to the next incremental value) and view information that they were not meant to see. I am sure you have probably thought of this, hence, is there a better design pattern I should employ? if so, could you give a brief example for completeness.
It’s not something you should employ on it’s own (or at all generally lol), if users should not be able to see something then you should implement proper security controls to prevent them from doing so such as route policies or conditional access, ect.
All of this is possible within Strapi, there is nothing wrong with incremental IDs other than size limits in certain databases which is a technical challenge that will not impact many.
For example the maximum signed id value in most SQL databases is 2,147,483,647 or unsigned is 4,294,967,295. In certain cases an ObjectID or UID would be better but not required.
Another good example of this is changing the SSH port on a Linux server from 22 to something else like say 2022 or 8022. It does absolutely nothing to help secure your server at all, it just makes it harder for novices to find it but a advanced engineer or bot will easily find it in seconds.
If you really don’t want to show IDs on something, write a route middleware that will loop through the response and delete the id field from the response before it’s sent. Shouldn’t impact performance too much.
There is also another workaround, you could essentially force the id into strapi. Using post request you can fill the id with the generated id e.g.Math.floor(Date.now()*Math.random()). There is just one issue. You have to check for error 500 on the post request. If you do this for small numbers, that you would eventually incrementally reach, you can brick the admin UI. You will get a server error when you are saving a file because strapi will just try to save at the next value it hasn’t used before. I strongly don’t recommend this but at this time I don’t see any other way to obscure the API endpoints.