[bug] can't edit storage configuration

[zhqu1148980644]

Description of the bug

1. docker-compose up -d the docker-compose file in this repo.
2. visit the admin page
3. add storage backend
4. can not edit the beckend configuration(user,pass...)

Can you replicate that error from the demo?

no, have no access to admin page

Observed behavior

Expected behavior

Can edit the configuration of each storage backend

[espressoelf]

Seems to be since the rewrite of the admin control panel. In the meantime you could check /server/plugin/plg_backend_*/index.go for the params the backend takes before editing the configuration manually. Not the most comfortable way but it's free self-support.

[mickael-kerjean]

I can't seem to replicate this. can you replicate this in the latest version?

[espressoelf]

I just pulled the latest image and it still looks like that. Looking at the source in Developer Tools (F12) there is nothing else displayed and the console doesn't show any error. I also don't see anything looking like an error in the container's logs.

[mickael-kerjean]

I am not able to replicate this. Can you share your docker compose file and make a screenshare to see the problem in action?

[zhqu1148980644]

I am not able to replicate this. Can you share your docker compose file and make a screenshare to see the problem in action?

The latest docker-compose.yaml file in this repo:

version: '2'
services:
  filestash:
    container_name: filestash
    image: machines/filestash
    restart: always
    environment:
    - APPLICATION_URL=
    - GDRIVE_CLIENT_ID=<gdrive_client>
    - GDRIVE_CLIENT_SECRET=<gdrive_secret>
    - DROPBOX_CLIENT_ID=<dropbox_key>
    ports:
    - "8334:8334"
    volumes:
    - filestash:/app/data/state/


volumes:
    filestash: {}

[mickael-kerjean]

The image isn't enough to replicate the issue you're seeing. Can you send a video or something to show the behavior you are seeing? I really need to replicate whatever you're getting to provide a fix

[espressoelf]

I started from scratch, which means I downloaded the docker-compose.yml and edited it like below:

version: '2'
services:
  app:
    container_name: filestash2
    image: machines/filestash
    restart: always
    environment:
    - APPLICATION_URL=http://192.168.0.6:8334
#    - GDRIVE_CLIENT_ID=<gdrive_client>
#    - GDRIVE_CLIENT_SECRET=<gdrive_secret>
#    - DROPBOX_CLIENT_ID=<dropbox_key>
#    - ONLYOFFICE_URL=http://onlyoffice
    ports:
    - "8334:8334"
    volumes:
    - filestash:/app/data/state/

#  onlyoffice:
#    container_name: filestash_oods
#    image: onlyoffice/documentserver
#    restart: always
#    security_opt:
#      - seccomp:unconfined

volumes:
    filestash: {}

I usually use Traefik as reverse proxy, this time I didn't do that. Afterwards I pulled the latest image and made sure there is no old filestash volume. Note: I usually use directories and not volumes.

docker pull machines/filestash # pulls :latest for amd64
docker volume rm filestash
docker-compose up

The server starts as usual:

Creating filestash2 ... done
Attaching to filestash2
filestash2 | 2023/10/20 13:08:41 SYST INFO Filestash v0.5 starting
filestash2 | 2023/10/20 13:08:41 SYST INFO [http] starting ...
filestash2 | 2023/10/20 13:08:42 SYST INFO [http] listening on :8334

I visit http://192.168.0.6:8334 in the browser, set an administrator password, click away the crash report message and get the following summary:

• SSL is not configured properly: This can lead to data leaks. Please use a SSL certificate
• Application is running as 'undefined'
• Emacs is installed
• Pdftotext is installed

Then I visit "Backend" and get the default pre-selected list of backends (WebDav, FTP, SFTP, GIT, S3, DROPBOX, GDRIVE), all with just their names configurable. Meanwhile, the log fills up with access logs. No errors or anything unusual.

Sorry it isn't a video, but I tried to be as detailed as possible while also keeping everything as untouched as possible. Is there anything special we could try?

[battarra]

I'm also encountering this issue with the latest version, a short video right after startup of filestash :

https://github.com/mickael-kerjean/filestash/assets/12116466/f065fb04-aa03-4656-8e11-edae88452a6d

• same docker-compose.yml as in the previous comment, with latest image (sha256:3fd53de85dc6fe96bff5af1d8d9b4577c0fe68cd6bae324d11a084412f17d3c1)
• reproduced on deployment via Docker as well as k8s with SSL correctly set up
• tested on Windows: Brave, Firefox and Edge and Linux: Chromium

Thank you for looking into this !

[mickael-kerjean]

I am still not sure to understand, what is the issue in the video ? You were able to select / deselect the storage backend and the loading spinner came to life showing the state was being changed successfully. Can you go onto more details about what you think is an issue?

[battarra]

I understand now - the settings that used to be under backend options are now delegated to the 'Authentication Middleware' settings. Very sorry, I upgraded from an old version and read the documentation too quickly ! All good for me.

[mickael-kerjean]

Hoo that must have been a very old version then. Yes those have changed as the previous way had a couple footguns by design that a few people got straight in and I didn't have a way to talk to those people to even let them know their instance had major issues.

The auth middleware is an attempt to enable the exact same use case as before but without any of the footguns. You should be able to configure things exactly as before from the doc using the passthrough auth middleware.

[battarra]

Many thanks for your answer ! One more question re: replacing the storage configuration with middlewares. If I am not wrong, it is currently not possible to configure middlewares for multiple backends - I seem to be able to pick only one middleware and also have it work only for one backend at the time. For example, if on the admin page:

• I have backends BackA and BackB
• I add middleware and set 'Related Backend' to BackA

Then, on the login scree, BackA goes through the middleware, but BackB is the 'naked' version without attribute mapping. If I switch the 'Related Backend' to BackB, then BackA goes 'naked'. Could you confirm that this is the current status of the functionality (vs an issue in my self-hosted setup)?