I have been wondering this for a few days and even after scouring the internet, I haven’t found an answer. Can you explain the reason for the architecture behind the UserAuth / UserAuthDetails objects? I look at every other thing that you have done with the framework and love it. Since I plan on using ServiceStack for the foreseeable future on all projects, I want to understand every function, eventually, as if I wrote it myself (don’t laugh, I know that’s a huge undertaking).
I am really curious of the following points:
Why are there so many properties in each
Why are there duplicate properties
This is in no way questioning what you did, I would just like to know why so I have a better understanding. I would have thought that you would have included the minimum number of properties required (i.e: Id, UserName, Email) and let the application developer extend from there.
The top-level UserAuth holds the primary User Authentication info, which can be sourced from multiple UserAuthDetails sources which contains the user info from a particular OAuth source, e.g Facebook, Twitter, GitHub, etc. This is how a single User Account can login from multiple OAuth sources. After each OAuth login the primary UserAuth info gets updated.
Most of the properties are from standard properties defined in the OAuth spec. There are a lot of properties as the same UserAuth model needs to be supported in all different UserAuth Repositories including RDBMS’s fixed schema where adding a property in a later release would break existing solutions. So it’s important to have most of the properties typically associated with a user upfront to minimize the chances for requiring extending the built-in UserAuth so the out-of-the-box solution supports many use-cases without additional effort. The only time UserAuth/UserAuthDetails are accessed is at Authentication which is used to populate the AuthUserInfo session stored in the registered Caching provider for subsequent fast access to Users Info.