GUID or INT url parameters

Question

GUID or INT url parameters

ANB 181

Hi people,

On my website I've the following structure to present a person, using AspNetUsers table from Identity:
www.mysite.com/person/6B29FC40-CA47-1067-B31D-00DD010662DA

However is hard to remember the url and it gets really big in some cases.

My second approach would be just create a new INT column 'UserId_Int' on AspNetUsers table.
So the url would be something like that: www.mysite.com/person/123
The problem here is I don't want customers 'hacking' other persons, just switching to 124, 125, 126, etc products.

What I am thinking now is to keep the INT column 'UserId_Int' on AspNetUsers table and use a hash/salt for the ID on the url:
www.mysite.com/person/29sla1

So after the user hits Enter, the .Net Core API would receive the '29sla1' parameter, convert it to INT, and then search the AspNetUsers table UserId_Int column.
Is this approach something weird ?

If bad, what approach could I use instead ?

Thx folks :)

Anonymous

2022-02-07T03:20:27.74+00:00

Hi @ANB ,

Agree with AgaveJoe, adding the sensitive data (such as the userid) in the URL is not a good choice. But if you have to do that, I suggest you could also use the authentication cookie to store the current user's identity, then when you want to access the protected resource, you could use current user's identity (get it from HttpContext.User) to query the database and get the userid, then compare it with the userid from the request url, if there are same, it means that the user is validate, if not it means the userid (from the url) has been changed.

Best regards,
Dillion

1 answer

Your answer

Anonymous

2022-02-07T03:20:27.74+00:00

Hi @ANB ,

Agree with AgaveJoe, adding the sensitive data (such as the userid) in the URL is not a good choice. But if you have to do that, I suggest you could also use the authentication cookie to store the current user's identity, then when you want to access the protected resource, you could use current user's identity (get it from HttpContext.User) to query the database and get the userid, then compare it with the userid from the request url, if there are same, it means that the user is validate, if not it means the userid (from the url) has been changed.

Best regards,
Dillion

Answer 1

I think this subject has been discussed in your other threads. Again, adding sensitive data like a userId in a URL is a poor security design choice. The standard approach is caching user data an encrypted token within an authentication cookie. The authentication cookie middleware reads the token and creates a user principal for the duration of the request. The user data is fetched using the standard pattern...

User.Identity.Name

The database tables must be designed with the user's Id on records that only the user can view.

What I am thinking now is to keep the INT column 'UserId_Int' on AspNetUsers table and use a hash/salt for the ID on the url: Is this approach something weird ?

By definition hashing is a one way operation. Therefore it is not possible to convert 29sla1 back to the original value. Use .NET cryptography libraries to encrypt sensitive data exposed to the user. Better yet, do not expose sensitive data to the user especially in the URL.

If bad, what approach could I use instead ?

Following openly published pattern and practices is always the best approach.

Use cookie authentication without ASP.NET Core Identity

Share via

GUID or INT url parameters

1 answer

Your answer