Signal/Signal-Server
1
0
Fork 0
mirror of https://github.com/signalapp/Signal-Server synced 2026-04-21 06:48:07 +01:00
Code Issues Packages Projects Releases Wiki Activity

Allow "reserving" one's own committed username hash

Browse Source
This commit is contained in:
Jonathan Klabunde Tomer
2024-01-23 12:44:55 -08:00
committed by GitHub
parent 55b9d84956
commit 21d0ffc990
2 changed files with 25 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
service/src/main/java/org/whispersystems/textsecuregcm/storage/AccountsManager.java
View File

@@ -549,6 +549,17 @@ public class AccountsManager {
return CompletableFuture.failedFuture(new UsernameHashNotAvailableException());
}
if (account.getUsernameHash().filter(
oldHash -> requestedUsernameHashes.stream().anyMatch(hash -> Arrays.equals(oldHash, hash)))
.isPresent()) {
// if we are trying to reserve our already-confirmed username hash, we don't need to do
// anything, and can give the client a success response (they may try to confirm it again,
// but that's a no-op other than rotaing their username link which they may need to do
// anyway). note this is *not* the case for reserving our already-reserved username hash,
// which should extend the reservation's TTL.
return CompletableFuture.completedFuture(new UsernameReservation(account, account.getUsernameHash().get()));
}
final AtomicReference<byte[]> reservedUsernameHash = new AtomicReference<>();
return redisDeleteAsync(account)