Repository navigation
[feature request] option to disable username/password signup/login #119
Description
Hi there, I just set up a fresh librislog instance for the first time, and loving it so far! This is exactly the piece of software I have been looking for, for a long time. Thank you so much for all the work you do on this amazing project :)
There is one feature I'd like to request. I solely use OIDC to log in to apps, including Librislog. So from a security perspective, I'd like to disable username+password sign ups and logins, when OIDC is configured. Maybe in the form of some .env variables?
Would this be possible to implement sometime in the future?
Reacted by sorryusernameisalreadytaken
Activity
sorryusernameisalreadytaken commentedon Oct 28, 2026
Hi, I have a related use case that might fit this feature request.
I'm self-hosting LibrisLog behind traefik and use traefik's built-in BasicAuth middleware as an additional security layer.
Currently, I have to authenticate twice: once through Traefik and once through LibrisLog.
For ny single-user setup, I'd love to have an optional "Trusted Reverse Proxy Authentication" mode.
Traefik already supports forwarding the authenticated username through a configurabel HTTP header (
headerField). LibrisLog could potentially use this information to authenticate an existing user without requiring a second login.For security, this feature should obviously be disabled by default and only enabled when LibrisLog is exclusively accessible through a trusted reverse proxy.
Would this fit into the scope of this feature request, or would you prefer a separate issue?
Thanks! Especially for your nice project here :)
codebude commentedon Oct 28, 2026
Hi @sorryusernameisalreadytaken , hi @tuxnwhiskers thanks for your ideas. I like them both. As I am using LibrisLog behind Traefik, too and using solely OIDC as login method your environments/use cases a familiar to me.
I'll see to integrate your ideas into the next release.
codebude commentedon Oct 29, 2026
Hi @tuxnwhiskers , hi @sorryusernameisalreadytaken ,
I implemented your feature wishes in #121 which is merged to develop branch now.
You can test the changes either via the Docker image tagged with
developtag or by git checkout of the develop branch and running LibrisLog from code.You can also find description of the features in the nightly docs:
Feel free to post your feedback here. If anything is missing from your point of view, please re-open the issue or let me know.
tuxnwhiskers commentedon Oct 30, 2026
@codebude Thanks for the quick implementation! A bit of feedback: I switched the images from latest to develop, added the
PASSWORD_LOGIN_ENABLED=falsein my .env file and restarted the stack. Then went to my librislog domain. I expected to be redirected straight to my oidc, but had to click the button first. Would an automatic redirect be something your're willing to consider? If not, no issue there, I can live with that.But once I authenticated, I was redirected to http://localhost:5173/api/oidc/callback instead of my domain. Might that be a bug? I didn't come across that behavior while using the latest images. I fixed it by setting the
PUBLIC_APP_URLto my domain, which was at the bottom between the email envariables. But it may have been my own fault and I should've set that env right at the start.Also, I don't know if I should open a separate issue for it, but is it possible for the profile pic to change to the one I set in my oidc application? Because right now I'm stuck with a cat face, and I cannot change it (again, I totally understand this is not something to prioritise, I can happily live with how things are currently).
TLDR; everything works, just some feedback in the 'quality of life' category :)
codebude commentedon Oct 30, 2026
I will consider that as optional/config flag.
I made some changes recently in the redirect handling (See: 58c6119). Until now OIDC guessed the redirect url/used relative paths. This lead to some struggle in multi server/developer setup. But from my point of view the changes should have been non breaking.
What do you mean by that. Did you add PUBLIC_APP_URL with your domain or did you have PUBLIC_APP_URL already in the settings, but pointing to http://localhost:5173?
If it was unset, then we might have a bug. If it was set already, but to the wrong domain, then the code works fine, but it was an config error. But I guess at the end its still my fault, because the .env.example has this line in it. I should update the .env.example and make clear, that it has to be set correctly. (Or add a fallback to avoid breaking existing installations on the next update.)
Please open a new issue for this. I'll have a look then. :-)
Btw. your stuck with the cat as the icon is generated/calculated out of your email address. So every user currently gets a unique avatar. Change your mail, if you don't like the cat. (Just kidding ;-) )
tuxnwhiskers commentedon Oct 30, 2026
I copied .env.example to .env, and the line
PUBLIC_APP_URL=http://localhost:5173was already there.codebude commentedon Oct 30, 2026
I checked what was going wrong. It was my fault. The change in general was fine, but it conflicted with the (somehow stupid) default value for
public_app_urlI defined in .env.exampleI removed the default value from the example file and build a guard logic in addition, that should ensure that other users, when updating (and having set the default value), do not face the same problems as you.
Changes are part of #123 which is merged to develop branch and ready for testing/feedback.