I currently have a website where all users' IDs (the primary keys in the 'users' table) is displayed on their profile. The reasons are:
1) Username is not unique (don't want it to be unique)
2) Users can send each other messages and gifts and money by using their user ID
3) Any user can send any user money, there's no other way (i can think of) which will otherwise guarantee that the money is going into that particular user's account. Email/cell number/username are not unique enough in this case.
4) The user's id will be an integral part in searching for the payment reference.
It did not occur to me before until I watched a video tutorial on Cookies (unrelated to the question above) where he says "cookies should not be used to store information that hackers will want, like a user ID". Which intrigued me to ask this question. My whole website project is based on the user ID public to other users. Silly, silly me!
Where can I find information on this i.e. if hackers can really use the user-ID to do bad things?
I've wondered the same thing a while back, and found this stackoverflow question useful.
Some notes:
select * from messages where to_user_id = ?instead of having to joinUser.Basically you're coupling functional concerns to technical implementation details. Like all decoupling, it's an extra layer of complexity, but it does make it easier to change things without affecting everything else.
I'm not sure about the cookies. You shouldn't trust that if the client sends a user id of 5, that it must thus be user 5, because that'd be really easy to fake. So basically it's only useful for sending from server to client, in which case you don't probably need cookies. Maybe that's where the guide was coming from?
So I'd say: safe enough, but possibly undesirable.