Details
Details
- 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
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
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
Comment Actions
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.
| 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 |
Comment Actions
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;