User ID on Client Side or Not?
Hi,
I’m building a Feed application, somewhat like Facebook. So far, I’ve implemented it in a way that avoids fetching or using user IDs on the client side. For example, when fetching posts or liking/commenting on one, I send a request to the server with just the post ID. On the server side, I handle the like or comment by finding the post using its ID, which is tied to a user ID, and update it as needed. This way, I don’t need to use the user ID on the client side. Similarly, when fetching data for myself as an authenticated user, I get my user ID directly from my identity on the server, so there’s no need to pass my user ID explicitly.
However, if I want to implement a profile page, I’ll need to locate and display a specific user’s profile. For this, I assume I’ll need the user ID available on the client side. Would this approach be fine?
What is your opinion about?
Thanks in advance!
3 Replies
I think user ids could be treated as identifiers and not as secrets.
I can't see the issue with exposing them as long as you have access control e.g .
But I would not recommend to expose countable ids.
If you don't want to expose the db user id you could you tokenized identifiers and the map them to the db id on the server.
Just my opinions tho.
Good luck
and if you don't want to expose countable id you could use something like https://sqids.org/dotnet
Short Unique IDs in .NET (C#) · Sqids
Generate short unique IDs in .NET (C#) using Sqids. These identifiers are URL-safe, can encode several numbers, and do not contain common profanity words.
I forgot to mention all user ids are guid, and i use authentication on the server side so it is not countable. I guess.
Technicly I cannot have any issue by exposing the userId to the client till I have authentication on every endpoint?