mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 00:29:48 +03:00
Local Linux account support #1160
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 @CorruptComputer on GitHub (Apr 27, 2019).
Describe the feature you'd like
I would like to be able to login as local users from the box that BookStack is running on. Disabling email service all together, and just using local usernames and passwords would be ideal for me. Another web application I use quite a bit is called Cockpit and it supports this out of the box.
Describe the benefits this feature would bring to BookStack users
Quick and easy setup for environments where SMTP is unavailable or where you would want to control access through Linux account groups.
Additional context
n/a
@ssddanbrown commented on GitHub (Apr 28, 2019):
Thanks for the suggestion @CorruptComputer.
Generally this is probably not something I'd be looking to add. I'd rather not add, support & maintain an additional authentication method, especially one that would be OS-specific and likely infrequently used.
Linux account authentication makes a lot of sense in a project like cockpit, where system users and app users will likely align due to the fundamental goal/features of cockpit, whereas in BookStack there is very little crossover between the roles of a user within BookStack and the role of a linux account.
Will leave this open to discussion though.
@CorruptComputer commented on GitHub (May 4, 2019):
@ssddanbrown As far as I have been able to tell BookStack only supports Linux to begin with, as the Installation documentation only shows support for Linux. So I don't think "OS-specific" code would hinder anything if this is only really supported on one OS to begin with.
This would also allow greater flexibility in not requiring email addresses and instead just allowing usernames to logon, which is something my organization would very much like.
@ssddanbrown commented on GitHub (May 4, 2019):
BookStack can run on pretty much any OS that'll run PHP7, It's just that we only have official install scripts for Ubuntu LTS releases since that'll be the most popular production target and I'm fairly confident with scripting Ubuntu.
I can see the use-case in this, Just don't think it'll be worth the effort in supporting it, as per my comment above.
@timoschwarzer commented on GitHub (May 6, 2019):
If you run BookStack inside a container environment like Docker, system user authentication makes no sense, too. Like @ssddanbrown said, Cockpit is focused on managing the system it runs on, therefore it makes sense to authenticate against the system user database. BookStack however is a web service and does not target a specific OS.
@CorruptComputer commented on GitHub (May 16, 2019):
I understand that it makes no sense for Docker. However when running it on a local server for documentation there is no SMTP available for email, nor is there LDAP available for user authentication. So this was just the easiest way I thought to implement this. Unless it was possible to just sign up users with usernames rather than email addresses.
@timoschwarzer commented on GitHub (May 16, 2019):
LDAP makes more sense to me.
https://github.com/Adldap2/Adldap2-Laravel
@ciphermenial commented on GitHub (Jun 12, 2019):
@CorruptComputer What is the value of adding this functionality? Is it even adding functionality or duplicating it? How many people will use it?
You can enter any email address for the username e.g. test@test.local and they can sign in with that. You don't need SMTP configured.
@CorruptComputer commented on GitHub (Jun 12, 2019):
I entirely understand how this isn't useful to many situations. But as I said in an environment with no SMTP or LDAP access it doesn't make sense to use email addresses for logon. I think usernames would be more appropriate, and with using usernames it would be nice to be able to use the accounts already provided by the system.
@CorruptComputer commented on GitHub (Jun 12, 2019):
This is not user friendly, nor is it intuitive to use.
A specific example as to why I think this is a good feature to have:
My company has a server setup, lets call it
dev-server. We have our development processes, software, and documentation all saved on that sever. Only people with access to logon to that server should be able to access the documentation stored there. Now if we want to make the process simpler and run a BookStack instance on that server for documentation rather than having text files everywhere, it makes sense to tie it to the accounts which have access to that server.@ssddanbrown commented on GitHub (Dec 10, 2020):
Since this feature request has had little further demand, and since it applies to auth which is an area that already consumes a lot of time, I'm going to close this off.
The efforts/discussion in #2223 might be of interest, since there's some discussion of auth based off of HTTP headers. Feel like there could possible be a simpler way to join local accounts with that, but I've not really explored that realm.