I'm trying to implement ASP.Net FormsAuthentication across many applications. I have already got a working prototype of this that shares the same login in couple of applications. As described here, the applications need to share some settings for this to work, for example the machinekey-section:
<machineKey validationKey="C50B3C89CB21F4F1422FF158A5B42D0E8DB8CB5CDA1742572A487D9401E3400267682B202B746511891C1BAF47F8D25C07F6C39A104696DB51F17C529AD3CABE"
decryptionKey="8A9BE8FD67AF6979E7D20198CFEA50DD3D3799C77AF2B72F"
validation="SHA1" />
I would like to have these settings in one place and use them in all of the applications. It would not make sense to have the same settings in 10 applications. If I want to change a setting, I want to do it in one place and have all the applications to use that afterwards.
Is it possible to have these settings for example in a class library project which the other applications use? How would you implement this? I tried the configSource-attribute, but I think I cannot use it with a config-file inside the class library. Am I right?
What other approaches have you used? All comments are welcome. Thanks!
The best solution would be to define it in your web.config and include it in your deploy packages. Therefore, when you deploy a new version with modified web.config, the changes will be deployed everywhere.
You can also use the xml transforms (http://msdn.microsoft.com/en-us/library/dd465326.aspx) to ease the management of these settings (debug and production settings may be different). You can then use a different project configuration (and therefore, web.config settings) for each publish profiles.
The main advantage is that the whole process is then automated, less error-prone.
Related
I have an ASP.NET MVC project that is deployed via Visual Studio's Web Deployment - all works fine so far.
I now need to deploy another version of the same project (e.g. for a different customer) - with the same code base/functionality, but with a different layout, i.e. other CSS and images (maybe even with different views/Razor code). Ideally, the content from the other configuration would not be published at all.
I know I can use different connection strings for the persistence layer - but is there a way to configure also configure other content elements?
I'd like to avoid having two versions (or later even more) that required branching/merging - but rather like to simply deploy the latest version with the different "themes"...
I have a MVC project with 4 class libraries. And i deployed it into 3 other domains.
I copied only MVC project without controllers or code classes for each client, and added them into my solution. I use them only for visual changes or themes. Not for server side functionality. So the copied projects' assemblies shouldn't be deployed. Only the UI files should be deployed. Assemblies are deployed from the original MVC project's output folder.
I build solution and publish dll's into 3 domain, and publish only each client's UI files into it's server.
This enables me to develop server-side functionality in only one MVC project. Separate UI files from server side functionality.
Hope this helps.
are you using MVC then?
What you can do is to override the default razor engine and create your own. What the razor engine does is mainly to map your requests to views in particular folders, you can tell the razor engine when to map those requests to views in one folder or another.
MVC4 Razor Custom View Locator
A full fledged explaination is here :
http://nickberardi.com/creating-your-first-mvc-viewengine/
That is for views, if you just want the CSS or JS to be different, you just have to map your requests to a razor bundle and then vary what the content of the bundle is depending on a variable, or the pressence of a configuration file, or by filling a variable with a value from the database.
As you can see here bundling is very easy :
http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
Say your html points to : /assets/mycssbundle.css , but what that file would actually contain can be altered by where you tell to the bundling function that the files are located.
This seems like a design question. If you foresee possible changes like this in the future, and you already swap content via DB, then you should consider loading css file from database. There're of course many other ways to do this but simple and efficient is preferable.
This would mean structuring your html properly to ensure all layout is properly handled via CSS and can be achieved via ViewData or ViewBag. See case example.
Edit:
Not css data but the relevant css file.
You have two options:
A) Develop a custom view engine that switches between different page sets depending on the configuration. This will allow you to switch between the page sets just by changing the web.config settings, which fits well with the visual studio's built in deployment model (different web.config transformations kick-in for different deployment environments). One implementation that comes to mind - switch between view engines for different deployment environments (in different web.config transformations).
Unlike the other suggestion to load pages from the DB, I would recommend loading them from folder or physical location (e.g. different view engines targeting different sub-folders of the project). DB approach is not developer friendly when it comes to developing and fixing pages and their markups that are in the DB.
B) Develop all page sets (all variations) under the same project and then write custom deployment scripts which deploy particular page sets depending on the deployment environment. Drawback of this approach is that it's hard to notice issues like page sets intersecting or links crossing the page set boundaries.
While plan B sounds a little bit simpler development-wise, it can become a nightmare maintenance- and deployment-wise.
So, I recommend plan A.
Your Question is too broad.
However we have also a similar use case. We put all the theme related stuff (css, images, etc) as an embedded ressource in a separate assembly. We have Customer1.Theme.dll and Customer2.Theme.dll etc.
The App loads dynamically the Theme.dll and references the ressrouces from there.
Among other solutions,
assuming that you are using asp.net mvc.
and assuming that you have content1 and content2 folder available in the same repository or making available in same repository is not a concern.
and assuming your are bundling your contents.
and assuming your images are referenced only using css.
You can have a app config key which will tell you whether you want content1 or content2.
something like,
<add key="sitecontent" value="content1"/>
Now in your Application start in global asax, read the app config key and depending on the value, call the
BundleConfig.RegisterContent1Bundles(BundleTable.Bundles);
BundleConfig.RegisterContent2Bundles(BundleTable.Bundles);
I think this is a design issue. As you can see below you can organize your .net application in different layers:
Source: Microsoft
There are some key principles (Separation of concerns, DRY, etc) that Microsoft strongly encourages through the .net platform and I believe will find good use in your project.
Based on what you describe a simple approach is to keep in one project -same for all clients- your business layer (including the Services or the Data layer - even with different connection strings for each project) and create separate projects for the Presentation layer.
You may find more information from Scott, CodeProject, or more traditional methods (BTW this is a great book).
We have different web based products. All the products share same underlying authentication and authorization mechanism. All are on same database server and are ultimately published to same server.
Each project has its own namespace, folder structure and pages. Still due to the fact that authentication and authorization is shared, we use login and other pages across all the projects.
Also to make look and feel uniform across the projects/products we use same master pages.
Currently we have a separate project which contains code, markup and scripts etc. for shared things. We copy the markup and other things to all the projects to build and run them. It is really a hell. We have to include/exclude the files, change namespaces etc. all the times and over that make sure that shared things are at same version in all dependent projects.
What would be the best methodology to handle all this in a way that we don't go to asylum?
We are on ASP.Net 4.0, Visual Studio 2010, Telerik 2013 Q1 release.
You have several options to improve your situation. The best option for your will likely depend on more than the information you have provided, however the following may be worth investigation.
Decouple authorisation system. If more than one application is using a single common authorisation code base then you may want to consider decoupling the functionality into a standalone (probably web service based) application. Authorisation through such an architecture is tricky, and easy to get wrong from a security point of view, but is achievable. The authorisation code base will then only need to be maintained in one location which will inevitably reduce deployment and building mishaps.
Extended configuration management. Does your application have any configuration management capability? If not, it should. It may well solve your problems with regards to includes and excludes and namespace chopping, especially when combined with point 3.
Improved version control management. It sounds as if you possibly aren't making the most of your version control system. Although you allude to versions in your question, if you were maintain different branches of a common trunk for your different applications the chopping up of namespaces and includes and excludes would probably be reduced or even not necessary since customisations could co-exist.
Disclaimer: I have limited ASP.Net skills
I have a couple of websites which I am transferring from my current hosting onto the Mosso hosting service. When I tried transferring one of the websites, I got the error "System.Security.SecurityException: That assembly does not allow partially trusted callers.", which appears to have to do with the fact that Mosso runs on Medium Trust for ASP.Net apps, and the code in the website appears to require full-trust.
Unfortunately, I don't have access to the full source code for the app, and the original developer is not available. Is there any easy workaround to porting these websites? I tried adding in web.config but that didn't work.
I don't think asking Mosso to adjust the security level is an option, because they had refused when I asked them.
Does anybody have any ideas?
Is your assembly strong named? Does it call strong named assemblies?
You should apply the 'AllowPartiallyTrustedCallers` attribute to the Assembly. More information about this attribute is available here.
From the docs:
By default, a strong-named assembly
that does not explicitly apply this
attribute at assembly level to allow
its use by partially trusted code can
be called only by other assemblies
that are granted full trust by
security policy. This restriction is
enforced by placing a LinkDemand for
FullTrust on every public or protected
method on every publicly accessible
class in the assembly. Assemblies that
are intended to be called by partially
trusted code can declare their intent
through the use of the
AllowPartiallyTrustedCallersAttribute.
See this MSDN article for more information.
Edit:
Some information that confirms my suspicions that the APTCA attribute is a possible solution to the problem:
https://support.isqsolutions.com/article.aspx?id=10334
http://bloggingabout.net/blogs/rick/archive/2006/04/07/11929.aspx
Sorry to say but unless they allow you to set the trust level, you could have big issues. You could have a look here.
Professional ASP.NET 2.0 Security, Membership, and Role Management
Almost exactly the same thing happened to me, except the my hosting company changed their trust policy after I a number of websites running on their servers for a couple of years. In the end I had to give up and move to DiscountASP as they overrode <trust level="Full" /> in my congfig file.
Here was my original question.
ASP.NET WebPermission Security Exception
Good luck
I know this is old, but I thought I'd add something to it that might help. Mosso's change to Medium trust caused us some issues as well.
We use BlogEngine.NET and access MySQL for its backend. We had the MySQL dll in our bin directory and that was causing issues with medium trust. Once Mosso added a MySQL dll to the GAC, we were able to use it successfully.
Obviously, I don't know your particular details and what you are trying to do, but if it is related to MySQL, let me know.
Scenario:
Let's say I have four very similar applications (i.e. most of the functionality is the same, but they are different enough to justify each being seperate applications).
What is the best way to re-use the common functionality code between them? COM+? Web services?
In general I'd typically just have the code in a seperate project (dll), but anytime that's updated, the file has to be updated for each ASP.Net application, and wasn't sure if there was a better way of going about it.
Thanks!
If possible, you can create a Visual Studio solution with a DLL Project and a number of Web Application or Website projects. The web projects would have a "project" type reference to the DLL project, and everything would build at the same time. Then you could use the "Publish" tool for each of your web projects as needed.
If all the apps are on the same virtual server, consider placing the shared assembly in the GAC. This allows you to diverge versions should the need arise, and keeps everything in the same place as a bonus. Downsides: this assembly runs with full trust and you should use policy and CAS to ensure there are no elevation of trust leverage points for external untrusted assemblies. You'll also need to learn about the [AllowPartiallyTrustedCallers] attribute.
As for the other choices, COM+, meh, a bit heavyweight. Good for transactional stuff. Web services, not so good for data heavy services, but if done right, can be fairly maintainable. The more it's shared, the better the pay off.
You can have your project, but instead of adding the common dll to the project reference add the common project to all solutions and then add a reference to the common project.
This way you can have one project on any number of solutions and you have your problem solved ;)
I'm doing research for an article on the ASP.NET Pipeline, but none of the resources I've covered so far adequately explain when the machine level, and application level, and possibly even sub-application level, web.config files are read.
Also, most of my reading has mislead me to look for default HTTP handlers etc. in machine.config, which seems to, at some point, have been mysteriously replaced by a web.config at the machine level, i.e. in the same config framework folder as machine.config. Are that many articles etc. so out of date, or was this a very recent change? Or, may I be imaginative and consider that the machine level web.config actually 'inherits' from machine.config?
The most comprehensive description of how asp.net configration files work that I know of is this one at MSDN:
ASP.NET Configuration File Hierarchy and Inheritance
It is written for the .NET 3.5 framework so the info should be as current as you'll likely find. It describes exactly how the various configuration files are read and merged into the runtime settings for the application in quite a lot of detail.
ASP.NET config files work in a hierarchical manner (much the same way as CSS elements).
Configuration Inheritance