the GetUserId() on client side should not be used for security, but that doesn't mean that sometimes, you want to still use it.  There is nothing wrong with that, as long is you use it for functionality / display, not security.

example :

client : only showing delete icon on list items created by the current user.

server : only allowing the delete to go through if item is created by the current user.

How you implement the client side part, doesn't matter, it could always be tampered with, even if you make some other solution then directly using the GetUserId() there.  The key safeguard against this tampering (it is not spoofing, but rather privilege escalation) is what you do at server side, i.e. call the GetUserId() there inside the actual transaction that executes the delete.

I get the 'but juniors will get this wrong' part, but that needs to be fixed with training, because removing the GetUserId() client side does not make things any more secure, a junior will then not automagically start using secure patterns on server side as a consequence.

Also, practically, OutSystems can't just do this, loads of existing code would be broken

Dear,

I was aggreged your some points.

Lets take this case

client : only showing delete icon on list items created by the current user. 

(while fetching list time (server itself) i can use my structure just apply filter or some logic to show the icon) - means I can handle this on server itself

i am wonder to know could you tell me any other reason to use getuserid() on client side

and basically while calling this function it was fetch the data from local storage , this means we are exposing our server user_ID to client. 

if i am correct our entire session basically based on user related tokens (part of userid) that's why we are storing some cookies like nr1Users  , nr2Users   as secured its completely agreed and accepted.

But how we can agreed to storing session user id on local variable directly even without  encrypted.

Kindly correct me if I am wrong!

Hi,

could you tell me any other reason to use getuserid() on client side : anything you want to do on your client (primarily, what and how you display stuff, whether stuff is editable/actionable) that somehow depends on the current user id versus a user reference in the data.

this means we are exposing our server user_ID to client : that 11 value showing in local storage, is not worse or more dangerous than the same data showing in, for example, retrieved data in your network tab, like the 'createdBy' attribute of an aggregate response.  Only banning the getUserId() from the client will not do anything about that, so if your goal is to remove all user id's from client side, there is MUCH MUCH more work to be done.

while fetching list time (server itself) i can use my structure just apply filter or some logic to show the icon) - means I can handle this on server itself : Yes, one of the alternatives is a calculated attribute 'CanDelete' coming from the aggregate (I think that is what you mean), but that is just as easily hacked, by either overriding the response from that list aggregate response, or by resending an altered Delete request. 

Sure, you 'handle this on server itself', but the big distinction here is not whether you handle it on server, but whether you apply your security at the moment the Delete is executed.  Doing something on server during the retrieval does nothing for security.

I don't understand this sentence if i am correct our entire session basically based on user related tokens (part of userid) that's why we are storing some cookies like nr1Users  , nr2Users   as secured its completely agreed and accepted. 

Dorine