-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future feature: User management. Ideas, wishes, roadmap #1255
Comments
When user management will be implimented? |
In the future, no ETA, probably lowish priority anyway to be honest |
I just want to add here that I think the currently existing multi-user plugin would be good to use as a reference for what user management could look like if implemented directly in YOURLS: http://www.matbra.com/en/code/multi-user-yourls-plugin/ I've quite heavily modified my version of the above plugin. It supports LDAP login and also our company's WebSSO login. When a user logs in for the first time, their account will automatically be created. Each user has their own admin page where they can see and manage their own short links. They can also view (and search) all short links in the system. |
Very interesting, thanks for the link @adigitalife! |
Some thoughts on users… The current system scales really badly because in several places it relies on cycling through the list of users. This is OK if you have half a dozen users, but isn't going to work well on a large installation. In looking at user management this needs to be eliminated. The way cookies are generated is one place. This is fairly simple to change. Using PHP's internal session management is the obvious way. The API is another place. For the basic signature style API a change here would require that a user's API key be stored in the database. It wouldn't need to be based on hashing the username, although it could be initially to ease migration. Verifying the API key is then simply a question of looking it up in the DB. Storing an API key in the DB, the form of which is independent of the username, also has the advantage that a compromised API key could be reset on a per user basis. Currently the only way to reset an API key is to change YOURLS_COOKIEKEY, which resets everyone's API key The big problem is the time limited signature token API method. There is no way of verifying the call without cycling through all users and testing the received signature against each in turn. This is completely unscalable. I therefore think this API call in it current form should be deprecated and replaced. This should happen as soon as possible to allow authors of systems relying on this method time to change their code. A replacement would need to include the username in the request. Clearly the simple way to do this is just to add a 'user' parameter to the request. Alternatively, a single paramater 'key' could be used that consists of a base64 encoded concatenation of username, timestamp and signature, separated by a suitable character, perhaps null (\0). Internally then base64 decode and split on the separator. |
I like the concept of the multi-user plugin as it stands except that it doesn't seem to support the concept of roles, which is just as important when it comes to supporting multiple users. The roles as proposed above are a good set. I might suggest one extra layer of "editor", which would be like user but with the ability to see all shortened links, not just their own. At the moment, I'm inclined to stick with https://github.com/nicwaller/yourls-authmgr-plugin because, for me, the role separation is more important than controlling who can see which links, but I really would like to see YOURLS improved to support both at the same time rather than having to choose between them. |
@pcolmer how about Auth Manager Plus, I think it does everything you are mentioning here. I have yet to add admin interface and other features, but under the hood it seems to run pretty good. |
Thanks, @joshp23. I've upgraded our installation to use it. |
This is a COPY of Issue 1255: Future feature: User management. Ideas, wishes, roadmap, filed on Google Code before the project was moved on Github.
Please review the original issue and especially its comments. Comments here on closed issues will be ignored. Thanks.
Original description
The text was updated successfully, but these errors were encountered: