This can be a lengthy topic... Following the MVC design pattern, when building any web app it's best to funnel all data access through a single Data Access Layer (DAL). This is in preference to having MV-related code in every page and class throughout a web application. This makes maintenance easier, allows you to switch the back-end for some or all functions, and allows for changing connectivity tools - all without changing the entire front-end. This also allows you to get one person to do the front-end access and someone else to do data access. Someone who grew up on a green screen may not be adept at creating an attractive or fully functional UI. It also follows that someone can change the front-end, even to something completely different like a web service, without any changes to the DAL.
One of the best security methods is to not give people access to source. Put your DAL into a DLL and take the source off of your deployment system. If someone hacks in there they will be much less likely to find vulnerabilities in your DAL code. And because .NET code can be de-compiled, obfuscate your assemblies. Security is handled at different layers including transport and application. Transport security means using HTTPS from client to server, and maybe SSH or tunneling for web server to DBMS. Application security involves authentication and authorization. In other words, only allow people in with an ID and password, and then ensure that only people who fit a given role are authorized to access specific functions. This prevents someone with a generic ID from maliciously or accidentally executing things they shouldn't. Do not allow users to enter data which then gets executed blindly by queries. I think this is one of the biggest faults in MV applications when a new UI is added. This is known in the RDBMS world as SQL injection but we are just as subject to queries being tweaked if your code does not carefully screen data entry. I don't use UO.NET so I can't comment on its pooling details. I do sell, support, and develop with mv.NET which has its own pooling mechanisms, and that allows fine-tuning of license limits. mv.NET is a superset of UO.NET, and even uses UO.NET underneath as a basic transport tool. I've also found that UO.NET requires full permissions to do almost anything, and no one seems to be able to tell us what the absolute minimal permissions are which are required to run it. That's not very security-friendly... For assistance with any of the above, feel free to contact me. Tony Gravagno Nebula Research and Development Worldwide distributor for mv.NET TG@ removethisNebula-RnD.com Robert Kubarych wrote: > Does anyone have any security best practices for building web > applications using UniObjects for .NET? > > I've placed the connection string in web.config and encrypted it, as > well as created a separate remote account with a stripped down VOC. > The only data files that can be accessed from this separate remote > are the two that the application needs to access (via pointers the > main remote account). I also tried to dial down the asp.net trust > level runs with, but it seems that uniobjects for .net needs to run > with full trust. > > I guess it's not possible to use connection pooling until UniData 7.1. > We are still on UniData 6.1. Is there some other method I could use > to limit the number of licenses the web application can grab? ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
