mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 00:29:48 +03:00
$_SERVER_REMOTE_USER authentication #1784
Reference in New Issue
Block a user
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?
Originally created by @tiredofit on GitHub (Jul 9, 2020).
Describe the feature you'd like
Adding the ability for HTTP headers to authenticate a user via REMOTE_USER or AUTH_USER
Describe the benefits this feature would bring to BookStack users
This would round out the authentication features of this application allowing systems that rely on central authentication to automatically login users based on the value included in the above header. A bonus would be to allow auto registration for those not in the user table similar to the other authentication plugins.
@ssddanbrown commented on GitHub (Jul 11, 2020):
Hi @tiredofit,
Thanks for the suggestion.
Could you confirm what systems or standards use these headers? I'm apprehensive to support further authentication mechanisms due to the focus they divert from enhancing the core platform.
@tiredofit commented on GitHub (Jul 12, 2020):
Hi there. REMOTE_USER or a similar variable is used in quite alot of intranet style setups and typically found as a companion to LDAP in software applications. Basically it rounds out those who are running their own authentication backend to quickly connect to 3rd party systems in an enterprise level. It's used both on Windows and Linux server environments.
I have seen other systems that are built with Laravel utilizing the ADLDAP2 module supporting it.
In short, how it works is that the web server passes the $_SERVER_REMOTE_USER variable to the PHP engine which would then circumvent the requirement for logging in. While I can certainly support the other methods that are in use (I am using SAML now)
I have an interesting use case that may make a bit more sense as to why it's requested.
Server would have 8 shelves - and one of the shelves would be publicly viewable. For those who were already logged into the central authentication system, the header would be passed and upon their visit to the site, they would see all 8 shelves. Yes, they would be able to click the login button, however it would be a source of confusion to the users to go that extra step. (Elementary school learners).
You could also pass additional variables such as
groupswhich would be similar to how you are fetching groups from LDAP and SAML to map against the Bookstack applications.I could provide access to a development authentication server, however the easiest way to emulate this would be to add a value in the nginx php configuration such as
fastcgi_param REMOTE_USER (username);@ssddanbrown commented on GitHub (Jul 12, 2020):
Thanks for explaining.
I'l therefore leave this open for a while to get an idea of need/support otherwise I may close it off after a period of time. With these kind of additions, It's effort of social/support/maintenance required, rather than the effort of initial implementation, which makes me concerned, based upon my experience from the other auth options.
@tiredofit commented on GitHub (Jul 12, 2020):
Understood. I am rather well versed in authentication so what I'll do is commit to assisting your users in this issue tracker to help them get past some of the crunchy bits about authentication. I've also made a Docker Image to support your excellent work! Thank you for at least enteraining this feature request.
@ryanc-me commented on GitHub (Aug 12, 2020):
Hey @tiredofit - I'm keen to have a look at implementing this and making a PR. Would you be up for providing some feedback?
@tiredofit commented on GitHub (Aug 12, 2020):
Hi @ryanc-me, yes absolutely. I have a development version of Bookstack and can provide input and test functionality easy enough.
I did see the referenced issue #1500 as well that you made mention to this post. What that issue was was basically asking for the same thing.
In short, I feel this would be a companion to the LDAP module (or even standard TBH) that was able to notice that a server header existed, and if it did, automatically log the person in, skipping the requirement to login. If they didn't have that header, it would work as normal/guest functionality right now.
@ryanc-me commented on GitHub (Aug 13, 2020):
@tiredofit Fantastic! I'm opening an issue to track this.
Also, I do agree. Continuing to allow LDAP sync would be great, and is something that Grafana's auth proxy supports (though only for the enterprise version - link here).
@tiredofit commented on GitHub (Aug 13, 2020):
Agreed - if we skipped the LDAP login component it would eliminate the benefits of what LDAP gives which is primarily the attributes and also more importantly the groups. I suppose we could eliminate that requirement if we added something to artisan to sync LDAP on a scheduled basis. I'm not sure how LDAP is being done in Bookstack but have been more familiar with how it is done with adLDAP2 where it polls the server and imports users on a regular basis AND authenticates to the LDAP server at the same time where as Bookstack only adds to the user table post first login. Which makes it challenging if there are "other" Bookstack Groups not passed by LDAP that need to be added to the user. I look forward to this.
@ssddanbrown commented on GitHub (Sep 29, 2021):
I'm going to close this off in favour of a theme system solution as discuseed/provided here:
https://github.com/BookStackApp/BookStack/pull/2289#issuecomment-857164663
The example on that comment should just need little tweaking to then work with the request here as far as I understand.
If it appears that I have misunderstood this then please feel free to comment at me here or open a new issue, referencing this one.