Page MenuHomePhabricator

[identity] Modify FindUserID response to respect reserved_usernames
ClosedPublic

Authored by bartek on Nov 27 2023, 4:59 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Jun 13, 11:50 PM
Unknown Object (File)
Thu, Jun 13, 9:01 PM
Unknown Object (File)
Thu, Jun 13, 6:33 AM
Unknown Object (File)
Sun, Jun 2, 9:43 PM
Unknown Object (File)
Thu, May 23, 4:36 AM
Unknown Object (File)
Mon, May 20, 2:01 PM
Unknown Object (File)
Mon, May 20, 2:01 PM
Unknown Object (File)
Mon, May 20, 2:01 PM
Subscribers

Details

Summary

Addresses ENG-5802.

Added is_reserved field to FindUserIDResponse to indicate if the username/wallet address is in the reserved_usernames list.
Followed the logic that we discussed in the Linear task.

Depends on D10052

Test Plan
  • Created a user (not-reserved) and checked the response: userID != null, is_reserved == false
  • Added the same user to the reserved_usernames list and checked the response: userID != null, is_reserved == false
  • Added a username to the reserved list and checked the response: userID == null, is_reserved == true
  • For other cases, checked the response: userID == null, is_reserved == false

Also tested wallet addresses

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

bartek held this revision as a draft.
bartek published this revision for review.Nov 27 2023, 6:47 AM

Now I think that maybe we should make is_reserved independent of userID, so:

  • userID not null if the user is registered with Identity (current behavior)
  • is_reserved = true if given username is in the reserved_usernames table, regardless of it being registered with Identity (instead of false)

Either way, the client is able to deduce if a username is a) registered with Identity; b) reserved; c) available

I'm okay with that proposed change. The important thing is that the client should be able to deduce whether a username is available or not.

This revision is now accepted and ready to land.Nov 29 2023, 6:27 AM
services/identity/src/grpc_services/authenticated.rs
265 ↗(On Diff #33725)

tokio::join is pretty handy... i wonder if there are other places where we should be using it

Applied the suggested change.

Clients can deduce if username is available with the following condition:

username_available = user_id == null && is_reserved == false;
// or reversed if you prefer
username_taken = user_id != null || is_reserved == true;