As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is using a constant in the global.asax a good idea?
It's always go to, what are you holding in such variable?
I keep my main settings (READ ONLY) variables in my web.config file in the <appSettings> area, for example:
<appSettings>
<add key="AmazonS3:CalendarPath"
value="http://mycloud.s3-eu-west-1.amazonaws.com/Calendar/" />
</appSettings>
and access such values with
string calPath = System.Configuration.ConfigurationManager.AppSettings["AmazonS3:CalendarPath"];
Either in my Views or Controllers.
This is a lovely place to hold your read-only variables as, no mater if your web application is built or not, compiled or showing all source files, you can easily change the variable to what you need, without opening a compiled file, change it and compile the project again... saves a lot of trouble and gives a certain dynamic to the hole application settings.
If by other hand you want a READ/WRITE way of saving variables across your application, you have 3 ways, all with pros and cons
Use Session State to save the variables This is the most used, but it's terrible on Cloud Platforms as the request can change servers and the new server that received the continue request of the user, does not have the session
Use Cookies to save user variables Cookies can be modified on the fly by the user, so we only use this to save settings that are minor changes, like UI definitions.
Use a Cache Layer to hold the variables This is the most used in Cloud Platforms as not only you can save settings, but you can also save portions of data that you access most of the time.
There is also the Application Settings on global.asax witch was very used back the Classic ASP days, since then I never have used them as they have the same flow as the Session Variables, witch are placed in memory... any Application Pool reset, any new build, all session are lost.
There are also, plenty of posts that you ca search to have a better knowledge of all options you have to save variables cross application on your ASP.NET project.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
In a multi-client scenario, where client entry points are sub-domains, I am wondering if I could separate my clients into directories that contain essentially the app ( like cache, config, logs, kernel) and then symlink back to a "core" Symfony directory for the rest (vendor, src, and web). This lets me keep the application unified in regards to my bundles, but provides me with a separate config for each client. Then I point my sub-domains to their respective directories.
On the surface, it seems to be promising, and simpler than some other approaches I've been considering.
Later down the road if I want to upgrade a client to version 2 or add a component, I can switch bundles, or even point the symlinks to a whole new source. It might also scale well.
I am also wondering if using this approach would allow me to maintain separate security contexts between clients, as opposed to checking sub-domains and redirecting to authenticate if a user manually switched sub-domain.
Downsides would be duplication of several config files, and more involved initial client setup (but honestly nothing to bad in my opinion).
Is Symfony2 flexible enough to handle such a re-arrangement?
Are there benefits like speed or security separating the caches in multi client app?
Would using separate firewalls in each config result in separate security contexts for each sub-domain?
Background/Additional information:
I am re-developing an application to be multi client/tenant. I am using Symfony2 in the re-design since the original sat on top of Doctrine and I need more robust framework features now. I want to maintain a single application (its the same across all clients) and have individual databases for each client. My expectations are 100-200 clients max realistically (if I go over that, I'll celebrate and then worry about it). The schema is the same between databases, I am separating for ease of backup/restore and for separate upgrade paths later.
I have spent time reading numerous questions and answers about multi-tenacy. Also about using routing and kernel listeners to use sub-domains to glean client ids and then dynamically selecting the Database Connections, etc.. I ended up finding a blog post from Orm-designer.com outlining what they did when they moved their site to a new VPS. They detailed their directory structure in the post and it got me to thinking about how I might adapt the concept to suit my purposes.
If I understand you correctly you have:
your application based on Symfony 2,
database structure,
several machines,
You need to:
deploy your app on ~200 nodes (they could be located on different
machines),
keep the configuration easy to maintain,
use the same source code for each application,
You need to:
implement maintenance mode in your application,
decide which files are user specyfic,
all files that are not user specyfic sym-link to client folder from some shared place,
implement rsync script to update the files that are common for all users,
Each time you want to update version of your application:
let client know that your application will not be available for some
time,
put all applications into maintenance mode,
rsync the common code among all machines and clear cache/deploy assets for each client,
if needed prepare backup and run database update scripts,
run functional tests on all client machine and switch off maintanence mode,
Client Folder:
Machine 1
SourceFolder
app
bin
src
Company
YourBundle
*Controller
Resources
config
*css
...
...
*vendor
web
Directories with * are sym-links to to folder shared by several clients on the same machine and rest of the directories are user specyfic.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I've just migrated and deployed my first Azure Web Role this week and now that the pressure is off to get it deployed I'm reading "Azure in Action" and after reading about configuration settings the whole thing rubs me the wrong way.
This seems fine for migrating AppSettings type configuration settings. However, what about settings in system.web, system.webServer and system.webService or other more complex configuration systems. If I want to be able to modify my WCF configuration settings my current options are:
Make the change and do a full deploy (build, upload to staging, switch VIP)
Extend WCF thru a custom behavior or whatnot to use the Service Config (cscfg) instead.
I thought maybe I was misunderstanding the use - like the examples were simply the very naive case and that in practice they were used differently. However, after googling for a while it seems that this is exactly how everyone is doing it. For example, instead of using the connectionStrings configuration element for Entity Framework connections I have to write a custom connection factory.
This not only seems like too much work, but it ties my entire configuration implementation to Azure. Yes, I can use an interface so I can abstract the details and replace the implementation if I need to. But I still don't like all the extra work, connectionStrings are simple, but there are much more complex things to override.
What I'm thinking is that I should be able to do is read the Service Configuration at startup and use the ConfigurationManager to update my web.config. If something changes at runtime then again, I can update web.config. This way my application is still portable and I'm not hardwired to the Azure configuration system.
Does anyone agree? Or is it just me?
What I'm thinking is that I should be able to do is read the Service Configuration at startup and use the ConfigurationManager to update my web.config. If something changes at runtime then again, I can update web.config. This way my application is still portable and I'm not hardwired to the Azure configuration system.
In that case, what would happen if Azure restarted your role? The configuration would revert to that in the Service Configuration. If you're running multiple instances, configuration can then differ between them with potentially dangerous results.
An option is to build (once) a customer configuration provider that picked up settings from somewhere else (such as Table Storage) rather than web.config or .cscfg
With your configuration provider abstracted behind an interface, you can exploit Dependency Injection to provide the appropriate configuration mechanism for your deployment model.
I feel your pain, but it's really only a problem that needs solving once.
it ties my entire configuration implementation to Azure
For an application to properly take advantage of Azure you'll end up tying much more than just configuration implementation!
For example, table storage is much much faster than SQL Azure, and even with SQL Azure there are differences regarding e.g. the requirement for clustered indexes.
It's worth remembering that unlike virtual hosts, Azure is not an abstraction of Windows Server: it is a platform in its own right, with its strengths and weaknesses.
In the case of configuration settings it's in my view entirely reasonable for them to be relatively hard to change on production boxes. It's obviously a different matter when developing and testing, however; and to that end there's Azure Web Deploy, which lets you do a "disposable" deployment in a few moments.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
As far as my understanding goes Modules kann be used to split an Application into different parts.
A big advantage seems to be to be able to load Module after Application Start, to get a better Startup performance.
I personally would like Modules to make me able to have an own Code Sandbox for the Module Code.
So neither the Main App Code nor the Module Code should influence each other. But for examples CSS Styles from modules influence the Main Application an visa vers.
My Question:
1. What can I use Modules for beside Runtimeloading ?
2. Are there options to run code in an own sandbox ? For Example via Loading swf assets ?
What can I use Modules for beside runtime loading ?
You can divide your application into distinct pieces - For example, you may only need to update the shopping cart portion of an application rather than the entire application. This lets you do that without deploying the entire application again. This forces good abstraction and means less regression testing / bugs.
Another benefit is securing the swf files themselves. I've written back end applications where a user might be able to get to the orders screen, but not the user management screen. Because each are a modules, the client never even gets an opportunity to see (or decompile) the user management swf code - because I can validate the user's session server side when they try to load a module. This is an extra layer of protection.
Memory management -its not just about loading the application, but how much processing it takes to have all that functionality loaded at once. If a user only needs one or two screens, why load the other 98 screens?
Portability and code reuse. You might use the "order viewer" module in both a consumer facing application and a back end tool. Those are most definitely not the same application, but they both need the basic functionality of the order viewer. Better yet, an entirely different application could use that same functionality.
Are there options to run code in an own sandbox ? For Example via
Loading swf assets ?
There are special considerations for communicating between modules, here is a good read for you:
http://livedocs.adobe.com/flex/3/html/help.html?content=modular_2.html
You can allow a module to deal separately with its styles by creating a new SystemManager for its flexModuleFactory, and you can load it into a separate applicationDomain for security purposes.
Not really an answer to the question you asked, but it addresses the underlying problems you were having.
We used modules at my last job to allow us to develop and add new functionailty on the fly--the path to the module would be stored in a database and loaded at runtime.
HTH;
Amy
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are others ASP.NET Security Best Practices?
So far identified are listed here:
Always generate new encryption keys and admin passwords whenever you are moving an application to production.
Never store passwords directly or in encrypted form. Always stored one way hashed passwords.
Always store connection strings in tag of Web.config and encrypt it in configuration section by using protected configuration providers (RSA or DPAPI). See example here
Use user ID with least-privilege to connect to SQL server or the database you are using. E.g if you are only executing stored procedures from a certain module of application then you must create a user ID which has permissions to execute only.
Use PrincipalPermission if you want to use role-base security on pages.
[PrincipalPermission(SecurityAction.Demand, Role="Admin")]
public class AdminOnlyPage : BasePageClass
{
// ...
}
Always use parameters to prevent SQL Injection in the SQL queries.
Consider installing URLScan on your IIS servers to protect against SQL Injection.
Also, for protecting against XSS attacks. You can use MSFT's AntiXSS library instead of the built to encode output instead of the built in HtmlEncode found in HttpServerUtility.
Always keep on customErrors in web config to make you errors/exceptions private
<customErrors mode="On" defaultRedirect="MyErrorPage.htm" />
In web applications, always validate the user's inputs for html tags or any scripts.
Never store sensitive information, like passwords in cookies.
Don't display system error messages, stack traces etc, in case of exception.
I found Microsoft's Developer Highway Code to be a useful security checklist.
Microsoft has a lot to say about this subject:
ASP.NET Web Application Security.
Improving Web Application Security (an entire book dedicated to the subject)
Never store sensitive information like passwords in cookies.
Don't display system error messages, stack traces etc. in case of exception.
Check out the new Security Runtime Engine (beta came out on November 14):
http://blogs.msdn.com/cisg/archive/2008/10/24/a-sneak-peak-at-the-security-runtime-engine.aspx
http://blogs.msdn.com/cisg/archive/2008/11/13/an-update-on-some-upcoming-free-tools.aspx
This should replace the current Anti-XSS library.
Anthony :-)
www.codersbarn.com
While displaying content from database on the page, you may use HttpServerUtility.HtmlEncode to encode output to avoid Cross site scripting (XSS) attacks.
Consider installing URLScan on your IIS servers to protect against SQL Injection.
Also, for protecting against XSS attacks, I would use MSFT's AntiXSS library instead of the built to encode output instead of the built in HtmlEncode found in HttpServerUtility.
You could be interested in this article Security Best Practices: ASP.NET Applications.
HTH
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Let's collect some tips for evaluating the appropriate use of global.asax.
It's simple to use if your session and application initialization code is very small and application-specific. Using an HttpModule is more useful if you want to reuse code, such as setting up rules for URL rewriting, redirects or auth. An HttpModule can cover everything a Global.asax file can. They can also be removed and added easily using your .config.
I've used it before to catch errors at the application level, and to do something when a user's session expires.
I also tend to use it a lot to provide static properties that read values from the web.config.
I think it ok for stuff like that, though I wouldn't put much more than that in there.
Initializing ASP.NET MVC. :)
Custom user authentication.
Dependency injection, like extending the Ninject HttpApplication.
Its a stiff drink, just be careful not to drink too much and you'll be ok.
I use it for global error handling, and setting up routes in mvc. You don't want to be writing global page_init code in there though.
If you stick to application level events, and make most of the logic actually live in classes that just get called during those events, you will have no problem making use of the global constructs.
It's a nice spot to grab session initiation, and even request initiation. Others have mentioned the error handing aspect, although be careful of exceptions thrown from non-asp.net threads (eg. threadpool or custom thread) as they'll bypass the global.asax handler. Personally I always have one, I think of it as simply part of the plumbing.
I used to use Global.asax for things such as error handling etc, however, I have since gone to using HttpModules to replace this as I can copy it from one project to another without editing the global.asax.
Con of using Global.asax compared to an HttpModule : You will be tempted to write code that's hard to reuse because it will be too tied to that particular application.
I haven't really used Global.asax. I used it's equivalent in classic ASP all the time, but that had mostly to do with certain configurations like database connection strings and such. The config in .net makes a lot of these things a lot easier.
But if you want to implement application and session level events, this is where ou need to go.
Global.asax can inherit from your own class that inherits httpapplication. Gives you more options as well as putting the bulk of the code you might have in global into a class library.
EDIT: Having your HttpApplication class (global.asax parent) in a seperate class library can promote reusability too. Although i agree that using HttpModules is better suited for many tasks, but this still has many uses, for one, cleaner code.
The Session_Start event in Global.asax is a wicked good place to initialize your session variables.