distributed ServerUser/ServerUserCollection using redis

0 votes
asked Sep 26, 2018 by GrahameHorner (170 points)

I'm looking for away to replace the ServerUserCollection with a repository pattern using redis cache so user data is not held in memory and a large number of users can be supported across a cluster of servers/applications; how can this be achieved?

1 Answer

0 votes
answered Sep 27, 2018 by Lukas Pokorny (123,810 points)

You can easily implement a custom authentication provider using FileServer object's Authentication event - please see the Custom Authentication page for more information and sample code.

commented Sep 27, 2018 by GrahameHorner (170 points)
Yes, but why do I still need to add the user the server.users collection ? given this is a cluster the user is not always going the re-connect to the same instance as the backend, and therefor we'd like to avoid adding a user into the in-memory user collection on instance and replace this with a redis cache or similar
commented Sep 27, 2018 by Lukas Pokorny (123,810 points)
No, you don't have to. You can actually ignore the Users collection altogether when using a custom authentication provider. You only have to return a newly-created instance of new FileServerUser that represents the authenticated user. Sorry for the confusion.
commented Sep 27, 2018 by GrahameHorner (170 points)
Q: what is the purpose of the returning the FileServerUser, is this held in memory or referenced in any process, for anything other then establishing the a user token has been provided? as the this looks to have an encrypted password, and password method checking.  the authentication user/system we would like to implement is a passwordless TOTP system?
commented Sep 29, 2018 by Lukas Pokorny (123,810 points)
The instance of FileServerUser object is associated with the SSH session and is passed to various custom events where it can be used for whatever purpose you wish (such as storing additional per-user data). You can even implement a custom class that inherits from FileServerUser and use that instead. The password functionality is only used with the build-in FileServer.Users collection and can (or actually should) simply be ignored when using a custom authentication provider.