is `account.get()` safe to be used in the client side?

I want to user's id for authentication. However, a while ago I was told in this server not to use account.get() and instead add user preferences for that user which matches with an $id that is in a collection that contains details like username. ChatGPT is advising against it strongly. So, now I am not sure which id to use for authentication, the one that is created in a collection and added as a preference, or the id that is in the Auth section?

Lol
Ai's be like implement worst security in the app
Then advise users not to use actually secure methods.

GPT actually encourages me to use the $id the comes with account.get() in the frontend. I was advised against it in this server.

What was the implementation that the id will be used in?

like different navbars for a user that is logged in, as well as leaving comments for posts, posting outside links.

There is no problem.
The user id is protected by session.
No one else can get it anyway.
And even if they could get it, if other tables that use the id to reference like whose comment is this, are protected by row level security then having the id has no use atall for the one who is trying to crack something.

hmm... this is my setup.The users can log in and only them are able to make posts, post outside links, and leave comments. However, I want the posts, comments, and the links be publicly available to everyone. So everyone can see them; the read for the posts collection is allowed for everyone.

Does that make sense? @Axistro

And I want to use the $id that is get from account.get() to ensure that the user is sees the UI to make posts, post outside links, and leave comments.

There is no harm in that.
But in my opinion, you should secure the comment method with a external or server side api.
Beacuse if anyone wants they can see previous comments and who's id are present in those comment.
Now if they create a session and instead of passing their own id they pass the targeted user id, that fake comment will link to the target user not the one who created.
To secure you can check what id is being passed and the current user session if the ids match.
This way they wont be able to misuse it.

@Axistro

No
The commenting part must not be on client side.
I assume when you are adding an comment, you are passing the userId and comment by taking the id from account.get().
Now if this is just a normal method written in client side then the mallecious user can pass a victim userId blocking your own method of passing current userId.
So I am suggesting you to create an api route for commenting.
In that api route check what userId is being passed to create a comment and the $id in the account.get().
This way the mallecious user cannot harm someone by faking an comment indicating the victim user wrote some racist or illicit comment.

This is as much as i can elaborate.
Paste my comment to any ai to elaborate if more context is needed.

oh Lord. I don't use any server-side function for creating posts, posting outside links, and posting comments.

why even allow those actions on the client-side if it is unsafe?

😭

The id is safe.
Your feature is not

my confusion is why even allow writing and updating to collection from the client side if it is unsafe

You are missunderstanding it.
Just use my method for posts comments etc.
I would love to explain
But i have to go now.
Ask ai why appwrite is secure but your feature implementation is not

Cc: @Chirag Aggarwal
Sorry for the ping.
But is there any plan for a new table feature where impersonation is blocked by appwrite api?
Say an option in table setting.
I think appwrite already checks who created the row.
So there can be a new fixed column like updatedAt and createdAt.
If the feature is on, there will be no need for a userId field referncing to the user who created the row.
That way, no need for an external api check.
Although just exposing the createdBy would be enough and no need for a settings to be toggled.

impersonation?

I think appwrite already checks who created the row.

i dont think so, row can be created by any entity, ur server side code, ci job, workers etc. its application logic to restrict it to users using permissions

Well it could be a good addition.
Because,
Now For a table that contains comment would have to reference to a user Row to reference who created that comment.
Now if someone can pass another user id instead of his, he can create comment as if the victim user have commented.

use row security, add row level perms so only that specific user can modify