Feature 'adjustment' suggestion

[SubnetMask]

I've noticed that when creating an album as 'any can access with link', the album in the link tends to be only two characters... This is not great. I'd like to suggest that instead of the album being only two random characters, instead it is created as at minimum 12 random characters. Longer would be even better. Or even better than that, have that a configurable option where the person running the server can specify the length, from two to whatever.

Just a thought.

 

[Rodolfo]

There's the internal variable id_padding which can be used to get more characters on the encoded ids. Table variables, name id_padding a higher number denotes greater padding.

 

[SubnetMask]

I'm assuming this is in the database, not a simple file. I'll look into it and try to adjust it.

 

[SubnetMask]

So I finally got this figured out. For anyone else interested, the MySQL command to change this value is this:

UPDATE chv_variables SET variable_value='your_new_value' WHERE variable_name='id_padding' AND variable_id=1;

However, changing t didn't make that much difference it seems.

By default, the value is 999. Even after changing that as high as 12,000, I only ended up with three character link IDs instead of the default two.

I'm not sure how this padding works, but these link IDs should really be 16 character (yes, I know I previously said 12 character... Maybe 12 character hard minimum with a 16 character default minimum and a... much larger... hard max?) randomly generated alpha-numeric strings at MINIMUM, and ideally, that should be configurable in the Web UI.

Side question - when will my posts no longer need to be approved? While I haven't posted much, I've only been a member/signed up since July 2017... It's kind of getting old...

Edit: Changing it to 120,000 resulted in a four character ID.

Edit2: I changed the value to 2400000000000000024000000000000000, which gave a better (but not ideal( value of BnMLrv72JgsP for the album, but I think that broke Cheverto, as I got 'that page doesn't exist' for that album. There's got to be some better way to generate long random strings that won't break things. Micro$oft Office 365 nonsense makes crazy long strings for files and whatnot - not that I'm a fan of Micro$oft at all - point being there's got to be an easy way to do it.

 

[SunnyBlueSkies]

You alter an existing row inside a table, when you choose update. You're only changing the variable of a particular entry. Anyways, that and you're also thinking of the blob when it comes to storing long content within a database table.

An example where blob or long blob is used in a database would be when we had the freedom to customize our Myspace layout.

 

[Rodolfo]

The system stores the variables in database, but it read these from Redis. Anytime you change variables you should send a Redis cache flush command. https://v4-docs.chevereto.com/application/reference/cli.html#cache-flush

 

[SubnetMask]

When I ran 'app/bin/cli -C cache-flush', , it returned '[ERROR] Cache is not enabled'.

 

[SubnetMask]

I'm assuming that since '[ERROR] Cache is not enabled' is returned, the Redis cache is not enabled, and after changing the DB, the change is immediate since without the cache, it would pull from the DB. So shouldn't larger changes have resulted in larger changes to the string generated? If not, how can I adjust it to 16+ string length?

 

[Rodolfo]

The encode id system in Chevereto only allows to tweak the padding (integer value) for the actual id value, you can't control the min output of the encoded result.

The system uses both id_padding and crypt_salt to compute that encoded id, you need to play around with it.

 

[SubnetMask]

I REALLY don't mean to sound like an *** but why the dancing around the subject? Why the half answer breadcrumbs that may or may not lead to an answer? The reality is two or three character generations for these URLs is REALLY BAD. They really should be much longer by default, and while I don't know anything about how you do things on the backend, It seems this should be a configurable option in the UI. Overall, IMO, Cheverto is a really nice product, very refined, but this one aspect of it surprises and concerns me. The super short nature of the URLs/IDs would make it super easy for an attacker to brute force IDs, find valid ones and scrape them for what's inside.

 

[Rodolfo]

@SubnetMask I'm very sorry about that, I think that I can explain it better.

If you want to make "anyone with the link" more secure I understand why you want a min 16 char length string, but to base security access in getting a larger public id is too simple brittle security. The id encode system is meant for URL vanity purposes, is not for making your content more/less private.

As the purpose of the id encode system in Chevereto is to produce the shortest encoded id possible, you are basically asking us for the complete opposite of it. This algorithm doesn't support min output width configuration, and I won't change it because I don't have any intention to break it 💀.

Scenario 1: chv.variables id_padding = 999



Scenario 2: chv.variables id_padding = 1000000



^^^ Even using large padding number ir produces a short string, because that's the purpose of the algorithm and that was the need of the users back then. The id_padding thing multiply/divide the target number, that's why it shifts two orders of magnitude when going from 999 to 1000000.

To get a safer "anyone with the link" thing we must implement an extra hash, something like &sec=<HASH> or keep the existing thing but introduce the concept of "anyone with a secured link".

I've created this RFC to initialize the process to get this into the core: https://chevereto.com/community/threads/make-anyone-with-the-link-safer-alternative.16330/