I have hundreds of sub-web.configs who have same app settings so I was wondering if it's alright to merge them all and put them into root web.config.
If you're the developer, or if you can chat to the developers so you can be sure that they are all likely to keep on sharing the same values, then I say go ahead and do it. Bear in mind that future apps deployed onto the server would also have access to those settings, so if you if you can't trust them, and if the setting values are confidential, you may want to keep those separate still.
Related
So I may have a bit of a strange situation here, and I need some guidance.
The company I work for has a number of small sites, with each site selling a different custom program. The sites are badly in need of an entire rewrite from top to bottom, and my boss has agreed that a login and online purchase/registration is required. This means user accounts, the ability to download a trial from within the user account, the ability to register that trial also from within the user account and the ability to view a list of previous purchases/registrations and product keys.
The thing is, I want a sign-on from one site to be usable on another. Plus, all of this will need to be administered (on our end) from one admin interface. So my thought is that this will all have to be driven by a single database.
Just to be clear: the front-end for each site needs to be different - sometimes only subtly, but in some cases by quite a bit (marketing differences). The backend (both Admin as well as for the Client interface), is identical in structure regardless of the site URL, but the Client interface needs to show different content (programs to download, lists of computers where the program has been registered on, etc.) depending on what URL is being used.
My problem is that I am not entirely sure how to do this from a code-first perspective. The sites are small, quite easy to build on their own, but I want them all within the same Solution so that a change to the model will be reflected across all of them (I will be able to see where things go sideways if the model gets altered - Intellisense is my friend!).
I have looked into Areas, but Areas seem to be a way of partitioning off gross differences within a site (things like resource files - JavaScript, CSS, etc. - remain in the root, whereas in my case each site will need different resource files). I need each section to be its own unique site, with its own unique URL. When this gets pushed to the server, I need each site to be “independent” in that they can sit in entirely different accounts on the same Windows Plesk server (Plesk was not my choice, but the company has clients that need a control panel interface to their own accounts). The only strong commonality between any of them is the database that they will make use of -- in fact, all of them will be making use of the same tables, with very few differences between the sites.
My other problem is that I do not know how to properly implement having multiple projects within a single solution, and all projects making use of the same model that is implemented/constructed only once. I have not yet made the jump to Repository Patterns, so I am completely in the dark with respect to that functionality.
If anyone has a suggestion, I would love to hear about it.
Essentially, you just need to create a class library where you will put your entities and context. If you're using Identity, you'll also put all the Identity-related entity classes here. You'll enable migrations on this class library. The other projects in your solution, then, will have a reference to this class library. You'll need to add the connection string to the individual projects' Web.config files, but other than that, everything will just work.
This is enough to ensure that all the projects are working from a common database and user store. However, in order to actually share authentication, such that signing into one, signs you into all them, you'll have to take one of two paths, depending on how they will be deployed.
If all of the sites will be on the same domain (different subdomains are fine). Then all you need to do is generate a machine key and ensure that each site uses the same machine key in its Web.config. The auth cookie will be added on the wildcard domain, and any subdomain of that domain will be able to see it. Sharing the machine key is to ensure that they can each decrypt it what any one them sets as the auth cookie.
If not all the sites will be on the same domain, then you're in for some pain. You'll have to set up a SSO system, which is non-trivial and far beyond the scope of Stack Overflow to help you with. There's entire companies devoted just to building SSO systems for organizations.
I've currently got a reasonably large site up that i've been asked to make changes to.
Currently To login to this site you need to go to:
www.example.com/folder/loginpage.html
This site is only accessible internally at this time and it is unlikely to ever be accessible externally.
We would like to, however, be able to direct external users to a sub-directory on the site (a 'survey' form) which is located in
www.example.com/folder/subfolder/survey.html
This survey writes its results back to the main application and i believe they are integrated tightly.
We initially tried the idea of using an additional IIS7 box as a reverse proxy however it is quite confusing to me, i'm not very familiar with IIS/ARR and the other features required (i'm mostly familiar with networking). I did try and follow a number of tutorials but didn't get very far. I'd like to avoid it if possible.
How can I, using IIS7 (this site is in ASP.NET) restrict external users from accessing anything other than the survey pages (there are a few included files necessary as well)?
Is it possible to make www.example.com/folder/subfolder/survey.html a 'website' in-itself so that i can publish a URL like survey.example.com externally?
I've come across other examples where access is restricted from specific pages but the root of the site is still accessible
ie
www.eg.com/ is allowed but www.eg.com/admin.aspx is denied. I'd like to the the reverse in effect, and if possible, hide the 'true' url.
Hope someone can help! If using a reverse proxy is possible i'm happy to do it but i'd need detailed instructions.
Thanks for reading,
Much appreciated!
Edit: Sorry all, I'm new to stackoverflow, indeed I've just realised that there are several other sub-communities. Is it more appropriate to ask this in a different community? If so, which one?
Thanks!
I usually place an app_offline.htm in my root directory when I am releasing a website to a production environment. However sometimes if there has been a few big changes to the site, I would like to click around first to make sure it's stable without allowing access to anyone other than me.
As far as I am aware this isn't possible, but I'm hoping someone has a neat solution...
The solution has to include if someone has a deeplink into the site, so using a default.htm/asp page in the root won't do the trick unfortunately.
I agree with the staging environment answer above, but otherwise here's one possible approach: Temporarily block all IP addresses besides your own. This can be achieved through IIS Directory Security configuration, or programmatically in any number of ways
You can redirect all the non-authorized users to an Under Construction page of some sort. Meanwhile, you can happily browse the site from your IP. When the site is vetted, you remove that IP restriction and the site becomes available to the world at large.
It's a difficult thing to achieve. That's why you should have a staging environment where everything should be validated before shipping into production. Then during the deployment process (if it takes long, but it shouldn't) you could use an App_Offline file. This staging environment should be as close as possible to your production environment (in terms of software, patches and configurations installed, not in terms of hardware power of course).
Another quick suggestion that would allow you to control things from the web.config might include a custom module that redirected all requests to a static page except those defined by a filter (i.e. hostname, url sniffing) that could be configured via the web.config.
Is it possible or feasible to run a bunch off web sites off of only 1 code base?
For example I have 1 site that bases it's connection string off of the domain name or subdomain name. So, depending on what domain/subdomain is hitting the site the site returns content that is stored in a database specifically for that site.
What types of issues might occur from doing this? Specifically if doing this with asp.net.
It's quite acceptable.
Just note that anyone can change the domain name that you may pick up (as long as you've configured a host header for it), so just make sure you don't go around making something like 'admin.foo' but relying only on that for security (you'd be mad though, obviously).
I see no problem with it.
It works and is proven. Se DotNetNuke for just 1 example of this.
Request come in. Regex/character matchthe domain name. Load settings for that domain (base path to images, css, config, pages etc etc) and off you go.
The gotcha to look out for is if your application is both a) storing data in memory and b) using the same application space. So if, for example, you want to dish up two different blogs and you want the data to be resident in memory (if, say, your back-end store was XML and you didn't want to parse XML with every request) then you'll have to make sure that Asp.Net sees each call as a separate application (which can both point to the same file-system folder and thus uses the same files).
I ran into this exact situation when coding a multi-blog data provider for BlogEngine.Net. It uses a single code base to serve up different blogs based on the requested URL. However, since BlogEngine.Net carries its data in memory, the data provider won't work unless IIS is configured so that each blog is its own application.
I'm building a static ASP.NET site (using Masterpages and a few forms) and I'm about to release it onto my production server.
I know about changing <compilation debug="true"> to false, but I'm wondering what other things I can do to obtain the highest speed possible. There is no data access in the site, it's all static content.
Does anyone have a checklist they run through or know of a good resource for setting up sites in a production environment, with a focus on performance?
Checklist so far (Feel free to edit this yourself with any worth additions)
Make sure <compilation debug="false" /> is actually set to false in Web.Config
Make sure <trace enabled="false" /> is actually set to false in Web.Config
Set necessary read/write/modify folder permissions for site
Enable GZIP in IIS (reduces size of pages/css/javascript dramatically)
Have you considered OutputCaching for any pages / controls?
Consider setting up Web Tests (Eg WatiN for .NET) to make sure functionality on your site is still working ok
Make sure it isn't Friday afternoon!
If you're writing any log or output files, make sure the proper folder permissions are setup in the production environment. Typically debug/test environments are much more lax on file read/write permissions than production.
Don't deploy on Friday afternoons! This is guaranteed to mess up your head for the weekend.
Also, don't forget to check the gzip settings in IIS. Compressing output will make things travel across the wire much faster.
There is actually a very good checklist on how to perform a security deployment review provided on MSDN.
if its all static content, you'll want to use aggressive Output Caching
If your site use a database and only presenting information, make the database read-only. That takes away all locking handling and speeds upp the access a great deal.
If you have a back-end that updates the data, make it a separate database and have sheduled periods that update the readonly database once a day or what is needed for that application.
If you just present news and other small things on a company web-site that not change so often then this solution is probably for you. Even if its a site with gigabytes of data.. The key word is, how often does we update the data?
From what I see in daily business,noone really thinks about this solution because everything has to be "real time", but there are plenty of cases where this would be a perfect solution.
Review your web.config
Check debug (web.config / *.svc), tracing, ...
Update debug to production values:
email addresses
(web)service addresses
location log files
quick search: link
You should have some sort of test to verify various functions of your site, and the permissions. For instance, once you publish. Walk through a checklist, can I access x if I don't have permission? Does x,y,z work on the application? I do this after every publish because small changes can have a big impact.
You should read this:
https://stackoverflow.com/questions/72394/what-should-a-developer-know-before-building-a-public-web-site
It's currently the 9th highest voted question on SO and in the top 3 most favorited. The caveat is that it's platform agnostic, so it's missing some ASP.Net-specific items.
Thoroughly test the site outside of your corporate firewall / proxy after clearing your browser cache. This will help to ensure that all resources are publicly accessible (and are not on a local server or cached). For instance, you might find that you have used absolute URLs to include, say, JavaScript or CSS files. These work fine in your development environment, but as soon as the site goes live they are inaccessible. Or you have a CSS file in your cache that has subsequently been deleted, but you don't notice.
Ensure that any products / applications you use that have keys that are tied to a domain will work on your live site. This includes things like Google Map keys or commercial 3rd party applications. It also includes automatically generated hyper-links sent out in, say, emails. You wouldn't want a user registration to have a link back to http://localhost/comfirm.aspx or the like, would you?