• Welcome to the Chevereto user community!

    Here users from all over the world gather around to learn the latest about Chevereto and contribute with ideas to improve the software.

    Please keep in mind:

    • This community is user driven. Be polite with other users.
    • Is required to purchase a Chevereto license to participate in this community (doesn't apply to Pre-sales).
    • Purchase a Pro Subscription to get access to active software support and faster ticket response times.

image and album path/URI/routing question

Wolfspyre

Chevereto Member
Pro
I notice that there's a random alphanum string appended to the uri of albums and assets..

This can be somewhat problematic in situations where the random-string matches well-known filetypes ie: .pl

Would it be absurd to:
  • allow the administrator/user to elect to have the random-string used as a path prefix or suffix
  • allow the administrator elect whether or not to allow the users to select their own (or regenerate?) a random-string
  • not have the random string in the album URI at all (ie just use album/subalbum name as the uripath


I looked around in the docs but didn't find anything that seemed relevant
 
Hello,

The alphanumeric string in the URI is not random. It's an encoded representation of the integer table row ID, based on a random salt generated during installation. This design prevents direct content enumeration and enhances privacy by making it harder for others to guess the structure of your content.

If you’d like to explore alternative configurations for URI structures, such as those you suggested, this would require custom modifications to the system, as the current design doesn't offer these options out of the box.

Let me know if you'd like further guidance!
 
Heya! That makes sense, for sure...
is there any reason the fingerprint/ID/salt needs to be a suffix?
Would this functionality work just as well for path distinctification as a prefix?

I notice there's the option to enable/disable SEOified URIs....

Might that be a viable mechanism to enhance?

I could see classifying the behavior as an alternate SEO optimization?

I'm just trying to think of reasons why a suffix makes more sense.
 
is there any reason the fingerprint/ID/salt needs to be a suffix?
In the design stage, we flipped a coin to decide whether the fingerprint/ID/salt should be a prefix or suffix. The coin had a 50% chance of going either way, but unfortunately, the coin had a bit of a bias and favored the suffix approach.

Would this functionality work just as well for path distinctification as a prefix?
Yes.

Might that be a viable mechanism to enhance?
Honestly, I really doubt it. You're overthinking it a bit. The current setup is pretty effective as is, and adding extra complexity might not bring enough benefit to justify the change.

I could see classifying the behavior as an alternate SEO optimization?
That’s an interesting thought! While it could be seen as an alternate SEO optimization, I'd say it’s more about structural clarity than SEO directly. SEO benefits might come from the overall readability and how the URL is perceived, but this change isn't likely to have any impact on SEO ranking.
 
That’s an interesting thought! While it could be seen as an alternate SEO optimization, I'd say it’s more about structural clarity than SEO directly. SEO benefits might come from the overall readability and how the URL is perceived, but this change isn't likely to have any impact on SEO ranking.
yeah, i agree it won’t have much impact on ACTUAL seo;
… although, one might make the argument that the increased entropy of url prefixes could serve to increase the hashing diversity resulting in a more even cache distribution ultimately resulting in more consistency in content delivery speeds…..

(idk how factual that argument would be.)

and I could see one wanting to have the hash at the end for the purpose of easier url parsing by LBs doing uri regex; but afaik most LBs can filter on ‘ends_with_’


regardless; the problem i encountered, is that certain hashes have a contextual association in other tools which can be problematic for the purposes of social sharing; as, for example, a gallery with the hash ‘.PL’ gets interpreted as a file download in discord (regardless of mimetype hint)

i don’t REALLY care what the uri is too much. but i would like the ability to alter/regen hashes which happen to conflict with pre-existing external expectations….

so … with that outcome in mind; what makes sense to you?

i’m not attached to the idea; my intent by expressing the idea is to come to the table with beer, as it were…..

I didn’t want to just say ”Noworky! Fix PLZ?”

i wanted to have…. at least a terrible suggestion that might solve my issue …. in addition to expressing my problem 🙂

make sense? 🙂
 
Back
Top