Skip to content
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

Open
ozh opened this issue Apr 6, 2013 · 8 comments
Open

Future feature: User management. Ideas, wishes, roadmap #1255

ozh opened this issue Apr 6, 2013 · 8 comments
Labels
Milestone

Comments

@ozh
Copy link
Member

ozh commented Apr 6, 2013

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

A few notes on how I see the future User Management feature

# Goals:
- storing login/pwd in the DB instead of config.php
- segregating short URL per user

# Needs:
- an UI to add/edit/delete users
- a full fledged installer that will prompt user for an admin login & password and store that in DB, instead of having users write that down in a config file, see issue 1254

# Features:
I want that feature to work like the user management in WP, that is
- roles (ie 'admin', 'user', 'statviewer', etc)
- capabilities (ie yourls_current_user_can('manage_plugins'), 'view-stats', 'use-api', etc...)
- everything filterable to create as many roles and capabilities as needed

Default roles should probably be:
stats: view stat pages only
api: use API actions only
user: capabilities = 'stats' + 'api' + shorten URL, edit/delete short URL
admin: capabilities = 'user' + manage plugins + manage users + manage options if any


# DB

To be pondered and decided. A 'user' table and a 'user_meta' table.


# Misc

During the process, attention should be paid to other areas that should benefit from these feature, such as Issue 1239 (multiple secret signatures per user)
@vishals321
Copy link

When user management will be implimented?

@ozh
Copy link
Member Author

ozh commented Aug 7, 2015

In the future, no ETA, probably lowish priority anyway to be honest

@adigitalife
Copy link
Contributor

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.

@LeoColomb
Copy link
Member

Very interesting, thanks for the link @adigitalife!

@tipichris
Copy link

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.

@pcolmer
Copy link
Contributor

pcolmer commented Aug 10, 2016

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.

@joshp23
Copy link
Contributor

joshp23 commented Sep 8, 2018

@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.

@pcolmer
Copy link
Contributor

pcolmer commented Sep 10, 2018

Thanks, @joshp23. I've upgraded our installation to use it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants