Greetings,
Apologies if this has been discussed before, a search didn't turn up anything.
We've got an application that's using remoting, the databases for different client installs live on one of our servers. Wondering if it's possible to have just one remoting host that would be able to to access a particular database, based on a .config setting.
Or is it required that we need one remoting host for each client install? The only difference is that different clients use their own databse.
Thanks,
Mike
I think I follow the question, so here it goes….
You can have one client remoting server connecting to multiple
databases. You just have to define all connection strings in
configuration file and you have to figure out what client is connecting based
on request information. In other words, unique client ID is passed as
part of each request/criteria object. I think you will be looking at a
lot of code refactoring if you are going to go with single service for all
clients/databases.
Sergey Barskiy
Senior Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Magenic ®
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: Michael Hildner
[mailto:cslanet@lhotka.net]
Sent: Wednesday, July 16, 2008 11:48 AM
To: Sergey Barskiy
Subject: [CSLA .NET] Remoting with many databases
Greetings,
Apologies if this has been discussed before, a search didn't turn up
anything.
We've got an application that's using remoting, the databases for different
client installs live on one of our servers. Wondering if it's possible to have
just one remoting host that would be able to to access a particular database,
based on a .config setting.
Or is it required that we need one remoting host for each client install?
The only difference is that different clients use their own databse.
Thanks,
Mike
Thanks Sergey, that makes sense. I appreciate the information.
Mike
One relatively common solution to this is to use ClientContext to store (and thus pass to the server on every request) a "database id" or "client id" value. That value can then be used in your DAL code to find the right database connection string for that particular id.
Another solution is to put the id token in your custom Identity object, because that also flows from client to server on every request.
The thing to consider in both cases is that a malicious hacker could potentially alter this id value in memory on the client, thus spoofing some other id. If this is a concern, then the same techniques will work, but you'll need to use encryption somewhat like ASP.NET does with their authentication cookie.
The encryption key is symmetric and is only known to the app server. When the user is authenticated, this id token is created and encrypted on the server. The encrypted value is given to the client, so the client can put it in either the Identity object or ClientContext. Either way, each server request gets the encrypted token, can decrypt it and use the value to find the right database connection string for that particular id.
You should make sure to time-bomb the encrypted token to prevent long-term replay attacks.
Security is so much fun...
Copyright (c) Marimer LLC