Multi-User Support

[Kovah]

LinkAce should support multiple user accounts which then can independently manage their links.

Current challenges:

• There must be at least two roles: admin and regular user. Admins should be able to change system settings and manage other users.
• How much access should the admin have to regular users' content?
• How much access should regular users have to access other users' content?
• How is the guest access organized? Which users' content is displayed and how?

Definition of Features

Roles and User Management

• Two roles will exist: Admin and User. Admins can change system settings and manage users.
• Users can be invited by the admin via email.
• User Management: users can be edited, deactivated (login no longer possible but the user profile remains active) and soft deleted.
• Soft deleted users no longer have profiles, links will only display the original user name but no links to a profile. Deleted users can be restored by admins.
• Admins are not supposed to "be god", i.e. view and edit all links no matter if they are private or not. Admins should only have access to advanced configuration and user management.
• TBD: Admins are able to configure a SSO or LDAP provider, see Support for SSO / LDAP #174. (How will user permissions be handled then?)

Permissions

• Guests (if Guest mode is enabled)
  • View link overview, link details
  • View list overview, list details with links
  • View tag overview, tag details with links
• Users
  • Links
    • Create links
    • View links they own and links of other users if they are internal (see below)
    • Edit their own links
  • Lists
    • Same as links
  • Tags
    • Same as links
  • Notes
    • View notes of all links they can view
    • Create notes on all links they can view
  • View user profiles
• Admins
  • Same as regular users
  • Access user management
  • Access system settings
  • Access the API token management

Links, Lists and Tags

• Links, Lists and Tags will be attached to the user who created the content.
• Privacy: Users are able to choose if a link, list or tag should be public or internal or private:
  • private links/lists/tags are only visible to the user itself and no one else.
  • internal links/lists/tags are visible to all logged in users
  • otherwise the link/list/tag is public and will be displayed to guests, if guest mode is enabled.
• Collaboration:
  • Users may attach tags to links and add links to lists as long as the tags and lists are either public or internal.
  • Users can lock public or internal lists. In that case only the owner can add new links to it.
  • Tags and lists will always remain open to add, adding them to links cannot be restricted yet.

User Profiles

• Users have a profile that is always visible to logged in users. Profiles show basic details about the user and their content: links, latest tags and latests lists.

User Settings

• Users can set their profile public, which means it is also visible to guests.
• Users can choose if links/lists/tags/notes are public or internal or private by default.

API Access

• Admins will be able to generate global API tokens. There will be two versions: (See Please vote: API changes in LinkAce 2 #556)
  • Read-only tokens which allow to read but not change all content that is also visible to logged-in users.
  • Read-and-Write tokens which have full access to all content including making changes.
• User API tokens will only be able to view and edit content the user has access to.

Migration

• All content currently stored in LinkAce is already linked to the primary users. This user will become an admin.
• Links currently marked as private will become private links of that user.
• If guest mode is disabled, all regular links will become internal links. Otherwise, they will remain public.

Final Tasks

• Testing multi user support properly.

[jmtrivial]

Other bookmark tools are providing a first page with all public content, then subpages for public content for each user:
https://github.com/sebcode/b
It could be a nice feature.

[anjunatl]

Local user & role management

If you're open to integrating with MIT-licensed 3rd party projects, I've had a good experience with these libraries for implementing user/role management features. It's pretty .env configurable & the blade views for user & role CRUD ops are deployed from templates and can be modified to fit the project 😄

• https://github.com/jeremykenedy/laravel-users
• https://github.com/jeremykenedy/laravel-roles

LDAP vs Local user & role management

If an ldap/local toggle is added to .env, the user provider config could probably be changed out between local & ldap user classes

• https://stackoverflow.com/a/56791055 - came up when searching "laravel dynamic user provider"
• https://www.csrhymes.com/2020/10/12/use-ldap-record-with-laravel-fortify.html references https://github.com/DirectoryTree/LdapRecord-Laravel, several random libraries came up when I searched "laravel ldap", I haven't researched healthy repos or used any of these myself yet

API Tokens

I'm pretty sure integrating this Laravel package will accomplish this goal - https://laravel.com/docs/8.x/sanctum

[djthread]

So excited for this. LinkAce seems like a great tool and with multi-user support, I'm going to propose my team uses it for link sharing. Thank you, Kovah & contributors! 🎊

[Metal-Frog]

+1
LinkAce is really great - but I multi user support is mandatory for me.

[Kovah]

Well, there is a big problem now. Tags, lists and links should be shared between users, but can also be private for a single user.
What about the following scenario:

• User Alice create a new List "Awesome Tools", makes it private and adds some links to it.
• User Bob adds some new links and creates a List "Awesome Tools" on the fly, which is public by default.
• There are two lists with the same name "Awesome Tools", but one is only visible by Alice.
• Alice creates new links and wants to add them to her list: theoretically, both Lists must be shown because Alice can access both. Is it preferable to always add the links to her own list?
• What happens when Alice decides to make her List public? There are two Lists now with the same name, but different content, depending on the user who used the List.
• It would be bad if users could not add new tags, lists or links because "they already exist", especially if they can't access them at all.

Similar issues arise when two users add the same Link. The same link can be added by multiple users. Should this even be possible? What if a user wants to add a private link that another user already privately saved? What happens when both users decide to make their links with the same URL public later on? 😕

@jmtrivial @anjunatl @djthread @Metal-Frog @ffraenz Do you have any thoughts on this? I'm kinda lost.

[ffraenz]

I'd display the creator/owner of a list next to it (e.g. in a badge or pill behind it or as a prefix "ffraenz/awesome-list". If you feel that would clutter the UI you could only show the owner when there's a conflict. Visually adding an owner badge to lists may also have a motivational effect on the "collectors".

About the links, yeah, they may be added multiple times without users knowing. You may reuse meta data already fetched but the user should not be able to find out wether a link was already added or by whom it might have been added (I'm randomly thinking about adding a sleep to trackle timing attacks 🙈).

[djthread]

Thank you for looking closer at this, Kevin! I'd be happy to help try and brainstorm on this stuff. My thoughts are a bit disorganized here, but maybe there are some ideas you like.

Is it possible you could just allow the duplicates until it's not allowed? For instance, maybe when a user sets a list to be public, it would be denied until they change the title (or slug) to be unique? The way I've seen blogs do it, the titles could be the same -- only the slug which is used in the URL must be unique. Or maybe the system could add a "-2" etc to the end automatically so making a list public would be allowed without intervention.

I've also done it and seen it done where the slug part of the url actually includes a primary key in it like "mywebsite.com/10-reasons-why-linkace-rocks-2836492". This may also help the issues you're describing.

Another idea could be to put the owner's username in the url to namespace them. This would also mean there would be no duplicates, right? Also, Alice would be able to see both lists in your example, no problem.

Why can't two LinkAce link records share the same URL? I mean two different URLs often lead to the same place or one redirects to the other, so it's hardly a perfect science here. If necessary, a tool to find dupes might be useful for someone. But maybe there is something in the LinkAce design here I'd want to understand.

As for tags, what if, by making a link public, an extra routine around its tags would happen. All tags also need to be public, so any tags which are private would be either dropped and replaced with a public one with the same name if it exists OR the existing private tag would be made public.

Anyway, just some naive thoughts.

[Drallas]

Why not keeping the users completely separate from each other?

www.linkaceurl.org : admin
www.linkaceurl.org/user1 : user1
www.linkaceurl.org/user2 : user2

If a user wants to make something public, they can expose them via their own url.

www.linkaceurl.org/user2/links/linkname
www.linkaceurl.org/user2/tags/tagname
www.linkaceurl.org/user2/lists/listname

If sharing is required, let say user1 to user2: www.linkaceurl.org/user1/links/linkname is flagged as accessible by user2/3/4 etc...

[Kovah]

To be clear, this is not an issue with the URLs of LinkAce or from the technical side. It is possible to have two links with the same url that the user wants to save. Sorry for not making this clear enough.
The issue I outlined is about the user experience and how users perceive seemingly duplicate lists and tags while they browse or edit stuff. I think the things @ffraenz mentioned seem to be a good idea: clearly separating seemingly duplicate links by appending the creator, or something similar. Additionally, the idea by @djthread about a routine or migration when a tag or list is made public when there is an existing tag with the same name.

[Kovah]

To cite myself:

I now remember why LinkAce had no multi-user support in the first place: the implementation is absolutely frustrating. I am really done for now...

😐

Edit: that was one of these moments in programming where nothing seems to work. I noticed that whatever I tried seemed to make things only more complicated. I gonna think through the matter before starting to work on it again. It will be a more simple solution.

[Kovah]

Here are some screenshots of what tags and lists look like. As explained earlier, creating a visual difference between tags or lists with the same name, I decided to "scope" them with the help of the username, which is now placed before the tag.

Links will be another topic. I planned to start from scratch for lists of links. There will be a table view and some type of cards. The author will likely be shown, or maybe put in front of the title or something like that.

[MrHappy]

You might use a displayname (combination of user+list?) and an id internally.
The displayname would become something like 'kovah/TODO Marketing' and the id 1001.
The url could be something like 'http://linkace.local/1001´. It does create extra handling for authorizations etc, but also makes it possible to change the name without ruining links....

[tjharman]

Is this implemented? I see the latest version allows you to list users.
I'm just not sure if this is in prep, or because this feature exists?

[Kovah]

This is not ready yet, the last update was kind of a preparation.

[tjharman]

I thought that might be the case. Thank you very much, I really appreciate LinkAce and the careful thought you put into it.

[Kovah]

Update on the API tokens stuff:
This is a ton of work. A new system user is generated while running the migrations. System tokes are bound to that user and have dedicated abilities. Api calls need to be properly authorized, which feels really hacky at the moment. I only implemented the checks for listing all links at the moment, all other stuff is completely missing. Guess this will take a lot of time to be completed...

[Kovah]

Is there anyone with some experience in Laravel willing to listen to me for a couple of minutes? I feel like I'm heading into a wrong direction with the API stuff. 🙁

[Kovah]

⚠️ Important!
Please vote on this poll if you are using, or will use, the API:

• Please vote: API changes in LinkAce 2 #556

[amadeusp]

For me it would not be important to be able to share anything between the various users. I would be fine if they'd be completely isolated from each other. Also not an important feature for me personally as I am currently using LinkedAce just for myself. But as a general capability I think it could make the app a lot more attractive if it'd offer multi user support.

[Kovah]

As per the latest poll on this topic (#556), LinkAce v2 will not ship with support for global/system-wide API tokens. I will move the code written until now to a separate branch and go on with other topics.

[chrissawyerfan4]

One thing that very much surprised me to see is that authenticated users can use the server as a proxy for requests. Thankfully things like the file:// protocol are rejected, but it would still get behind any firewalling that the system has on the outside. Told myself not to worry because, as it currently lacks multi-user support, I should (barring vulnerabilities) be the only one able to make use of this proxy.

Multi-user support is an awesome feature and I think it's a great enhancement to LinkAce, but at the same time, I would want to be aware of this being a thing before installation if other users might be able to make use of this.

Just something to keep in mind while working on multi-user support. Perhaps arbitrary request proxying should be an opt-in/enableable setting per user (group).

[Kovah]

That's indeed an interesting point. Never thought about that. Of course, the new multi-user system is not meant to be like a social network or something where everyone can register. Admins must invite each user, so there's control over who can use your LinkAce.