I am a developer that owns a small E-Commerce site. I am considering selling the business. I have a prospective buyer, but he is not very technical and I am insisting that he get his own hosting provider instead of calling me every time the site goes down (which sort of defeats the purpose of selling the site in the first place).
Since hosting the site offsite also means hosting the database offsite, there are some challenges with converting all of the applications for use with a shared hosting provider. Ideally, this could be done without changing too much of the architecture.
The business runs on 4 custom applications and some 3rd party software. The site itself and one of the custom applications were built as 2-tier applications. Upon analysis, the site will require no changes. The other 2-tier Windows service can easily be converted by writing an XML Web Service wrapper around the data access layer, which fortunately is in a class of its own.
Then there is an administration application (a Windows client) and a Windows service that are built using a modified version of CSLA 1.5. CSLA was introduced to this business about 1 year ago, and the CSLA classes were intended to be used in all applications but the work wasn't completed in the other two. These applications contain all of the key functionality of the business and it is very important that these applications be converted for use with an offsite database.
The easiest option it seems would be to use .NET Remoting for these 2 applications. However, does this mean that I will require my prospective buyer to buy multiple sites from the shared hosting provider? I have never personally used a shared hosting provider. Can anybody recommend a shared hosting provider that will guarantee that all of the sites can access the database? Or am I wrong in making this assumption - can I configure my CSLA server to run on the same IIS site as my website?
I went back to read the "Visual Basic .NET Business Objects" book to see what it says about web services, and from what I gather the recommended approach to the architecture is to use the CSLA classes on the web server that hosts the XML web service. Since my Windows client applications already use the CSLA classes directly including its UI databinding functionality, using an XML web service this way would require an extensive rewrite of the entire UI layer.
It would be easier to create an XML web service that uses the data access code, and put calls into the CSLA classes to the XML web service to retrieve the data. Somehow this seems to go against the grain of what CSLA is trying to accomplish. Any opinions?
Just to be sure I don't get any answers like "who cares, you are selling it aren't you?", I should also point out that I may still be responsible for maintaining the code in the near future, so doing anything that would provide maintenance problems in the future would be counterproductive. I will also be responsible for making the conversions to the code to get these applications hosted elsewhere.
In a web app you ideally do NOT use remoting or web services to talk to any app server at all. It is far better (usually) to have the web server talk directly to the database. CSLA supports this as the default mode for the data portal, and that is typically the right choice.
Many shared hosting providers offer a virtual root with a SQL server database for that root. If you use the data portal in local mode, then you could install your app into the VR and have a dedicated database for that customer - which is also probably the right answer (maximum isolation, dedicated cost structure, etc).
Rocky,
Thanks for your quick reply. While I COULD port the website to CSLA, that really isn't my issue. I have 2 CSLA Windows applications that need to be converted to work with a remote database on the shared host (the website will work fine the way it is). These applications are used to manage the business (phone orders, order changes, order processing, automated bookkeeping, etc).
So, I am faced with the options of using XML web services or remoting to host these two applications locally, while my database and website are hosted remotely.
Remoting seems like it should work, but that probably means I will have to get more than one remote website to host the additional endpoints for the remoting components that access the database.
XML Web Services, while I don't usually consider them an option for "in house" software seem more viable because I can host the endpoints for both applications on the same virtual root as the website. However, this means that the "Data Access" portions of my CSLA classes will be remote calls to XML Web Services. As I pointed out before, this doesn't seem like the right way to go.
I guess a third option would be to rebuild my CSLA Windows application as a web based application, but given the number and complexity of the forms involved, this would be a monumental task. Not to mention, this doesn't solve the issue with the CSLA driven Windows Service that will also likely have to be run locally.
NightOwl888:
Remoting seems like it should work, but that probably means I will have to get more than one remote website to host the additional endpoints for the remoting components that access the database.
You may be unaware, but you can host a remoting endpoint from within a normal web site. In other words, the same virtual root that exposes your web UI can also expose your remoting endpoint if you desire. This does require that the web site's \bin directory contain the business assemblies used by the windows app, and Csla.dll of course. And you need the remoting entries in web.config - but that's all there is to it.
XML Web Services, while I don't usually consider them an option for "in house" software seem more viable because I can host the endpoints for both applications on the same virtual root as the website. However, this means that the "Data Access" portions of my CSLA classes will be remote calls to XML Web Services. As I pointed out before, this doesn't seem like the right way to go.
You certainly can rebuild your objects to call web services instead of stored procedures. This is a perfectly acceptable architecture/design - though it comes with some costs: performance, and of course the need to build a set of web services to support the data requirements of the objects.
The DeepData sample app from my web site (discussed on a recent DNR TV show) includes an example of loading objects from a web service.
I guess a third option would be to rebuild my CSLA Windows application as a web based application, but given the number and complexity of the forms involved, this would be a monumental task. Not to mention, this doesn't solve the issue with the CSLA driven Windows Service that will also likely have to be run locally.
Yeah, this seems like a very expensive option, and one that really shouldn't be necessary.
I just setup a remote data portal at www.webhost4life.com and I was surprised by how easy it was, and how good the performance is. It's no problem to have multiple remote portals accessing the one database either. In my case I created a separate subdomain for the data portal and that give you a seperate virtual root.
Funny, I was just looking at their website when I received the email about your post. I noticed that they allow you to put up to 8 virtual hosts on their server - that is 4 more than I need so it should work fine. In fact, this solves the entire issue because I just need to use remoting on the Windows Services as well.
As Rocky pointed out, it is possible to host the endpoints for all of the remoting components under the same root. I tried this some time ago and had some issues with it, I just don't remember what they were. At the very least it makes sense to seperate them physically for deployment purposes even if it isn't necessary for the applications to work that way.
Well, thanks to you any doubts I had about www.webhost4life.com are now minimized. I just have one question though (sort of a symptom of not doing development for a year, I guess) - how did you secure the endpoints of your remoting components being that they were Internet facing?
At this point I'm just testing a Beta so I haven't worried too much about security. The way I see it though, using a CSLA Windows Forms application with a remote data portal is not that different to a browser based application, and therefore the approach to security is the same. In other words, if you follow the guidelines in Rocky’s book it will be reasonably secure without doing anything special.
Of course I may be completely in the dark here, so please enlighten me if that is the case.
The only thing I might need to change is to secure the transmission with SSL. Although I haven't actually done this at webhost4life I don't think it is difficult.
There are two differences from a typical web UI.
First, your objects might pass data back and forth that would
never be sent out to a browser. Some of that data may be sensitive, and if so,
then you probably need to take steps to protect it further.
Second, there’s the issue of interception. The data sent to your
server from the browser is validated and otherwise processed AFTER it gets to the
server. In a smart client scenario the data is often (typically) validated and
large processed (calculations, etc) on the client BEFORE it gets to the server.
This means that a “man in the middle” who was extremely clever (able to
deserialze, change and reserialize the byte stream) could alter your values as
they went across the wire.
SSL addresses both issues. Or the remoting encrypting in .NET
2.0 can help address them (though you need some secure way of getting a key to
the client).
Things can get more complex from here though. Things like replay
attacks and other hacks that can occur if you have a “man in the middle” can be
very hard to overcome, though SSL does solve pretty much all of them as far as
I am aware. The remoting encryption probably solves the vast majority of issues
– especially if you put some sort of auto-incrementing message id in each
message (using ApplicationContext.GlobalContext probably), because then the receiver
of the message can check to see if that value is the expected value, thus
preventing the replay attack scenario.
As with any security issue, you need to do a threat assessment
and evaluate the cost/benefit/risk issues around each possible type of attack.
Then you can decide which scenarios should be addressed and come up with a
strategy.
Rocky
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.3/809 - Release Date: 5/17/2007 5:18 PM
Dave and Rocky,
Being from a banking background, I have a little experience regarding security. I agree with Rocky that putting SSL encryption in place is a great idea and it will protect any sensitive data while it is in transit. Personally, I prefer the SSL to the .NET remoting encryption route for the following reasons:
However, what my original question addressed was how to protect the .NET remoting endpoint. This is an entirely different matter altogether. Keep in mind, putting a .NET remoting endpoint on the Internet is like giving all the hackers in the world the keys to your database. In .NET using reflection to reverse engineer the .NET remoting endpoint into MSIL and then build an application that can call it is a trivial matter. And since SSL doesn't block any unauthorized acess to your server (after all, anyone can call a server with SSL installed), SSL alone isn't enough to protect your endpoint from hacking. If you have ever analyzed the logs of an Internet facing webserver, you are probably aware of the dozens of attempts by automated programs to find vulnerabilities on your server. Without a doubt, .NET remoting endpoints are something hackers will program their robots to look for if they haven't already.
I should point out that if you don't have any gold, you don't need to build Fort Knox. But if your database contains any sensitive data (personal information, credit card numbers, account passwords, etc) - even if they are encrypted in the database, securing the endpoint to your application is crucial. After all, your application has unencrypted access to this information, doesn't it?
One thing that makes .NET less secure than other languages is the easy ability to read all of the strings in plain text that are compiled into the application. It is a very important matter to put your database connection strings outside of your code - not just to make it easier to point to another database, but also for security reasons. Another thing to keep in mind is that configuration files that contain your database connection strings with the extension .config cannot be downloaded from the Internet, but if you use some custom scheme for configuration you should add your file extension to the list of files that cannot be downloaded (consult the MSDN documentation for this).
Two ways to address the specific problem of securing the .NET remoting endpoint (across the Internet) are:
Both of these methods can be implemented without changing a single line of code and will be completely transparent to your application. In addition, they can be used simultaneously. There are certainly other schemes that can be used such as .NET remtoing encryption, but most of them require you to modify your application in one way or another.
While the first method I mentioned isn't completely foolproof because IP addresses can be spoofed (althouh enabling this option certainly reduces the chances of being hacked), the second method brings you to a whole new level of security. Using a public/private key pair will ensure your server will reject any nontrusted computers from making requests to your server, and the only way to thwart this is to gain access to a certificate that the server will accept. Not to mention, you don't have to purchase a public SSL certificate because this public/private key pair will also encrypt the in transit data to the level you specify when you generate the certificate.
Granted, my description above is not complete of the whole process and it is recommended that your Certificate Server never be connected to any public (or depending on the level of trust in your organization, private) networks. But this should point you in the right direction. The MSDN documentation is a good source of information about creating and installing private certificates using MS Certificate Services.
A good source of information about security with .NET remoting (although the book is now a little dated) is "Advanced .NET Remoting in VB.NET" (there is also a C# version) by APress.
Dave, I guess the only question is which methods will www.webhost4life.com allow you to configure? Since the process of installing private certificates on a webserver is almost exactly the same as installing an SSL certificate, I imagine this is an option with your hosting provider, but since you have access to their control panel and I do not, can you tell me if they allow you to configure certificates? Do they allow you to lock down your virtual host to a specific IP range?
NightOwl888
NightOwl888,
Thanks for all that information - I'm sure this will be very helpful when I get to the point of needing to lock things down more securely. The main thing I had considered was the database connection strings, and by following the recommened procedure I believe I am pretty safe there. I have experimented with encryting the connections string section of the web.config which is easy to do in .Net2, but I haven't implemented it yet.
You can't configure certificates via the control panel but I'm sure webhost4life would have no problem installing a private certificate for you. Going back a couple of years I used to purchase my SSL certificates myself and would have to log a support request for them to install it. The process is a bit more automated now with standard SSL, but they're very good at handling non-standard configuration issues that can't be done via their control panel. In most cases they don't even charge for it. I'm fairly sure you can't specify a specific IP range for a virtual host, but again I would expect they would allow you to do this by logging a support request. I'm sure you could get them to confirm this without being a customer.
David,
After over a year of being sidetracked, I am back on this again. I am seriously considering webhost4life as the place to host my website and database.
After reviewing my options for securing the Internet-facing application endpoint, I still come to the same conclusion: I will likely need to host some web services in order to accomplish this.
I found this article from Microsoft which spells it out in black and white:
Do Not Expose Remoted Objects to the Internet
http://msdn.microsoft.com/en-us/library/aa302429.aspx
However, now I have an extra level of complexity - my CSLA 1.51 classes must be able to run locally or remotely through web services (instead of remoting). And those web services must implemtent WS-Security. They need to run locally now too because my web site now uses CSLA.
Anyway, I am just curious where your implementation ended up - did you find a way to secure remoting endpoints, or did you switch to web services? Every time I think about how much maintenance it will be to keep my CSLA classes and remoting endpoints in sync I cringe.
-NightOwl888
Yea, I found a related thread on this and I am starting to worry: http://forums.lhotka.net/forums/thread/6814.aspx
It sounds like it can be worked around somewhat because only certain functionality uses reflection. But then, I am using the same CSLA library in both my partial trust shared host provider and in a Windows application, so I may need to write some conditional logic in each case whether to use the functionality that requires reflection. That could amount to a large amount of work!
The thing I am most concerned about is securing the endpoint that will be sitting on the shared host so it can only be accessed the Windows client.
I am reading up on CSLA 2.0 right now, and I noticed it supports web services through the dataportal. I have yet to find out whether I can use WS-Security with this configuration, but it sounds promising. Then it will be a matter of figuring out which of these options can be implemented the fastest:
Since there are only about 15 forms in the Windows application and at least twice as many objects, #4 might end up being the easiest to implement, and would solve my security issue with no extra effort.
The long term goal of this application is to upgrade it to CSLA 2.x, so this is grunt work that will need to be done regardless of which option I choose. I have also been considering migrating the Windows application to the Web just for the sake of sharing UI components.
BTW - one of the Windows Services was incorporated into my CSLA library and another is no longer in use, so I am down to migrating just 3 applications (a Windows Client, a Windows Service, and an ASP.NET web site) for use with the shared host.
I haven't done any more on this as it won't really be an issue for me. The only time I will place the remote objects on a public web server is for my demo app, and the only consequence of that getting hacked is a bit of inconvenience.
If any of my customers want to use remoting over the Internet they will most likley use a VPN, so I think it should be fine.
Sorry I couldn't be of any more help.
It would be difficult to get any recent version of CSLA .NET to work in medium trust, because it uses the BinaryFormatter (or NetDataContractSerializer) and that isn't allowed. And it uses reflection, which isn't allowed (as used anyway).
There's the possibility that CSLA Light (CSLA .NET for Silverlight) may (with some tweaks) work when built against the .NET runtime too. If so (and we're quite a ways from trying this) it might address the medium trust issue. If this works (big if), then you could build a web site using CSLA Light (perhaps combined with the CslaDataSource from CSLA .NET?) that would run in medium trust, talking to an app server running with full trust, or talking directly to a SQL database.
But today you need full trust, and there's no easy way around that...
Thanks for the response Rocky.
It would be difficult to get any recent version of CSLA .NET to work in medium trust, because it uses the BinaryFormatter (or NetDataContractSerializer) and that isn't allowed. And it uses reflection, which isn't allowed (as used anyway).
I am currently using version 1.51 on .NET 2.0, but I plan to upgrade as soon as we can. Unfortunately I can't wait for CSLA Light - I need to move everything to a shared (or dedicated) host by October.
But today you need full trust, and there's no easy way around that...
I just got a response to a help ticket from webhost4life and they have another plan that sounds like it will work with fewer application changes (although quite a bit more expensive): http://www.webhost4life.com/advancevps.asp. Basically, they will allow me to install whatever I want on the server even though it isn't fully dedicated - I could probably even put the Windows Service there and it says they support Crystal Reports too.
They also answered my other help ticket about .NET Reflection and this is their reply:
"The .NET Reflection mechanism which you want to use should be supported by our share hosting service."
While I agree, yes it should - that still doesn't mean it will. Maybe I will sign up for their plan to see if I can get my other CSLA website to work there. So far, I am not too impressed with the blanket statements I am getting from their support team.
Then again, it seems that if they didn't allow serialization or reflection, it would be very limited what could actually be accomplished and they would run into this very frequently. Being that it doesn't sound like they run into people complaining about it not working, maybe they are running on a higher trust level than most shared hosts?
They also answered my other help ticket about .NET Reflection and this is their reply:
"The .NET Reflection mechanism which you want to use should be supported by our share hosting service."
While I agree, yes it should - that still doesn't mean it will. Maybe I will sign up for their plan to see if I can get my other CSLA website to work there. So far, I am not too impressed with the blanket statements I am getting from their support team.
Then again, it seems that if they didn't allow serialization or reflection, it would be very limited what could actually be accomplished and they would run into this very frequently. Being that it doesn't sound like they run into people complaining about it not working, maybe they are running on a higher trust level than most shared hosts?
Public reflection works in medium trust. Private reflection does not.
So if you make your DataPortal_XYZ methods public, it might just work. I'd mark them with the EditorBrowsable attribute then, to make them invisible to Intellisense so the UI developer doesn't accidentally invoke them.
But the BinaryFormatter or NetDataContractSerializer also use reflection - typically to get your private fields. Unless you are willing to mark all your fields as public you'll still be in trouble with serialization...
I am still inclined to go with the more expensive hosting option that undoubtedly allows you to run with full trust. Ideally it would be best to find hosting that meets my software requirements, not alter the software to meet the hosting requirements.
A virtual server is probably your best option if you don't want to stretch to a dedicated server. I think the VPS offerings at JodoHost are pretty good value. http://www.jodohost.com/windows-vps.asp I haven't tried one but I happily use their shared hosting and keep an eye on their forums. I think their VPS comes with access to an external SQL Server.
I found this article from Microsoft which spells it out in black and white:
Do Not Expose Remoted Objects to the Internet
This is generally good advice, because it isn't good on Microsoft's part to assume you know how to expose remoted objects in a secure manner. So by stating this clearly, they avoid anyone doing it wrong, and then blaming Microsoft for the results.
And really, you should think twice. And then again.
If you have a client out in the wild world, calling your server, perhaps you should be service-oriented. Yes, that's a lot more expensive and complex, but it often suits the requirements better.
But if you decide that the client, even in the wild world, is within your application's semantic and security trust boundaries, and if you secure your communication channel using SSL or WS-Security, then I don't see where there's a problem using the data portal to move your objects between client and server.
Copyright (c) Marimer LLC