Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE REQUEST] Customized and editable names for files #381

Open
flatypus opened this issue Jun 10, 2023 · 5 comments
Open

[FEATURE REQUEST] Customized and editable names for files #381

flatypus opened this issue Jun 10, 2023 · 5 comments
Labels
feature Things that would be nice to have help wanted Help would be appreciated

Comments

@flatypus
Copy link

The feature:
Currently, links for files are created with randomized names. It would be beneficial in certain cases for someone to be able to edit the name of a file to something memorable, assuming the name has not been used under the same domain.

What could be done to make this happen:
Be able to edit the file name to a different name, and query to check if the name is available for use. If it isn't, offer similar names that are available. For example, https://doma.in/1qzk6qq9m8cf.mp4 => https://doma.in/special_name.mp4

Additional context:
I've been considering forking and writing something like this for a while, would this be something you guys would be considering adding/open to merging? Either way, I'll try working on something on my own time.

@Pitu
Copy link
Member

Pitu commented Jun 10, 2023

Definitely interested in this. We are 2-3 days away from a major release that rewrites the entire codebase to make it easily extendable, so once that is done it would be great to have this feature.

@Pitu Pitu added help wanted Help would be appreciated feature Things that would be nice to have labels Jun 10, 2023
@flatypus
Copy link
Author

Hi! Finally got around to working on the PR for this, my active fork is here:
https://github.com/flatypus/chibisafe/tree/rename-files

I did want to clarify something in the meantime though; right now, I'm exposing a route that lets a user attempt to rename a file as long as they own it, but it also checks if a file with the same name already exists on the safe, possibly with another user.

Do you think this could potentially be a security issue, giving files a potentially guessable name, or should we assume that if a user renames their file to, say, doma.in/abcde, they assume the risk that someone could also go to that link and find their file? Or do you think there's a better way than this?

@Pitu
Copy link
Member

Pitu commented Feb 25, 2024

Thanks for coming back to this @flatypus.

This is something we've talked about a bit with @iCrawl a few days ago.
We've still haven't found the best way to do this, but I think there are 2 important scenarios that this feature can cover and it really depends on the functionality you are looking for:

What is the purpose of renaming a file?
If it's simply about having a vanity URL to a file like chibisafe.moe/best.jpg for the sake of just vanity/showing off then sure, we can rename files but 2 files with the same name can't coexist. And you assume the risk of this file being guessed since you bypassed the random filename.

Now if the reasoning behind the custom/original filename is to be able to download a file and it being recognizable once you download it, I think a different approach might be better.

Let's say you upload chibisafe-installer.exe and its renamed to chibisafe.moe/spbneywb.exe. If you were to open this link, it would be sus af. Would definitely not be able to share this as most likely no one would like to click on that link. And even if you did, the file would be downloaded as spbneywb.exe and you would've lost the original filename.

For this last case I think that something we could do is chibisafe.moe/file/UUID and that should trigger the file download with the original name that was saved on the DB instead.

We can have both options. Let people rename files as long as they meet certain criteria like not being able to name it as another already existing file, and let people download them with the original filename.

@flatypus
Copy link
Author

flatypus commented Feb 25, 2024

I see, in that case we should probably discuss the exact plan for implementation before I write a bunch of unusable code lol.

In the first case, I could see two reasons; one is for vanity I guess, but also to have a rememberable name is often useful. I've had cases where I upload a file to my safe, and on another device (that I can't c/p it to) needs to type it out. It would be nice to do like a chibisafe.moe/presentation.pptx, as then I could easily remember and type that. If we want to handle conflicts, an idea could be to do it by user (so .moe/admin/presentation.pptx) and have each user handle their own file conflicts I guess; or we could just do what bit.ly does and allow everyone to set any URL.

With the question of potentially guessable names, I think assuming the risk of a guessable file name is fine. URL shorteners basically have the exact problem anyways. If they really needed to secure the file, then 1. they could just use the randomly generated name; 2. they could risk it, assuming no one finds their custom domain (or remove the file after they're done with it); or 3. we implement password protection for links, which bitly also does, and which I'm a proponent for.

As for your last case, of creating recognizable files, I'm wondering if the storage process could be different altogether. Consider I upload a file with like minecraft.exe. Right now, the file gets saved as like e9P4IfITiti4.exe, served at /e9P4IfITiti4.exe, and downloaded with e9P4IfITiti4.exe. I wasn't able to find a way to do this with fstatic, but if the file could be saved locally at /e9P4IfITiti4/minecraft.exe (or something else), then served at /e9P4IfITiti4.exe (or /{UUID}) and then have an intermediary function call db to return the file with the original filename? It's a bit of a rewrite & outside the scope of this PR, and it's up to what you guys think of how files should be served here, but it could potentially lead to a smoother situation where files retain their original filenames for all uploads.

@TheDogHusky
Copy link

I entirely agree with @flatypus
I would think keeping both the options could be great, allowing people to rename them just as vanity URLs but taking the risk of guessing them and as well save the original name so when people download them it has the original name.
The suggestion with the file names (last paragraph) is really great and we just should decide which option to take. Now we wait for Pitu or iCrawl to answer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Things that would be nice to have help wanted Help would be appreciated
Projects
None yet
Development

No branches or pull requests

3 participants