public export share folder #84
Comments
|
I've seen this approach used in some similar servers, and it's not a bad idea -- but at the same time, copyparty already has the dirkeys/filekeys features, which are somewhat similar to this... I'm just not sure how well it'd work with authentik. Is it possible to configure authentik to allow access to copyparty even though the user doesn't have a valid auth? As in, authentik would authenticate all users that it knows about, but in the event that someone doesn't have a valid auth, it'll still let people through, but then without including any auth headers to indicate that the user was authed? This would allow us to use the existing dirkeys/filekeys options, and it would be safe as long as your copyparty volumes are configured to only allow access from users/groups that it knows about, so any unauthorized users would still get rejected and sent to the "login" page. However, if you then also enable dirkeys, and an unauthed user were to provide the right dirkey in the url ( ...but that said, there are some strong advantages to your suggested solution, since it's far more flexible -- the control panel could show a list of your shares and allow you to revoke them at any time, and it would be possible to share a folder with a subset of your own permissions (read-only, write-only, ...). Meanwhile, dirkeys/filekeys are entirely static, so they'd be tricky to revoke if they were to go astray, and they only allow read-access. So it's tempting to give it a shot :> |
|
I'm not sure it is possible to do as you've suggested with authentik, thats why just bypassing authentik entirely is usually the best play you could possibly create a dummy user like guest/guest but then thats an always authenticated user so kind of defeats the purpose i need to look more into the structure of the dirkeys / filekeys, because its possible that might work with some regex if its repeatable. traefik is pretty powerful on matching criteria, for example these are my bin (selfhosted pastebin) traefik rules which i use to lock everything except the viewing of pastes behind an auth screen its possible something like this could also be done, i will go and read more documentation on how dirkeys / filekeys work, but it seems a little sparse from my reading so far (are these g / dk / y flags declared in the config file?) |
|
Right, hmm... I guess this won't work then, because as soon as you enable dirkeys, all URLs are transformed to contain the correct dirkey (for sharing purposes), so even privileged users would be using the dirkey URLs to navigate around on the server. So if the presence of a dirkey is enough to get you routed past authentik, then you wouldn't be getting your intended privieges as admin. So that kinda settles it I guess 😁 I'm not sure when I'll get a chance to work on this, but it's on the list! |
|
Hey, it took a while but it's out now: https://github.com/9001/copyparty#shares I made some conservative choices which i hope aren't too limiting:
However, the following should be all good:
let me know if you hit any issues 👍 |
i'm struggling to get the syntax of this down i've tried placing
i read the documentation you linked which said since the help info said i tried various iterations of which then all came back with errors similar to any ideas what im doing wrong? edit: figured it, it was |
|
so im still not seeing the option to share anything, do i need to be logged in / using the user login features? |
|
yup! the share feature is disabled for anonymous users, since that implies you already have read-access without authentication. I assumed this would also be the case for IdP scenarios, since the IdP would provide the username in a http header. if this doesn't fit your usecase, I can add an overload to allow creation of shares for guests as well. |
i make use of the authentik forward proxy, so it effectively is transparent for the user, since authentik sits at the very front and if they don't have a login it won't forward them to the cpp authentik works by placing in the cookies the successful auth encrypted string i created a user and the share menu appeared now, but i then got presented with the following error
|
|
oh dear, that's what i get for only testing with Firefox... guess i've made a typo that Firefox doesn't mind, but chrome is more picky. I'll get that fixed tonight 👍 but I'm worried that your setup doesn't tell copyparty the username of the user; this is going to break a lot of assumptions I've made. For example, users will be able to see and cancel each other's uploads. Could you enable logging of http headers for your copyparty instance and see if there's any sign of a username in there? you can do that with the following statement inside the
or alternatively, as commandline argument |
i obfuscated the logs a bit to remove important info but if you need some better examples with populated dummy data i can provide them, this was with me logged into cpp when logged out, i can only see the authentik related username stuff but i'm not sure if the application itself is aware of that, the headers that are used are this is the forward auth documentation for authentik i've tested it out on firefox and the implementation works great as a minor QOL idea, could you pre-populate the share name with a random string as if the random button was pressed? it shouldn't be too much of a hassle for the user to delete it, and it would save them having to click the button each time (or maybe some kind of random always flag in config) i'll try create a share now and access it unauthed |
oh that's something i forgot to document -- if you click "create share" without any text in the name field, it does exactly that :> the reason was to keep the name-field empty, so it's easier to fill in a custom value if you wanna do that. Should mention that in the tooltip for the name-field, unless you have any better ideas?
I think this is what we're looking for -- if you provide this header-name instead of the example but there's some more things we should look at,
your reverse-proxy is telling copyparty that your IP (the IP you sent the request from) is However there's one more thing I'm wondering -- is it true that the IP you sent the request from is actually the reason I'm asking is because copyparty needs to know the correct IP and username of each user to function correctly. |
|
ah ok if it generates a random string then its all good one thing that i have encountered, is that when i first made my first share i got a nice popup offering me the link unfortuantely for any subsequent share creation, that menu isn't coming up anymore also theres another issue, which im guessing shouldn't be too dififcult to solve i just need to find the elements that need to be loaded, but this is how the menus look when i access the public shares now lol
this is of course because the elements themselves are locked behind an authentik login screen and an external user doesn't have authentication for them are all the UI related js locked behind /.cpr/? for example i see /.cpr/browser.css?_=w04D i'm trying to whittle it down to the concept of least privilege |
|
hmm i added to the my entire file being now im getting this error |
aight, I'll take a look at that too 👌
yeah, at minimum you'll want to allow all traffic to regex the reason I'm being specific about "only files with a file extension" is because the .cpr folder serves a few other purposes as well;
so it depends on your config , but with the default settings it'll be fine to just allow all access to all of .cpr as well. Note that the list above uses glob-syntax for the paths, let me know if you need help with a regex alternative if you wanna be that specific :>
heh, yep that sounds like a bug (luckily isolated to just this new feature) -- thx, I'll take a look tonight 👍 don't have access to the code rn |
|
https://github.com/9001/copyparty/blob/hovudstraum/copyparty/authsrv.py#L1340 i think its replacing the dashes in edit: ignore me, stripping it out doesn't resolve it |
|
is it possible to remove this login prompt? if you attempt to access a share which doesn't exist then you are presented with this but ideally it would be better if that login for more was placed behind its own login page, so i can place authentik in front of it |
yes, but that is where you type in the password to view a password-protected share :p the way the shares work internally is that they pretend to be volumes, so they use the regular login system if they have a password. That felt like a much better approach than reinventing a lot of access-control stuff, even if it looks a bit funky hehe but I just realized that it's entirely possible to provide an alternative "login" screen, and show that instead when you're trying to access a share instead of a regular password-protected area, so I'll add that 👍 thx! |
|
this was the set of labels that seem to work for me, the hope being that it adds a bit of a stop on trying to directory traverse just in case, since you can't hit another issue i noticed, is that when i created a share - it seems to display all the other directories (which i'd assume shouldn't be visible for a user visiting via a share link) if they attempt to navigate to them, authentik would deny them so it works fine but ideally those top level directories shouldn't be listed at all
additionally whilst the logic for the empty name field for the share being a random string makes sense when a nice feature to the shares panel would be being able to either mouse over or just inline convert the unix timestamp into local timezone stuff, as well as being able to click a button to extend the time period by the original set duration (so if it was set to expire in a day, then clicking once would increment it by 1 day, clicking twice by 2 days etc) finally the post share creation menu which allows you to copy to clipboard has returned, i've confirmed the reason why is that the up2k file indexer prevents the creation of shares during its scan period - whether this is a desired behaviour i have no clue, i'd guess not? |
I'm sorry to say that this will not be a bulletproof way to prevent unintended access outside the shares; or at the very least you shouldn't expect that to be the case, even if it possibly might be right now... We're coming back to my concerns that copyparty needs to know the user's IP and username to function correctly, even if you're authenticating through an IdP. The HTTP API is designed around this assumption. In order to prevent unintended access, you'll need to configure your volumes to only allow access for a list of trusted users, or a trusted group of users. When configured correctly, the IdP can provide all of this dynamically. I'm not an expert on this topic, but maybe we can figure this out together -- going back to the example idp config, we have this part: [/] # create a volume at "/" (the webroot), which will
/w # share /w (the docker data volume, which is mapped to /srv/pub on the host in docker-compose.yml)
accs:
rw: * # everyone gets read-access, but
rwmda: @su # the group "su" gets read-write-move-delete-adminthat creates a volume which is read-write-access for unauthorized users, but read-write-move-delete-admin for all members of the IdP usergroup if you remove the
good idea -- although it'll be a bit trickier to pull off than the current approach, it shouldn't be too bad -- I'll give it a go!
absolutely, the shares listing was thrown together in a rush so I didn't really stop to think xD
interesting idea, I'll check it out.
aw man, yeah you're probably right. That's a limitation of the current design -- this one runs deep and might be real tricky to do anything about... sorry heh I'm still not quite home so haven't started looking at any of the issues, might at least get a beta up tonight to fix the biggest issues, let's see :> |
|
alright, got to at least fix some of the stuff --
I posted a beta image on dockerhub, so you can pull
|
* crash when root volume is unmapped * rephrase login-page for shares * add chrome support (lol) * fix confusing helptext * improve ux * placeholders in share creator * button to disable expiration in share creator * human-readable timestamps in share listing
if files (one or more) are selected for sharing, then a virtual folder is created to hold the selected files if a single file is selected for sharing, then the returned URL will point directly to that file and fix some shares-related bugs: * password coalescing * log-spam on reload
|
should be better now, the only thing I didn't get around to is the buttons to increase the expiration time from the shares listing -- and there's the thing about up2k indexing blocking the creation of new shares, gonna have to think about that one... another time heh as usual, let me know if you hit any issues :> |
The way I use copyparty is situating it behind authentik, so i don't have to do any of the worrying about authentication, and let authentik do that. (alongside a reverse proxy + cloudflare) i'm sure this is common for most people.
It would be nice if we could easily create a one time use or time gated online share, located at a different address (maybe even password protected / prompted) and my friends could then share things with their friends on a one time basis.
the way i image this would work, is that each folder or file has a share button. upon clicking that you are presented with a prompt to place; 1. a password, 2. the length of the share existence, (x minutes, hours, days, weeks, months) 3. one time use download checkbox. all of these would be optional settings.
upon clicking share, a new random string (maybe something like 12 digital alpha numeric) will be created at https://copyparty.example.com/share/{random_string}
this would then allow us to create specific public whitelists for the /share/* on our reverse proxies so that they don't go through the authentication process. it doesn't specifically have to be /share/ it can be user defined or hard coded - just something that is consistent so that we can bypass authentication apps
this could also further be customised with server settings that prevent say the base directories from being shared, or putting an arbitary limit on the total size that can be shared but those two seem niche and more effort - its likely that if the person who is sharing these things with their friends, they can trust their friends not to then not share everything to the world
Describe any alternatives you've considered
i've considered using various other apps to do this instead, but its way more a hassle since it would require replicating the files, instead a copyparty native solution is the ideal medium
The text was updated successfully, but these errors were encountered: