It'd be really complicated to implement.
Basically you'll have to somehow first set up a website to create credentials
then, forward those credientials to a database the server can use
use IO/file operations of .net or create your own to iterate over the list of credentials
probably separately on a different server-computer that can send RPC remotes back & forth from and to the server for really large shards
or some better means of organizing old credentials no longer used after a certain # of days to keep the folder iterations fast
if the credentials in the folder are found than that's the first step
then, some means of generating a client tag inside the client launcher that connects to the server
the server then iterates over its list of credentials and checks for this client tag
if found, then that's the second step
the server would also need to be able to keep track of a generated clientID and any other forms of identification on the server,
which would need to be proactively hashed and regenerated each login. that's the third step.
then this would enforce client verification
however the client would also need to use an implementation of an hashing algorithm imho
to pregenerate credentials the server could also validate, historically cross comparing various data points of that client on the server
it's a heck of an idea and a hell of an implementation, but would enforce client verification
one step further would be to consolidate the entire process of the website into the direct workings of the server
that would only take implementing a custom GUI interface on the ClassicUO client launcher
however at that pojnt you may as well also utilize a system of IO/file reading to determine if all of the contents of the client's files also match the server's latest copy of those files, including all artwork and everything else.
that would be slow on the server so, on a separate thread...
or the server would send a bunch of IO files similar to a cookie for the client to verify,
that introduces the concept of people bypassing to get advantages or bypassing client verification to cheat
maybe on several separated threads have those dedicated to logging players in and verifying their client files or something,
and only share any data between threads when actually finishing a validation
that would just require tweaking of thread-queue executions whenever a player attempts to login and that could lessen overhead
Sooo....
1. Client wants to login
2. First, distract target onto a blind queue.
2.1 Counter cross to left cheeky onto another thread for overhead reasons, (y) handling a queue of handshaking requests;
3. The client performs a wild haymaker of file-dumping
3.1 Each file needs to be written to IO and send over the network to the server,
perform elbow block and body shot every file's content against an existing clone.
3.2 Than blocking furrow left, send requests to the client to simultaneously begin a new thread
and check the client's ClassicUO version or other custom files exist in a custom client also.
3.3 If the client cannot verify that, than weaken right jaw and send a request to check for the client's tag or something
4. Once verified, break cracked ribs and traumatize their solar plexus anyhow,
and get them to verify a set of credentials created within the client interface.
4.1 Dislocate jaw entirely, and on the server backcheck whether these credentials pre-exist
by iterating over a folder's contents for the particular custom IO operation file's contents... pre-existing credentials excuse me.
4.2 End with a huge kick to diaphragm, verifying the client or IP banning.
2. Perform uppercut onto a queue to a separate thread handling handshaking; process
3. The client dumps their client files into an IO file and sends that across the network,
each file's contents would need to be decrypted and sent to the server to validate an existing clone.
4. The server completes validation, and finishes that particular client's verification,
sending their next process to client logging in.
I think its all doable on the server actually without much implementation,
but you need to be willing to mess around with the client and figure out through visual studio's referencing what's doing what
