github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-08-22 12:12:18 -05:00
Code Issues 690 Packages Projects Releases 13 Wiki Activity

[GH-ISSUE #476] Use random IDs instead of autoinc #6169

New Issue
Closed
opened 2026-04-20 16:46:39 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-04-20 16:46:39 -05:00
Owner
Copy Link
Copy Source

Originally created by @vikunja-bot on GitHub (Apr 1, 2025).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/476

Original issue by aksdb on 2021-01-24T10:48:25.000Z

Autoincrementing IDs give away usage information (how actively a system is used; how many tasks were created between two points in time, for example) and make it easier to exploit possible security problems (since you can easily guess IDs).

It would be better to use randomized IDs ... UUIDs, ObjectIDs, WUIDs, NanoIDs, etc.

They can easily be sharded in a database, they are unguessable and practically collision free.

Original issue on Gitea

@kolaente commented on 2021-01-24T12:37:53.000Z:

I think I understand the concerns, but I'm not sure if I understand the threat of it. Like, what advantage does a malicous actor have if they know an instance now has 43134 more tasks than a month ago?
Given that you'll need to be authenticated to do anything at all I'm not sure what the advantage of it would be.

And also it would be a massive breaking change and not an easy task to change it everywhere whith potential to go wrong.

What we could do though would be to add an api endpoint to retrieve the tasks by their index which is only incrementing per list, much like Gitea/Github do. That would at least not give the id away in the browser url, but you could still get it from the api response itself.

aksdb commented on 2021-01-24T13:49:28.000Z:

For the theoretical background, see The German Tank problem. More IT related can be read in this blog post.

For the database side, CockroachDB has a few infos. Basically you would enable more possible data storage options with easier horizontal scale out. Restore and merge of data also gets easier.

Regarding the security aspect, there are two vectors:

  1. A future version could - temporarily - introduce a bug that allows unauthenticated API access to certain endpoints or ignore permission scopes (therefore giving authenticated users more access than they should have). With sequential numbers this can be exploited extremely easy. Of course you don't implement something like that willingly. But most security incidents are not due to bad intentions or neglect, but simply due to a mistake. They happen.

  2. A recent famous attack was on a platform called Parler. After the attackers got access to an admin account which was supposed to have access to everything (that is fine), they could easily scrape all the data because all they had to do was increment IDs until they got everything. This attack would have been significantly harder to scale if IDs would have been random.

I am aware that it's not easy to migrate. But it also won't get easier the older the product gets. The earlier such a change is done, the less impact it has.

aksdb commented on 2021-01-24T14:08:32.000Z:

Oh and another addition in regards to

Like, what advantage does a malicous actor have if they know an instance now has 43134 more tasks than a month ago?

Let's say Vikunja would be used in a company, and that company has a workers council. The workers council enforces, that managers cannot track their employees. The numbers could give away that an employee created much or not enough tasks. "Hey you only created two tasks the last month ... are you slacking off?!".

Meta-information can be dangerous and I would try to minimize them wherever possible.

Ticket numbers in ticket systems are a slightly different case, since you need to refer to them directly (via their number). I don't think Vikunja intends to do something like that for tasks, though, right?

@kolaente commented on 2021-01-24T14:59:19.000Z:

Thanks for the detailed answer. I've only looked briefly into the articles but I'll probably come back with a few more comments once I've read them in full.

I've heard about Parler and I do remember thinking "well why are they using numeric ids at their scale?". I guess I never thought about that this could be a problem given I'm not sure if Vikunja would reach a scale like that one day. That being said, it's probably not impossible and as you rightfully pointed out would be a lot harder to change then than it is now.

Meta-information can be dangerous and I would try to minimize them wherever possible.

That's a very valid reason, thanks for pointing that out.

Ticket numbers in ticket systems are a slightly different case, since you need to refer to them directly (via their number). I don't think Vikunja intends to do something like that for tasks, though, right?

Tasks have an "index" value which is the number you see in the frontend when you open a task. This index value is individual per (task, list)-tuple, like github/gitea issues for example.

In general I think it makes sense to do the switch I'm just hesitant to do it because it'll be a lot of work and there's other more interesting things to do right now. But I've put it in the backlog, so it'll happen one day.

aksdb commented on 2021-01-24T15:31:40.000Z:

Tasks have an "index" value which is the number you see in the frontend when you open a task. This index value is individual per (task, list)-tuple, like github/gitea issues for example.

Do you plan to use that somewhere besides that view? Maybe I just missed it, but so far it only seems to be a visual representation when opening the task.

I think when linking tasks, the search for a title (and/or content) is more important than a number (which the user may not even (want to?) remember). So unless you have something in mind (or already implemented and I just failed to notice so far :D), it might be easier to just remove that label and go with the titles only. The IDs would then only be shown in URLs.

Alternative idea (if it's only about the visual representation): show the number representing their order. Yes, that number changes when I remove, add or reorder tasks. But there is value in that number ... "task 2" tells you its the next in line. "Task 50" tells you this is probably not relevant or very far in the future. If you decide to move "task 50" to the front, it's then better to see it as "task 1" (since it's now at the top) instead of having a weird order of "task 50, task 1, task 31, task 21, ...".

@kolaente commented on 2021-01-24T16:46:10.000Z:

From my work experience, you need a reference to a task which does not change, for example to reference it in commits or in other places. It's just quicker to put a number somewhere than a title (which would be editable). For example, when referencing a task in an email or other means of conversation it's way easier to say "Task #123" instead of "You know that task about colouring the header - yeah no no not that one about the menu header, the other one".

This doesn't necessarily have to be a globally unique number (like an auto incrementing id) but a per-list-uniuqe index is fine.

I'd admit you'd probably search for a task by its title or content instead of the number, but you'll still need a number imho.

Re: order: If you absolutely need the order you can have that in kanban (at least for now). If you need a priority, I'd suggest to use the priority field of tasks.

aksdb commented on 2021-01-25T08:13:28.000Z:

Hmm I see. In written communication one could probably get away with simply pasting a link, but spoken not so much.

In general I would be willing to take a shot at migrating the code towards another ID approach (no idea yet if UUID is the best fit or if nano-id is cleaner). However it seems like a simple autoinc -> uuid will not work from a conceptual level. I'll think about it some more if I can come up with an idea for the task referencing. Given that basically all ticketing systems I know use counter for their ticket numbers though lets me believe that this simply might be the best approach if referencing tickets/tasks is desired.

danner26 commented on 2021-04-15T22:25:09.000Z:

I agree that autoinc is not the best way to go about this, but as a possible solution that I am not sure has been proposed yet is to do something like Jira does. Each project gets a unique 2-4 character identifier, which then has an auto increment for actual task number.

This allows for 2 things: first the malicous actor needs to know that specific identifier, and it still allows for easy relaying of information verbally.

I think forcing each list to have an identifier and incrementing on top of that would be a good solution to this issue. Thoughts? @aksdb

@kolaente commented on 2021-04-16T12:20:50.000Z:

@danner26 The tasks already have these kinds of identifiers, at least the index. We could modify the api endpoint (and the frontend urls as well) to query tasks by that index. That would still expose the task id in the api response though. And this expands to other things like lists, namespaces, teams etc. as well so it would be quite an effort to change it everywhere.

I'd advice against forcing a prefix though, in previous versions of Vikunja it would create one by default whenever you created a new list and this was slightly confusing to people so I removed that again.

Tbh this whole thing feels a bit like premature optimization of a problem which does not really exist (yet).

dpschen commented on 2023-04-12T18:02:59.000Z:

If I got it correctly tasks do have an additional UUID now.

@kolaente commented on 2023-04-12T19:20:12.000Z:

@dpschen They do, but it is not exposed via the api and might go away in the future.

Originally created by @vikunja-bot on GitHub (Apr 1, 2025). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/476 _Original issue by aksdb on 2021-01-24T10:48:25.000Z_ Autoincrementing IDs give away usage information (how actively a system is used; how many tasks were created between two points in time, for example) and make it easier to exploit possible security problems (since you can easily guess IDs). It would be better to use randomized IDs ... UUIDs, ObjectIDs, WUIDs, NanoIDs, etc. They can easily be sharded in a database, they are unguessable and practically collision free. [Original issue on Gitea](https://kolaente.dev/vikunja/vikunja/issues/772) --- _**@kolaente** commented on 2021-01-24T12:37:53.000Z_: I think I understand the concerns, but I'm not sure if I understand the threat of it. Like, what advantage does a malicous actor have if they know an instance now has 43134 more tasks than a month ago? Given that you'll need to be authenticated to do anything at all I'm not sure what the advantage of it would be. And also it would be a massive breaking change and not an easy task to change it everywhere whith potential to go wrong. What we could do though would be to add an api endpoint to retrieve the tasks by their index which is only incrementing per list, much like Gitea/Github do. That would at least not give the id away in the browser url, but you could still get it from the api response itself. --- _**aksdb** commented on 2021-01-24T13:49:28.000Z_: For the theoretical background, see [The German Tank problem](https://en.wikipedia.org/wiki/German_tank_problem). More IT related can be read in [this blog post](https://www.clever-cloud.com/blog/engineering/2015/05/20/why-auto-increment-is-a-terrible-idea/). For the database side, [CockroachDB](https://www.cockroachlabs.com/docs/v20.2/sql-faqs#how-do-i-auto-generate-unique-row-ids-in-cockroachdb) has a few infos. Basically you would enable more possible data storage options with easier horizontal scale out. Restore and merge of data also gets easier. Regarding the security aspect, there are two vectors: 1. A future version could - temporarily - introduce a bug that allows unauthenticated API access to certain endpoints or ignore permission scopes (therefore giving authenticated users more access than they should have). With sequential numbers this can be exploited extremely easy. Of course you don't implement something like that willingly. But most security incidents are not due to bad intentions or neglect, but simply due to a mistake. They happen. 2. A recent [famous attack was on a platform called Parler](https://cybernews.com/news/70tb-of-parler-users-messages-videos-and-posts-leaked-by-security-researchers/). After the attackers got access to an admin account which was supposed to have access to everything (that is fine), they could easily scrape all the data because all they had to do was increment IDs until they got everything. This attack would have been significantly harder to scale if IDs would have been random. I am aware that it's not easy to migrate. But it also won't get easier the older the product gets. The earlier such a change is done, the less impact it has. --- _**aksdb** commented on 2021-01-24T14:08:32.000Z_: Oh and another addition in regards to > Like, what advantage does a malicous actor have if they know an instance now has 43134 more tasks than a month ago? Let's say Vikunja would be used in a company, and that company has a workers council. The workers council enforces, that managers cannot track their employees. The numbers could give away that an employee created much or not enough tasks. "Hey you only created two tasks the last month ... are you slacking off?!". Meta-information can be dangerous and I would try to minimize them wherever possible. Ticket numbers in ticket systems are a slightly different case, since you need to refer to them directly (via their number). I don't think Vikunja intends to do something like that for tasks, though, right? --- _**@kolaente** commented on 2021-01-24T14:59:19.000Z_: Thanks for the detailed answer. I've only looked briefly into the articles but I'll probably come back with a few more comments once I've read them in full. I've heard about Parler and I do remember thinking "well why are they using numeric ids at their scale?". I guess I never thought about that this could be a problem given I'm not sure if Vikunja would reach a scale like that one day. That being said, it's probably not impossible and as you rightfully pointed out would be a lot harder to change then than it is now. > Meta-information can be dangerous and I would try to minimize them wherever possible. That's a very valid reason, thanks for pointing that out. > Ticket numbers in ticket systems are a slightly different case, since you need to refer to them directly (via their number). I don't think Vikunja intends to do something like that for tasks, though, right? Tasks have an "index" value which is the number you see in the frontend when you open a task. This index value is individual per `(task, list)`-tuple, like github/gitea issues for example. In general I think it makes sense to do the switch I'm just hesitant to do it because it'll be a lot of work and there's other more interesting things to do right now. But I've put it in the backlog, so it'll happen one day. --- _**aksdb** commented on 2021-01-24T15:31:40.000Z_: > Tasks have an "index" value which is the number you see in the frontend when you open a task. This index value is individual per `(task, list)`-tuple, like github/gitea issues for example. Do you plan to use that somewhere besides that view? Maybe I just missed it, but so far it only seems to be a visual representation when opening the task. I think when linking tasks, the search for a title (and/or content) is more important than a number (which the user may not even (want to?) remember). So unless you have something in mind (or already implemented and I just failed to notice so far :D), it might be easier to just remove that label and go with the titles only. The IDs would then only be shown in URLs. Alternative idea (if it's only about the visual representation): show the number representing their order. Yes, that number changes when I remove, add or reorder tasks. But there is value in that number ... "task 2" tells you its the next in line. "Task 50" tells you this is probably not relevant or very far in the future. If you decide to move "task 50" to the front, it's then better to see it as "task 1" (since it's now at the top) instead of having a weird order of "task 50, task 1, task 31, task 21, ...". --- _**@kolaente** commented on 2021-01-24T16:46:10.000Z_: From my work experience, you need a reference to a task which does not change, for example to reference it in commits or in other places. It's just quicker to put a number somewhere than a title (which would be editable). For example, when referencing a task in an email or other means of conversation it's way easier to say "Task #123" instead of "You know that task about colouring the header - yeah no no not that one about the menu header, the other one". This doesn't necessarily have to be a globally unique number (like an auto incrementing id) but a per-list-uniuqe index is fine. I'd admit you'd probably search for a task by its title or content instead of the number, but you'll still need a number imho. Re: order: If you absolutely need the order you can have that in kanban (at least for now). If you need a priority, I'd suggest to use the priority field of tasks. --- _**aksdb** commented on 2021-01-25T08:13:28.000Z_: Hmm I see. In written communication one could probably get away with simply pasting a link, but spoken not so much. In general I would be willing to take a shot at migrating the code towards another ID approach (no idea yet if UUID is the best fit or if nano-id is cleaner). However it seems like a simple autoinc -> uuid will not work from a conceptual level. I'll think about it some more if I can come up with an idea for the task referencing. Given that basically all ticketing systems I know use counter for their ticket numbers though lets me believe that this simply might be the best approach if referencing tickets/tasks is desired. --- _**danner26** commented on 2021-04-15T22:25:09.000Z_: I agree that autoinc is not the best way to go about this, but as a possible solution that I am not sure has been proposed yet is to do something like Jira does. Each project gets a unique 2-4 character identifier, which then has an auto increment for actual task number. This allows for 2 things: first the malicous actor needs to know that specific identifier, and it still allows for easy relaying of information verbally. I think forcing each list to have an identifier and incrementing on top of that would be a good solution to this issue. Thoughts? @aksdb --- _**@kolaente** commented on 2021-04-16T12:20:50.000Z_: @danner26 The tasks already have these kinds of identifiers, at least the index. We could modify the api endpoint (and the frontend urls as well) to query tasks by that index. That would still expose the task id in the api response though. And this expands to other things like lists, namespaces, teams etc. as well so it would be quite an effort to change it everywhere. I'd advice against forcing a prefix though, in previous versions of Vikunja it would create one by default whenever you created a new list and this was slightly confusing to people so I removed that again. Tbh this whole thing feels a bit like premature optimization of a problem which does not really exist (yet). --- _**dpschen** commented on 2023-04-12T18:02:59.000Z_: If I got it correctly tasks _do_ have an additional UUID now. --- _**@kolaente** commented on 2023-04-12T19:20:12.000Z_: @dpschen They do, but it is not exposed via the api and might go away in the future.
GiteaMirror commented 2026-04-20 16:46:40 -05:00
Author
Owner
Copy Link
Copy Source

@kolaente commented on GitHub (Apr 1, 2025):

I don't think we'll change this soon, therefore I'll close this.

<!-- gh-comment-id:2769751824 --> @kolaente commented on GitHub (Apr 1, 2025): I don't think we'll change this soon, therefore I'll close this.
GiteaMirror commented 2026-04-20 16:46:41 -05:00
Author
Owner
Copy Link
Copy Source

@mishaturnbull commented on GitHub (Apr 8, 2026):

@kolaente , would you be open to a new, independent API endpoint that supports some kind of index-within-project task lookup? My use case is using Vikunja as a Gitea external issue tracker. As-is, using the "numeric" option in the Gitea settings makes a link that does work correctly -- but the index to use is counterintuitive (I also come from a Jira background, so the PROJECT-N identifier feels "native" to me):

Image

To get it right in Gitea, I have to do something like git commit -m "Fix issue #7, not the more obvious Fix issue #2.

If I set a project identifier (for example, GITEA):

Image

then there's no way by which I can git commit -m "Fix GITEA-2" or similar.

What I'd like to propose is a new API endpoint, something like /projects/{project}/tasks/{id}, which works just like the existing /tasks/{id} but with clearer handling of the task identifier within that project. By creating a new endpoint, I imagine this shouldn't break any backwards compatibility promises.

Would love to hear your thoughts on this -- I'm happy to help where I can, but I have no web development background so it may take me a while :)

Thanks for the project; regardless of this feature, it looks great and I'll definitely be using it, Gitea connection or no!

<!-- gh-comment-id:4203183873 --> @mishaturnbull commented on GitHub (Apr 8, 2026): @kolaente , would you be open to a new, independent API endpoint that supports some kind of index-within-project task lookup? My use case is using Vikunja as a Gitea external issue tracker. As-is, using the "numeric" option in the Gitea settings makes a link that does work correctly -- but the index to use is counterintuitive (I also come from a Jira background, so the `PROJECT-N` identifier feels "native" to me): <img width="485" height="348" alt="Image" src="https://github.com/user-attachments/assets/f6085462-88ce-42ae-bc8f-70a18c8ebc4c" /> To get it right in Gitea, I have to do something like `git commit -m "Fix issue #7`, not the more obvious `Fix issue #2`. If I set a project identifier (for example, `GITEA`): <img width="485" height="348" alt="Image" src="https://github.com/user-attachments/assets/92a67e9f-99a4-4282-af5e-805936ae5d6f" /> then there's no way by which I can `git commit -m "Fix GITEA-2"` or similar. What I'd like to propose is a *new* API endpoint, something like `/projects/{project}/tasks/{id}`, which works just like the existing `/tasks/{id}` but with clearer handling of the task identifier within that project. By creating a new endpoint, I imagine this shouldn't break any backwards compatibility promises. Would love to hear your thoughts on this -- I'm happy to help where I can, but I have no web development background so it may take me a while :) Thanks for the project; regardless of this feature, it looks great and I'll definitely be using it, Gitea connection or no!
GiteaMirror commented 2026-04-20 16:46:42 -05:00
Author
Owner
Copy Link
Copy Source

@kolaente commented on GitHub (Apr 8, 2026):

I've been thinking about this as well, happy to add this. Can you open a new issue so that we can keep this one closed?

<!-- gh-comment-id:4204893549 --> @kolaente commented on GitHub (Apr 8, 2026): I've been thinking about this as well, happy to add this. Can you open a new issue so that we can keep this one closed?
GiteaMirror commented 2026-04-20 16:46:43 -05:00
Author
Owner
Copy Link
Copy Source

@mishaturnbull commented on GitHub (Apr 8, 2026):

Ah, the github issue template suggested that feature requests go in the forum -- and it looks like this may already be there: https://community.vikunja.io/t/links-with-project-task-identifier/3948 . I'll go vote for that one, figured I'd link to it from here for findability!

<!-- gh-comment-id:4210180278 --> @mishaturnbull commented on GitHub (Apr 8, 2026): Ah, the github issue template suggested that feature requests go in the forum -- and it looks like this may already be there: https://community.vikunja.io/t/links-with-project-task-identifier/3948 . I'll go vote for that one, figured I'd link to it from here for findability!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 pull-request
Mirrored from GitHub Pull Request
 pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#6169