Guess it contains code from another pr ? too?

oops...

Hmm would this not mean that we change the title of the folder to an id which no one can understand?

Yes. But if the username is changed the files of that user are lost and the user can't access his/her files. Unless the folder name is also changed offcors..

Unless the folder name is also changed offcors

Bad idea unless you're also going to fix all of the content referencing that file path. ID is more consistent, what is the issue with using it?

@mbabker good point. Except what @zero-24 says, I don't see issues with using id's instead of usernames

Isn't that feature already possible with the regular mediafield (eg in articles)? Not sure but I think I remember seeing something like that once.
If so, then it has to behave the same in the custom field.

I'm more of a fan of username, with id's you can guess the next user folder too easy. But there is a third alternative, adding an option to the field which scheme should be used to create the folder, ID or username. Just an idea.

I have tested this item ✅ successfully on 6844fa5

Joomla! 3.7.0-alpha2 dev

What is the problem with guessing the user ID? Images folder is always public.

Making it a option might be a good idea. But than you still have a possible break when you like to change a username

Yes but at least, the user has decided to use that scheme.

test successful but i fear security issues as you can read out then the userid if you access images/42 or images/73 whatever. So username and userid are not good solutions.

cc @SniperSister

I have tested this item ✅ successfully on 6844fa5

! please see my comment !

@coolcat-creations Google is also allowed to look in that folder. Also if you have some secrets to hide, you don't hide them in a random folder. So I don't think it is a security leak. Because secure image should not be saved in a publicly accessible area / folder

@n9iels the security issue is not related to the fact that one can guess image paths but the fact that one can systematically crawl through those directory and get a list of user IDs with this. These user IDs can be used for other attacks using attack vectors like SQL injections.

There is btw a PR to remove the Home Option at all #13893

@SniperSister why not mapping the id and some uniqid() value into database?

That's a possible solution, even though I don't like the idea of an extra database call that might be necessary in some situation if only the user id is available.

Hmm hashing the userid even with salt does not make much sense either.. (Hashed) Usernames can be changed and even as we have plugin events for these, it's not nice updating folders.

So maybe an uuid in the users table is the most efficient way to go.. This could be helpful for a lot of places where we currently use the user id publicly (com_contacts etc.)

JFactory::getUser()->uuid, JFactory::getUser($uuid)

As always any solution has ups and downs..

There is another discussion going on #13878. Perhaps we should remove that option as in PR #13893. More and more I have the impression that confuses people more than it helps.

Closing as the feature is removed from the core now :)