How can I hide the "New share" button on the /share-download url?

[iahim]

Hi, I want to share files with my client, but i do not want him to be able to create new shares using my server.
I have tried to protect (using apache+proxy) the /share-create endpoint using .htaccess but it somehow fails:

• if i access the /share-create directly in the browser the .htaccess works, and the url is protected.
• if I send a file to my client, he can download the file, but also he can click the New share button and he can create a new share (the .htaccess does not kick-in, since the page is not reloaded).
  So how can I protect the new share button and/or hide it from the download page?
  Thanks in advance !

[epoupon]

Hello!
The easiest solution would be to set up an upload password.
Otherwise, you would need user management #64 which is planned but not here yet

[epoupon]

Yes indeed, they can try to brute force the upload password, but this should not be that easy as there is a 1s throttling for each attempt.

[iahim]

Hi, I do not think you understand my question. Above image is what the client gets - so he can download a file if they have the password - that is perfect.
The problem is that even if they have or have not the password, they can create a new file-share. I want that the client can ONLY download files and they are not allowed to upload files.

[epoupon]

There are two kind of passwords: a download password you can set (or not) for each share you create using the web interface. And an upload password that is set using the fileshelter config file, and that must be provided each time you want to create a share (see

fileshelter/conf/fileshelter.conf

Line 22 in 4b8d1a2

# Required password to upload files. The user must provide one of the specified passwords to upload files

)
What I am suggesting is that you setup an upload password. Your clients will be able to click on "New share" but they will have to enter an upload password to upload files.

[iahim]

Ohhh THANKS - I did not know there is the option to password protect the upload. That is perfect. Thank you kindly ! I will try that right away.

[iahim]

It worked - I managed to mount the /etc/fileshelter.conf inside the docker container with a pass for the upload section.
One very cool thing would be to have the option to load passwords from a YAML file (for example), so we could enable/disable the upload passwords without the need to reload the entire docker container. Is just a thought. Many thanks for your reply and help!

[andymarden]

#101 - that has been pulled in to the develop branch so should be in the next release

There is a new config entry:

show-create-links-on-download = true;

Set that to false and this does exactly what your original point asked for.

FYI - what I also do is have my fileshelter behind a reverse proxy and use authentik to have anyone unauthorised prohibited from going to any fileshelter page apart from the download one. My nginx config is:

# Fileshelter
server {
listen 443 ssl http2;
server_name fileshare.example.org;
proxy_request_buffering off;
proxy_buffering off;
proxy_buffer_size 4k;
client_max_body_size 10G;

location /share-download {
proxy_set_headerHost $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

proxy_pass http://fileshare.home:5091;

proxy_read_timeout  120;
}

location / {
proxy_set_headerHost $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;

proxy_pass http://fileshare.home:5091;

proxy_read_timeout  120;

##############################
# authentik-specific config
##############################
auth_request     /outpost.goauthentik.io/auth/nginx;
error_page 401 = @goauthentik_proxy_signin;
auth_request_set $auth_cookie $upstream_http_set_cookie;
add_header Set-Cookie $auth_cookie;

# translate headers from the outposts back to the actual upstream
auth_request_set $authentik_username $upstream_http_x_authentik_username;
auth_request_set $authentik_groups $upstream_http_x_authentik_groups;
auth_request_set $authentik_email $upstream_http_x_authentik_email;
auth_request_set $authentik_name $upstream_http_x_authentik_name;
auth_request_set $authentik_uid $upstream_http_x_authentik_uid;

proxy_set_header X-authentik-username $authentik_username;
proxy_set_header X-authentik-groups $authentik_groups;
proxy_set_header X-authentik-email $authentik_email;
proxy_set_header X-authentik-name $authentik_name;
proxy_set_header X-authentik-uid $authentik_uid;
}

# all requests to /outpost.goauthentik.io must be accessible without authentication
location /outpost.goauthentik.io {
proxy_ssl_server_name on;
proxy_pass https://authentik.home:9543/outpost.goauthentik.io;

# ensure the host of this vserver matches your external URL you've configured
# in authentik
proxy_set_headerHost $host;
proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
add_header Set-Cookie $auth_cookie;
auth_request_set $auth_cookie $upstream_http_set_cookie;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
}

# Special location for when the /auth endpoint returns a 401,
# redirect to the /start URL which initiates SSO
location @goauthentik_proxy_signin {
internal;
add_header Set-Cookie $auth_cookie;
return 302 /outpost.goauthentik.io/start?rd=$request_uri;
}
}