[feature request] auth interface

[xurwxj]

Can u abstract the method in /internal/auth/auth.go as an interface, so is it convenient for users to use this library to verify logic with their own auth sys? For example, access to the existing user system or redis's session.

[FZambia]

@xurwxj hello! Great to see your interest to this project.

That auth logic is for Centrifugo server only (this library supposed to be a core for Centrifugo v2). Centrifugo must integrate with backend in any programming language. So in that case the only generic way to authenticate user is passing it's credentials from client with HMAC sign to verify on Centrifugo side.

But if you are talking about using this library from Go language code then it's already possible to authenticate user in any way you want using convenient middleware approach - as shown in example. You have request and context - so can implement any logic and pass whatever you want to context and set correct user ID to client credentials.

That example is for Websocket and SockJS as HTTP server middleware is used. For GRPC it will be possible in GRPC-specific way - using interceptor. Though we have no clients for GRPC endpoint yet, only proof of concept client

Does it make sense?

Also I must note that this library is not a complete work at moment, API will break - but I suppose you saw this warning in repo description.

[xurwxj]

@FZambia thanks for your great job. This library is very meaningful to me.
I want to use it to try some of the following functions:

1. private chat, support offline messages, until they are subscribed.
2. groups of chat, support offline messages, until they are subscribed.
3. message subscriptions, including at most one delivery and at least one subscription for different scene.
4. save all message in db for history pull or offline message redelivery
   so any advise base on this library?

[FZambia]

This library must anyway be used together with robust persistent storage for messages - i.e. main application database if you want reliable delivery and history, library provides a best effort to recover some missed messages (in configured time interval and limited by configured size) but the only source of truth is your main database. You better consider Centrifuge lib only as persistent connection hub and transport for real-time messages. It has at most once delivery – so when you need at least once for example then you had to implement sth on top of this library in your code - message acks maybe.

It's hard for me to give a concrete advices at moment - as I had no real experience building sth complicated on top of this lib. I am interested in any feedback from you whatever you end up with - any downside can theoretically be fixed at this stage I hope.

[xurwxj]

@FZambia thanks a lot. I need to think about it, maybe I will build a new library based on your library. I will feed back when I have a progress.