[docs] setup navidrome with oauth2-proxy authentication - #2357
[docs] setup navidrome with oauth2-proxy authentication#2357zenphonix wants to merge 26 commits into
Conversation
* Add and fix links * Add more comments * Fix typos * Update oauth2-proxy.md and navidrome.md
|
One thing that didn't make it into this PR is supporting a different path_prefix. The idea is to adjust the rule as such: But this results in a double slash with the default config. In defaults.yml the path_prefix is conditioned:
This seems to be standard for all roles but I rather think that it complicates code and demands an additional test, as one does not know whether to expect a trailing slash or not. If either the default would be an empty string or values are demanded to end with slash, this would simplify formulations as above and make them more readible. Kind regards! |
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
luixxiul
left a comment
There was a problem hiding this comment.
First round of review is done. Would you please address the comments?
Especially the section "Navidrome configuration adjustments" seems to need some adjustments.
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
|
Thank you for reviewing so swiftly! Apologies for the delay, the notifications did not reach me. I will address the suggestions in the threads. |
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
| ######################################################################## | ||
| ``` | ||
|
|
||
| ### Securing Navidrome behind OAuth2-Proxy |
There was a problem hiding this comment.
Do we need this whole section in the first place, because it looks mostly identical to the instruction on oauth2-proxy.md ?
There was a problem hiding this comment.
The section in navidrome.md is more detailed, whereas oauth2-proxy.md contains just the essentials.
There was a problem hiding this comment.
I'm sorry, but I still do not see any difference between the code blocks in this section on oauth2-proxy.md and this section on navidrome.md.
There was a problem hiding this comment.
The sections are not identical, but the code blocks with navidrome variables and the preceeding notes are indeed identical in both documents. I think they should be identical out of consistency even if they serve different purposes:
- In
navidrome.mdthe section serves to guide the setup process and configure OAuth2 for Navidrome - In
oauth2-proxy.mdthe section serve as a real-world example of how to use OAuth2-Proxy, such that the person reading it can adapt the configuration for his use-case
Nevertheless the code blocks should be identical to maintain consistency and avoid confusion, as the particular configuration serves the same purpose for the navidrome setup, namely providing a fully-functional OAuth2 authentication method.
Why should they be different?
I mean, of course we could delete the sections in oauth2-proxy.md and refer to the section in navidrome.md for a sample configuration, but doesn't it make it easier for a reader to have all relevant information including sample config in one page? If you take the samples out, the page would be almost bare and lack what in my opinion is most interesting for someone who is setting up oauth2-proxy for the first time. Additionally, if you out-source the sample to navidrome.md, somebody who sets up a config for a different service will need to read through Navidrome-specific information that is unrelated to his purpose.
There was a problem hiding this comment.
Doesn't it make it easier for a reader to have all relevant information including sample config in one page? If you take the samples out, the page would be almost bare and lack what in my opinion is most interesting for someone who is setting up oauth2-proxy for the first time.
Not every user who is looking for OIDC authentication on Navidrome is going to use OAuth2-Proxy. Someone who prefer Authelia or authentik for example would not find it relevant anyway.
The example on oauth2-proxy.md is enough for those who are motivated to set up OAuth2-Proxy. It is a complicated system in itself (not something like Pocket ID), and they will (need to) study the example and adjust it for the services they are using, whether Navidrome or not. If anyone does not have the will to study documentation, well I think the person is not really qualified to try OAuth2-Proxy to begin with, or they use LLM to try something which they cannot tell whether it is really correct or not.
Because your example on oauth2-proxy.md seems informative and to be able to be applied to other services with some tweaks (otherwise it would not be the example anyway), honestly I cannot see substantial merit of having the very same (and complicated) snippets on the two pages, unless there would be a reason why the sample instruction about OAuth2-Proxy must be put on navidrome.md, not on documentation of other bunch of services which can be used with OAuth2-Proxy. There is a high chance of inconsistencies due to upstream changes in a future, which you will have to sort out.
Note that the section for the file management features Syncthing because file management is essential for using Navidrome and the documentation on other services features Syncthing too.
There was a problem hiding this comment.
I am at a gathering right now, where is very little internet access and little free time to be on the computer, so my communication might be delayed.
There are few alternatives to OAuth2-Proxy in the case of Navidrome. For services behind Traefik, forwardauth module is frequently used.
Authelia and authentik are not an alternative to OAuth2-Proxy! The first two are OIDC Providers, but OAuth2-Proxy is a OIDC client! It handles delegated authentication for a service that cannot handle it natively. In this sense, it is very relevant for setting up OIDC for Navidrome, even more than Syncthing is for file management (for which there are much more alternatives than for OAuth2-Proxy - personally I let Nextcloud manage files for example).
There was a problem hiding this comment.
But I get your point. When I find some time, I will look into it and propose a solution.
There was a problem hiding this comment.
I see, I am not really familiar with OAuth2-Proxy, thanks for the info (though I did not claimed Authelia or authentik would be alternative to OAuth2-Proxy).
My point about not repeating the exact snippet on navidrome.md still stands, let alone the fact that Authelia and authentik can be used with Navidrome for authentication anyway, regardless they are not same as OAuth2-Proxy, which is a OIDC client; it does not really matter on this context, right?
Let's keep the documentation simple. The documentation is not layman's guide.
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
|
What else need to be done to satisfy the requested change? |
|
Please see this comment: #2357 (comment) |
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
A thorough guide to how to setup oauth2-proxy as a OIDC provider for navidrome via Externalized Authentication + some minor corrections
oauth2-proxy.mdfrom hubsite to navidromenavidrome.mdI have been using this setup since a month and can confirm that all works fine. Navidrome is secured, while subsonic end share endpoints are exposed and working as expected.