[BUG] `ApiToken` does not generate a UUID for an empty-string token (only for null)

[SuperCorleone]

Describe the Bug

The constructor generates a random UUID only when token == null; an empty string "" is passed through unchanged, so getToken() returns "". The only token-generating call site (ApiTokenService.java:31 → new ApiToken(user, name)) passes null, and DB-loaded tokens always carry a real value, so this is not triggerable today — a defensive hardening item.

Root Cause

this.token = token != null ? token : UUID.randomUUID().toString();  // "" is not replaced

Suggested Fix

this.token = (token == null || token.isEmpty()) ? UUID.randomUUID().toString() : token;

Corresponding Test (generated)

@Test
public void testGetToken_WithEmptyToken_ReturnsGeneratedUUID() {
    // Arrange
    User user = new User("testuser", "Test User");
    ApiToken apiToken = new ApiToken(null, "", user, "test-name", null, null);
    
    // Act
    String actualToken = apiToken.getToken();
    
    // Assert
    assertNotNull(actualToken, "getToken() should not return null when token is empty");
    assertNotEquals("", actualToken, "getToken() should not return empty string when token is empty");
    assertTrue(UUID.fromString(actualToken) != null, "Generated token should be a valid UUID");
}

This input was generated by the test case generator TestFusion developed in our STAR lab.

[dgraf-gh]

Hi @SuperCorleone,

on one side, this issue is valid. But on the other side, it is a theoretical construct since we only call these constructors either with a token value coming from the DB or when we create an actual new token without any user input.

I am not a big fan of defensive measurements for theoretical problems since they solely increase the complexity.

Closing it for now