[2005] Best practice: MVC and secure connection string(s)?

Hi everyone! :wave:

I'm developing a fair sized web application and it's my first go at MVC - both desigining and writing it. I'm using VS.Net 2005 and have made a decision not to use the new ASP.net MVC framework (if I'm right that's just for 2008 anyhow). Anyway, I have this setup:

1. ASP.Net website, webpages & codebehind only for page control (event) interaction and handing everything else off to controller middle tier.
   
2. Controller .Net DLL for buisness logic, calculations from input values passed-from above, and handing any database interactivity-requirements over to model, 3rd tier.
   
3. Model is a second .Net DLL with classes to conect to, and interact with a database, passing values back through the above layout to the client.
   
4. An additional, secondary part of the model is the database itself, with stored procedures.

Now then, this gets interesting when I think about the connection string.

• Previously, I've always placed this in a web.config file, but passing it down the layers seems an additional burden and possibly open to man-in-the-middle attacks.
• I completely want to avoid hardcoding the string anywhere for obvious reasons (if the database changes).
• My train of thought is to place an xml config file at the same directory location as the model DLL(s), and though I can secure access to the folder using Windows security.

I'm wondering whether I'm taking the best approach and want to throw this one open in order to welcome any comments on the security, any used practices in your organisations which might be better to take or any other tips or thoughts from you all please.

Many thanks!!
Alex :D :cool:

Is this an internet website or a intranet site? If the servers are open to "man in the middle attack " between IIS and sql server there are major security issues.

The web.config is a good place for the db conn string, why hard code it any where else - it has to be somewhere the site code has access to.

It seems to me like you're reinventing the wheel with your XML file solution. The web.config is alright for this. Maybe you should explain your man in the middle attack fears.

Hi guys, thanks for replying. :D :) :thumb: (&& :afrog:)

Through all the jobs I've been in - even the huge companies, I've never written any websites which are more than website on single web server communicating direct, or via dll on same server, to a database on a seperate, second server. I've been developing for 10 years now and think I should start training myself and thinking more of things like MVC, security, remoting, server farms etc. which I've never taken part in or been shown before.

I'm writing an app at the moment and building it for extensibility as much as possible, lets say for arguments sake that it was a bookshop and could potentially turn into Amazon, or a bidding site and could potentially turn into Ebay.

If I have different servers for (1) processing web requests, (2) for listening and processing calculations (3) databases, I can't help but think storing connection strings on the 1st hurdle/step (a web.config file on a web server) which is exposed to the Internet can't be best practice (as in the MVC/MVP patterns this side should just be for altering end user controls), and that the server(s) and related processing dlls which communicate directly with the database(s), should contain the connection string information at their end, further away from the exposed website.

I was hugely interested to find any advice or tips from anyone who might've worked on these type projects, who have read papers on this sort of thing which I'm still trying to find & download, or any general comments or advice on this.

Thanks

I see your concern, but IIS protects access to web.config; meaning that you can't request websitename.com/web.config. I haven't seen it not been done this way but as far as I've talked to others, this hasn't been commented on. Had it been commented on, there would be entire topics around it. So, using web.config on a web server is alright, that's what it was meant for.

Now, that aside, I'll combine my answer with general comments. If you have one server just for processing requests, and another for your business logic, I think that it's not going to achieve the efficiency that you may be aiming for, as there is going to be an amount of latency involved as opposed to class libraries being loaded into memory. If the middle server actually has a few class libraries which you're referencing, then it's definitely a bad idea, because the class libraries will need to be loaded into memory. If it's a web service on the middle server, then you are loosely coupling your application, that's fair enough.

Now fair enough, you haven't worked on large scale websites, but I think you should be looking at web farms. You build your application as you normally would. Then you simply deploy it to your multiple web servers. A load balancer takes care of requests coming in and assigns them to a server.

I have (do) worked (work) on large websites, but I haven't worked on amazon.com or flickr.com; however, the principles are usually the same for any heavily hit website.

I second what mendhak said. I'm no .net guru but have worked on corporate sites for some years now and a standard setup is a dedicated server running the site and if needed a seperate db server and possibly mail server.

If the time comes that webfarms or co location are needed your site should be running very efficient scalable code and smoothly move accross multi servers.

I think that's the most important point, how well the site runs. Adding more hardware will not fix resource or bandwidth hungry coding.

Hi guys :wave:

Many, many thanks for the suggestions and opinons, they really help! Brin - I was trying (and hopefully am :p) writing scalable code at the moment btw, but thanks also. :)

The side question I was thinking of, in relation to this question too was whether the way I'd always been taught to write sites - that is just writing front-end and processing sites and COM+ or .Net dlls and hosting them all on the web server, with just a secondary database server was the right way to go about it. Whether to move processing to third and fourth servers or not, and it's been fantastic and fascinating to hear you all code the same way - and just upscale the 2 servers into a base of 2 farms. That's very interesting to know!

Many many thanks for your time and thoughts :)

Well hopefully you're feeling better about your perceived lack of knowledge in this area now.

Yep definitely cheers. It's good to know you all use the same methods as I was taught too.

I also found this interesting article which I'll put here as it's relevant. http://msdn2.microsoft.com/en-us/library/ms978701.aspx - looks like I was thinking of a 4th tier by the looks of things!

I'm going to stick with the usual 3 tiers for the moment & upsize with server farms until it really gets huge, then I'll worry about the addition of an app tier and all the remoting code tweaks later on if the site does go E-bay size.