Multi-user capable and integrated branding options.

[agent4701]

This PR adds multi-user capability and integrated branding options.

• Enables multiple users to use the same Scriberr instance
• Adds basic branding/customization options for deployments
• Updates UI and server so the new options are applied consistently

Tested locally in my own setup.

If you now build the application using docker-compose.build.yml and then start it, you can create an admin account
for the first time and log in directly. Afterwards, you can click on Settings via the three dots and create new users and
change the logo as desired.

I hope I did everything correctly; I'm still a beginner in the GitHub environment.

[mo-st]

I have tried to get a preliminary overview today and realized I will probably need a lot more time than anticipated to review this thoroughly, as it is quite a broad change. I'll continue updating on my thoughts and findings here as I go. I hope this is okay.

General Plan

1. Review changes (Progress: 10/43 files)
2. Test implementation with Docker container

Findings so far

As without me finishing the review you cannot see the comments I made, here a preliminary summary

• added gorm.io/driver/postgres v1.5.7 which is a few versions behind latest, potentially contains CVE crypto libs -> maybe update?
  • This driver may have a couple of CVE's: gorm.io/driver/postgres-v1.5.7: 5 vulnerabilities (highest severity is: 7.5) kube-tarian/kad#518
    The issue seems to be an older crypto module. Is it possible to use a more up-to-date one? Or did you encounter breaking changes akin to Gorm 1.6.0 breaking change for where conditions with joins go-gorm/gorm#7489 as well?
    I didn't look into whether these may affect overall code security too deeply but in case this needs to be kept, I would like to do that first
• potential fail-open vulnerabilities in
  • internal/api/chat_handlers.go Line 358ff:
    In my understanding, by including this else if you still allow getting sessions that are not associated with a uid, is that correct? So if the getContextUserID were to fail for some reason, you would default to letting any user access the chat session using just the sessionID, given the db query with it succeeds without error. If this understanding is correct, I would not consider this secure. Failure leading to access wouldn't be a good default. Fail-secure is the principle to go by. For example, using an early return in case uid isn't ok would be better:

    uid, ok := getContextUserID(c)
    if !ok {
        c.JSON(http.StatusUnauthorized, gin.H{"error": "Authentication required"})
        return
    }

    In case I misunderstood, please disregard.

[EdrisT]

I tried running agent4701s version and it had (for me) some problems.

The multi user (and custom branding) worked as expected. (I did not test backwards compability of the db)

But it seems there are also other changes, for example in how the python environments are handled, that at least for me broke the diarization part of the transcription.

[rishikanthc]

I still haven't reviewed the PR yet. I believe @mo-st is still reviewing the PR.

There are some concerns that need to be addressed. The major one is the PR is built on old code which will be a problem. Also I'm not a fan that such a major change has been submitted as a single commit. The PR touches something like 40+ files. Adding all changes as a single commit for such a major change is not good practice. This also makes review really hard and one of the reasons why I have been pushing taking a look at it.

I'll get to it sometime next week. I don't want to add this to 1.2.0 as it's auth related and a big feature. I will need to audit to make sure everything is secure and there's no leakage of data across users. I also need to check how the job queue is handled when multiple users submit jobs.

[rishikanthc]

One thing I wanted some input on and is a good discussion to have is whether to add support for OIDC auth. This would be a good feature to have imo.

Let me know your thoughts

[mo-st]

Yes, I'm still on it, slowly but surely for the reasons you mentioned. I'm trying to be quite thorough. I'm updating my first comment with findings I thought worth mentioning ahead of finishing the review.

I suspect about 30 files will actually change once the artifacts from being based on old code are cleaned up. Still quite substantial and I'm not sure whether it's possible to touch any less, as so many functions need to be updated to check for uid clearance. I agree with your sentiment to check everything carefully, especially considering the size and monolith commit nature.

OIDC would be a great feature to have, I agree.

[rishikanthc]

@mo-st no worries.. Please take your time. I want to get more eyes on this and I would rather take the time to make sure everything is good than rushing into it.

Also, if possible, please also verify if the changes are backward compatible. Especially the database part needs to be check to ensure that existing users can seamlessly migrate to the new multi-user setup without breaking anything..

[stony007de]

Is there a way to support you to bring up that request?

[rishikanthc]

Is there a way to support you to bring up that request?

Right now I need more hands on deck xD I'm not an expert when it comes to auth.. So I need to understand how auth works properly before I can do this as I don't want to introduce any security vulnerabilities.. I am also thinking if I should go the OIDC route.. but not sure.. I'm still mulling over this..
So could really use some help with building this.. Or if someone could point me to some good resources that would also be of great help..

[daemolition]

For plain multiuser without OIDC or LDAP you just need to have a signup route (for new users), saving hashed or encrypted passwords into a small userdatabase and a small rolesystem ('admin','user'). With this you also need to map the user_id to the transcriptions and the adminmenu should be hidden and inaccessable if the user doesn't have the role admin. Nothing more is needed.

https://blog.devgenius.io/build-a-super-simple-but-scalable-user-login-system-in-go-cassandra-docker-307769b6f135

For oidc or ldap you need to know about encryption, sessions, cookies, certificates etc. In addition you need to setup your own active directory / keycloak in a lab environment to make your code work. If you are interested just get in touch with me and i'll show you what's needed to setup a local environment for ldap.