Option to randomize shot URLs

[EmberHeartshine]

At the moment, all shots uploaded are given a number in increasing consecutive order. This would make it trivial to view shots not intended for the recipient by simply changing the number. The direct links are already randomized; perhaps that could be used in place of the consecutive numbering for the viewing page.

[mdshack]

Hey @EmberHeartshine, this would definitely be a fairly trivial move to go from auto incrementing IDs to UUIDs, though this would break existing usages of ShotShare (if people have created shots and distributed links to them).

I can see two possible ideas for handling this

• Implement some sort of opt-in feature that would change column behavior
• Hold off on this till version 2 and issue a warning for updating from 1 -> 2 regarding this

Let me know if you have any additional ideas as to how I could go about this!

[EmberHeartshine]

I don't know the current logic behind storing what values of shot page correspond to what image, but I imagine there shouldn't be any intersection between UUIDs and numerical shot pages. Would there be any harm to simply changing the way shot page URLs are stored in the database and continue to append past the existing entries? Or are shot pages indexed in such a way that makes that change impossible?

[mdshack]

I don't know the current logic behind storing what values of shot page correspond to what image, but I imagine there shouldn't be any intersection between UUIDs and numerical shot pages. Would there be any harm to simply changing the way shot page URLs are stored in the database and continue to append past the existing entries? Or are shot pages indexed in such a way that makes that change impossible?

I have never actually mixed UUIDs & auto incrementing IDs, though they would never intersect. Let me sit on this one for a little bit and dive into any of the UUID helpers that are built into Laravel to make sure mixing these wouldn't break anything.

In MySQL a UUID is not a special datatype (so this column would just shift to a varchar), I would wonder if this would have a negative impact on databases that do possess special data types for UUIDs (I think Postgres has this).

[EmberHeartshine]

That's fair. My personal greedy side is saying "just implement it ASAP, consequences be damned, I have a personal need for it" but waiting to refractor until v2 is reasonable here I feel.

[EmberHeartshine]

After thinking about it a little bit more, I will comment that this is a blocking issue for me-- that is, I can't deploy ShotShare in the capacity I need it (without #23 fixed, anyway). If you don't want to do the refactor until 2.0 anyway then I totally get it, but I was a little more flippant with my previous comment than I intended.

It looks like you have #⁠23 on the roadmap for 1.7.0, however, so this may be a non-issue.

[mdshack]

After thinking about it a little bit more, I will comment that this is a blocking issue for me-- that is, I can't deploy ShotShare in the capacity I need it (without #23 fixed, anyway). If you don't want to do the refactor until 2.0 anyway then I totally get it, but I was a little more flippant with my previous comment than I intended.

It looks like you have #⁠23 on the roadmap for 1.7.0, however, so this may be a non-issue.

Hey @EmberHeartshine, I have an "opt-in" UUID solution in my working branch, we should see this feature in 1.7.0. You can see that progress here.

[mdshack]

This functionality has just been rolled out in 1.7.0; lemme me know if you have any questions!

see FEATURE_UUID_ROUTES here

[EmberHeartshine]

This is so awesome.

Seriously, you're doing amazing work implementing feature requests from some random schmuck on the internet. You need a tip jar or Patreon or something.