Upload: Generate a more elegant random token to distinguish simultaneous uploads

[raxod502]

Not using the standard bug report template because this is a comment directly on the source code, and not a report of a user-visible problem in a deployed configuration.

I am using the PhotoPrism REST API to upload photos, and since the API documentation isn't finished yet, I am (as recommended) checking the browser console when uploading photos to see which endpoint to use.

All good so far, I see there is a request like POST https://photos.example.com/api/v1/users/us56eo2vflczhcntsq/upload/zp0dcs. Where does the value zp0dcs come from? I check the frontend and find this:

photoprism/frontend/src/common/util.js

Lines 294 to 296 in f652159

	static generateToken() {
	return (Math.random() + 1).toString(36).substring(6);
	}

This implementation works, but is deeply perplexing to me. It is generating a floating point number, converting it to base 36, and then taking off the first 6 characters (so, 1.nb7z7ohqqv becomes 7ohqqv). The algorithm here has a number of interesting properties:

• Usually it generates 6-character tokens.
• But sometimes it generates 7-character tokens instead, depending on how the floating-point number was displayed.
• And sometimes it generates 5-character tokens instead, if you got unlucky and the floating-point number was evenly divisible by a power of 36.
• It can even generate shorter than 5-character tokens, down to and including the empty string, if you get sufficiently unlucky (I think around 1 in 300 million?). If you actually hit this last case then the upload would most likely fail because it wouldn't match the server-side route.

All of this is not a big issue, because the upload path isn't security critical and the failure condition is very rare, but just... why? There are lots of ways of generating random strings in JavaScript and it seems like it would be straightforward to use one that doesn't have such strange edge cases. I would be happy to contribute one if desired.

[lastzero]

@raxod502 I don't see this as a bug, since from what I know it works as intended and is "good enough" for this purpose, despite the lack of elegance. Note that the "token" (random number) is only used to distinguish between simultaneous uploads from the SAME user, i.e. you could even use incrementing integers or the time the upload started (though these approaches would generally have a higher chance of generating duplicate tokens than the "unelegant" solution, unless you implement conflict resolution or some kind of locking mechanism when using multiple browser sessions, which is extra work for no obvious benefit).

That said, you are welcome to submit a PR with improvements that make this part of the code more elegant! 🌷

[raxod502]

Implemented and tested in #4971.