Feature request User based on a rest API

[fstn]

Subject of the issue

My users are stored in my remote application, I can't access and query the database. The only way that I have to authenticate a user is to call a rest API. Is it a way to Tinode to work with an empty user table and use a rest API for users?

Is this a bug report of a feature request?

• Bug report
• Feature request

[or-else]

If the question is about authentication only then yes, it's straightforward. All you need to do is implement this interface: https://github.com/tinode/chat/blob/master/server/auth/auth.go

Take a look at some authenticators here: https://github.com/tinode/chat/tree/master/server/auth
For instance, token authenticator does not use a database at all
https://github.com/tinode/chat/blob/master/server/auth/token/auth_token.go

If you want to keep data in two databases, users in one and everything else in another, that's also possible but tricky.

If you need help or have questions, please let me know.

[fstn]

Thank you ;)

If I understand I can use my LoginProvier to generate a token like this:
[8:UID][4:expires][2:authLevel][2:serial-number][4:feature-bits][32:signature]

The login will look like this:

How can I add user permissions inside the token?

The goal is to link automatically users to the other users that work inside the same group:

Users have one or many groups, each group has channels, when a user connect, he can list all users and channels that are inside the same groups.
There is super user that can list everything inside a super group.

A slack comparaison would be:

How can I limit user visibility to do that? tags? if it's the case can I put tags inside the token?

Or I might be do something like that:

Thank you

[or-else]

Here is how the current authentication scheme is supposed to work:

The User -> Tinode authentication request does not need to be a simple login/password. It can be your token which may contain whatever info you want. You need to write your own authentication adapter, which is quite simple, give it a name, say "fstn" then login like {login id="123" scheme="fstn" secret="whatever-you-want-base64-encoded"}. Tinode will pass this secret to your adapter which may use it to call your LoginProvider. If adapter.Authenticate() does not return an error, Tinode generates the token ([8:UID][4:expires][2:authLevel][2:serial-number][4:feature-bits][32:signature]) and returns it to user. User will subsequently use the token to authenticate with Tinode directly without calling your adapter.

Let me know what's missing in this scheme.

Regarding user groups. Yes, the groups should be built on tags. I think the most logical place for issuing tags is the authentication adapter.
It's possible to organise tags so users can find each other only if they belong to the same group. But it's not strictly enforced. Users may still find each other by other means and communicate even if they don't belong to the same group. Is it a problem for your use case?
There is also a question of policy how tags/groups are managed, i.e. inviting/removing/banning/creating new. where do you see this happening?

[fstn]

Thank you ;)

Ok for the adapter, I will try ;)

Regarding the tag option, I have some security issue. I need to limit the found people with the group. Users from different groups must not see each other.
I can't just filter it on the client side, do I have a way to code a middleware on the server side that filter Fnd query for topics and user ?

Concerning the tags, this is what I imagined:

So there is no need of inviting, tags are given by the LoginAndTagsProvider during the login. So it will update (create,remove) tags at every user login... does it make sense?

[or-else]

I need to limit the found people with the group. Users from different groups must not see each other.

It's easy to make sure they cannot find each other using fnd. But, say, if you and I meet by the water-cooler and exchange IDs, I will be able to open a p2p chat with you regardless of group membership. Blocking such contacts would be hard.

LoginAndTagsProvider

Yes, it makes sense and it seems to be the most straightforward solution. If something is currently missing, I can add it. The side effect of this scheme will be that tag changes (group membership changes) will require a re-login.

[fstn]

It's easy to make sure they cannot find each other using fnd. But, say, if you and I meet by the water-cooler and exchange IDs, I will be able to open a p2p chat with you regardless of group membership. Blocking such contacts would be hard.

Ok this seems to be ok ;) Where can I add the middleware to filter this? I saw something call plgTopicFnd can I add a plugin to do that?

Yes, it makes sense and it seems to be the most straightforward solution. If something is currently missing, I can add it. The side effect of this scheme will be that tag changes (group membership changes) will require a re-login.

Thank you

[or-else]

You certainly can do it with a plugin but maybe you don't need it. Groups seem to be a reasonably common use case so I don't mind supporting it directly.

The steps would look like this:

• allocate a tag name space, like group: (group:general, group:random, group:help, etc)
• assign tags to users according to group membership.
• have the client construct the fnd query based on user's tags.
  Technically users may still craft a fnd query by hand, so I need to ensure on the server side that the query contains permitted terms only.

[fstn]

It would be awesome 😎

Do you know approximately when you can supporting it?

Thank you, it’s really a pleasure to talk with you.

[or-else]

That depends on how fast you are willing to move. I need to finish the #hash navigation in the client then I can take the next feature. You are going to need to write an adapter. It will take you a couple of days at least.

[fstn]

Great ;)