[Feature Request] Support all notes on Specific Path for excluding from authentication

[nvroot]

What type of request is this?

New feature idea

Clear and concise description of the feature you are proposing

Is there a way to configure authentication globally for all paths while allowing specific paths to be excluded and marked as unauthenticated with all notes on this path?

For example:

Authentication required: site.com/any-path (default behavior)
Unauthenticated paths: ^/unauth-path
Additionally, all notes inside unauth-path should be accessible without authentication, such as:
site.com/unauth-path/xxxxxxxx#pw:xxxxxxxx-xxxxxxxxxx-xxxxxx-xxxxxxxxxx

Is there an existing way to achieve this, or would this require custom configuration?

Additional context

No response

Validations

• Check the feature is not already implemented in the project.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
• Check that the feature is technically feasible and aligns with the project's goals.

[CorentinTh]

Hi @ssqlone
Thank you for the suggestion 🙏

The approach you're proposing, having an "un-auth" feature that allows someone to view a note without authentication, would completely bypass the authentication mechanism and significantly impact security.

[CorentinTh]

Related to #404

[nvroot]

Hi @CorentinTh ,

Thank you for the quick response!
I’m not suggesting any changes to Enclosed’s authentication or authorization mechanisms. My request is simply to have the option to move all notes from enclosed.site/notetoken to a structured path, such as enclosed.site/somepath/notetoken, without touching Enclosed’s existing mechanisms.

Many authentication tools—such as Authentik, Authelia - as well as reverse proxies like Nginx and Traefik, support regex-based unauthenticated path exclusions. Changing the path structure would enhance compatibility with these tools, providing more flexibility for defining precise authentication rules.

Would love to hear your thoughts on this!

[CorentinTh]

Oh, I see, my bad for the misunderstanding!
I think adding a configuration option to prefix the note URL path should be doable
Just to confirm: would this only apply to the "view note" URLs?

[nvroot]

@CorentinTh Yes, it would only apply to the "view note".

[CorentinTh]

Implemented in #418 and released under the 1.15 version

You can now configure the "view note page" path prefix using PUBLIC_VIEW_NOTE_PATH_PREFIX, for exemple :

PUBLIC_VIEW_NOTE_PATH_PREFIX = foobar

new notes will be accessible at the url :

http://yourinstance.example/foobar/01jpz7kazfwd7n0x7ta0rx#dB28vtGK21zyryVHHD7eYNXaR

[ToshY]

@nvroot @CorentinTh

I've encountered this problem in #210 and was still waiting for a fix and I now find that it's fixed in 1.15.0, but could either one of you elaborate on how to configure this, as I do not think it works out-of-the-box with the information provided in either the issue or #418 .

The /api/notes (GET) is required in order to read notes, and the only way I've managed to get this to work with Traefik is by adding to the rule /foobar, allow just GET method and the /api/notes endpoint.

services:
  enclosed:
    environment:
      PUBLIC_VIEW_NOTE_PATH_PREFIX: foobar
    labels:
      traefik.enable: true
      traefik.docker.network: proxy
      traefik.http.routers.enclosed.tls: true
      traefik.http.routers.enclosed.entrypoints: websecure
      traefik.http.routers.enclosed.rule: Host(`notes.${APP_DOMAIN}`)
      traefik.http.routers.enclosed.service: enclosed
      traefik.http.services.enclosed.loadbalancer.server.port: ${ENCLOSED_PORT:-8787}
      traefik.http.routers.enclosed.middlewares: oauth@file"
      # Anonymous read
      traefik.http.routers.enclosed-read.tls: true
      traefik.http.routers.enclosed-read.entrypoints: websecure
      traefik.http.routers.enclosed-read.rule: Host(`notes.${APP_DOMAIN}`) && Method(`GET`) && (PathPrefix(`/foobar`) || PathPrefix(`/api/notes`))
      traefik.http.routers.enclosed-read.service: enclosed-read
      traefik.http.services.enclosed-read.loadbalancer.server.port: ${ENCLOSED_PORT:-8787}

This allows for anonymous reading of notes at notes.example.com/foobar and the user will not be able to create a new note. The user can however still navigate to the note creation page (through "New note" in navbar), and can also click on "Create note" button, but the request will fail as it is not authenticated (as it should be).

While I personally do not like that an anonymous user can still navigate the application to the note creation page, it's already a step forward that they cannot create new notes.

Is there a better way to handle this?