sigoden/dufs
1
0
Fork 0
mirror of https://github.com/sigoden/dufs.git synced 2026-04-08 16:49:02 +03:00
Code Issues 8 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #617] Auth problems #367

New Issue
Closed
opened 2026-04-08 16:52:23 +03:00 by zhus · 0 comments
zhus commented 2026-04-08 16:52:23 +03:00
Owner
Copy Link

Originally created by @cppbear on GitHub (Aug 18, 2025).
Original GitHub issue: https://github.com/sigoden/dufs/issues/617

Problem

There appears to be a significant regression in permission handling in Dufs v0.44.0 compared to v0.43.0. The read-only (ro) permission for anonymous users is not being enforced, and multi-user authentication seems to be broken.

I have observed two related issues:

  1. Read-Only permission is not enforced:

    • Expected behavior: When starting Dufs with dufs -A -a @/:ro, anonymous users should only have permissions to browse and download files. UI elements for creating, uploading, moving, deleting, or editing files should be hidden or disabled.
    • Actual behavior: In v0.44.0, an anonymous user can perform write operations, including moving, deleting, and editing files, despite the ro flag. This worked correctly in v0.43.0, where anonymous users were properly restricted.

  2. Login functionality is broken with mixed permissions:

    • Expected behavior: When starting Dufs with mixed permissions like dufs -A -a user:pass@/:rw -a @/:ro, the server should default to anonymous read-only access, but provide a functional "Login" button to allow authenticated users to gain read-write (rw) access.
    • Actual behavior: In v0.44.0, the "Login" button is visible in the UI, but clicking it has no effect. The login modal does not appear, preventing users from authenticating to gain elevated permissions.

These issues have been reproduced on both Linux and Windows systems.

Configuration

The following command-line arguments were used to reproduce the issues.

Scenario 1: Incorrect Read-Only Enforcement

dufs -A -a @/:ro

Scenario 2: Broken Login Functionality

dufs -A -a user:pass@/:rw -a @/:ro

Log

No specific errors are shown in the console log upon startup or during the incorrect operations (delete/move). The server starts normally.

Example startup log for Scenario 1:

./dufs -A -a @/:ro -p 5100
Listening on:
  http://127.0.0.1:5100/
  http://[::1]:5100/

2025-08-18T20:47:03+08:00 INFO - 127.0.0.1 "GET /" 200
2025-08-18T20:47:06+08:00 INFO - 127.0.0.1 "GET /config.yaml?edit" 200
2025-08-18T20:47:06+08:00 INFO - 127.0.0.1 "GET /config.yaml" 304
2025-08-18T20:47:10+08:00 INFO - 127.0.0.1 "PUT /config.yaml" 201
2025-08-18T20:47:10+08:00 INFO - 127.0.0.1 "GET /config.yaml?edit" 200
2025-08-18T20:47:10+08:00 INFO - 127.0.0.1 "GET /config.yaml" 200
2025-08-18T20:47:51+08:00 INFO - 127.0.0.1 "GET /logs/" 200
2025-08-18T20:47:55+08:00 INFO - 127.0.0.1 "DELETE /logs/dufs.wrapper.log" 204

Screenshots/Media

The screenshot for Scenario 1 would show the WebUI for an anonymous user with the 'Delete', 'Move', and 'Edit' buttons visible and functional. These should be hidden or disabled in read-only mode.

Image

For Scenario 2, a screen recording would show the 'Login' button in the top right corner. The issue is that clicking this button produces no action.

Image

Environment Information

  • Dufs version: 0.44.0 (Bug observed), 0.43.0 (Worked correctly)
  • Browser/Webdav info: Microsoft Edge 140, Google Chrome 139
  • OS info: Windows 11 and Ubuntu 24.04 LTS (reproducible on both)
  • Proxy server (if any): None
Originally created by @cppbear on GitHub (Aug 18, 2025). Original GitHub issue: https://github.com/sigoden/dufs/issues/617 **Problem** There appears to be a significant regression in permission handling in Dufs v0.44.0 compared to v0.43.0. The read-only (`ro`) permission for anonymous users is not being enforced, and multi-user authentication seems to be broken. I have observed two related issues: 1. **Read-Only permission is not enforced:** - **Expected behavior:** When starting Dufs with `dufs -A -a @/:ro`, anonymous users should only have permissions to browse and download files. UI elements for creating, uploading, moving, deleting, or editing files should be hidden or disabled. - **Actual behavior:** In v0.44.0, an anonymous user can perform write operations, including moving, deleting, and editing files, despite the `ro` flag. This worked correctly in v0.43.0, where anonymous users were properly restricted. 2. **Login functionality is broken with mixed permissions:** - **Expected behavior:** When starting Dufs with mixed permissions like `dufs -A -a user:pass@/:rw -a @/:ro`, the server should default to anonymous read-only access, but provide a functional "Login" button to allow authenticated users to gain read-write (`rw`) access. - **Actual behavior:** In v0.44.0, the "Login" button is visible in the UI, but clicking it has no effect. The login modal does not appear, preventing users from authenticating to gain elevated permissions. These issues have been reproduced on both Linux and Windows systems. **Configuration** The following command-line arguments were used to reproduce the issues. **Scenario 1: Incorrect Read-Only Enforcement** ```bash dufs -A -a @/:ro ``` **Scenario 2: Broken Login Functionality** ```bash dufs -A -a user:pass@/:rw -a @/:ro ``` **Log** No specific errors are shown in the console log upon startup or during the incorrect operations (delete/move). The server starts normally. Example startup log for Scenario 1: ```text ./dufs -A -a @/:ro -p 5100 Listening on: http://127.0.0.1:5100/ http://[::1]:5100/ 2025-08-18T20:47:03+08:00 INFO - 127.0.0.1 "GET /" 200 2025-08-18T20:47:06+08:00 INFO - 127.0.0.1 "GET /config.yaml?edit" 200 2025-08-18T20:47:06+08:00 INFO - 127.0.0.1 "GET /config.yaml" 304 2025-08-18T20:47:10+08:00 INFO - 127.0.0.1 "PUT /config.yaml" 201 2025-08-18T20:47:10+08:00 INFO - 127.0.0.1 "GET /config.yaml?edit" 200 2025-08-18T20:47:10+08:00 INFO - 127.0.0.1 "GET /config.yaml" 200 2025-08-18T20:47:51+08:00 INFO - 127.0.0.1 "GET /logs/" 200 2025-08-18T20:47:55+08:00 INFO - 127.0.0.1 "DELETE /logs/dufs.wrapper.log" 204 ``` **Screenshots/Media** The screenshot for Scenario 1 would show the WebUI for an anonymous user with the 'Delete', 'Move', and 'Edit' buttons visible and functional. These should be hidden or disabled in read-only mode. <img width="1192" height="428" alt="Image" src="https://github.com/user-attachments/assets/b20e8dd7-f5c5-4fc7-8f89-fa01dc4a3648" /> For Scenario 2, a screen recording would show the 'Login' button in the top right corner. The issue is that clicking this button produces no action. ![Image](https://github.com/user-attachments/assets/d53f44eb-453c-4b98-8ca7-3b0e9f14c07a) **Environment Information** - Dufs version: 0.44.0 (Bug observed), 0.43.0 (Worked correctly) - Browser/Webdav info: Microsoft Edge 140, Google Chrome 139 - OS info: Windows 11 and Ubuntu 24.04 LTS (reproducible on both) - Proxy server (if any): None
zhus closed this issue 2026-04-08 16:52:23 +03:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
zhus
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sigoden/dufs#367
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?