Im wondering if this is possible. I would really like to ship my application with no configuration file (stop users fiddling with it). Is it possible to set all the configuration in memory in say the global.asax (application_start) event? For example I dont want users messing directly with the connection string I want them to be able to modify it in the gui only. And i dont want to have to write to the config file as there may be security issues....
you could still use the file system and have the files encrypted. In this way only you can modify or from the app, but no one can really modify the configurations directly from the file. Also you could encrypt Configuration Sections: Check this Microsoft Link out.
Good luck!
Related
I'm exporting an excel file that's created dynamically at run time from DataTables in aspx.cs file at server side using ClosedXML lib. I want to let user select the downloading file location at client side, which is currently moved to downloads.
You unfortantly cannot do this. This is also why you can never select a local file or location from server side.
So, the users local file system is 100% off limits.
And the reason is quite simple. If you come to my web site to look at some cute cat picture? Well, while you are doing that, do you think it would be ok if my web code also starts looking around at your files? Hum, maybe a file called banking? Maybe a filel called passwords? Hum, how about I steal all your email files? How about I look for a Excel sheet called passwords?
So, when it comes to poking around, looking at, and deciding things like file locations? You cannot on the server side GET ANY information, nor can you even find and define what file to pick for up-loading, and the SAME applies to downloading of files. If I could pick a location, then gee, why don't I start overwriting some of your system files - including some that would give me remote access to your computer, right?
So, things like what folder, what file, even the computer name etc? These things are 100% hidden, off limits and simple not allowed. Now it would be possible for someone to come out with a new web browser tht allowed local file rights and access. But then again, no one in their right minds would ever use such a browser, and the security hole would be too large. As a result, for reasons of security, such information, and even simple knowledge of the local file system is not allowed, nor even exposed to the web server.
But then again, the user might be on a iPad, or android phone, and their file systems and how their folders works is not even the same as say a windows desktop computer anyway.
However, you can see with above, that your ability or even options to mess with, or even choose local file locations is not allowed for reasons of security.
So, if you web site provides a file, or even streams down a file, it will go into the download folder as per user browser settings - you unfortantly can't change this - it works that way due to security concerns.
Scenario:
I want to implement user editable app settings in my symfony application but don't know what's the best practice.
The user should be able to edit global settings like company address or alike in the app backend, no user specific settings.
I had a look at the CraueConfigBundle, but I think a file based settings solution fits more to my problem.
It's difficult to find something on Google for my problem, maybe you can help me find that out.
What do you use to give your app admins the possibility to edit global settings?
For basic CraueConfigBundle can work for you (didn't use it just read docs) even tho it's saving to database.
Do you have particular reason why you need saving into file? You can always set up case to save data from database to file.
But if you want to write something in general, its require few steps like basically like this:
You need service which provide reading / uploading of configuration
This service can take use of adapters to do real Saving reading from your chosen source of data (for example you can use symfony Yaml component which can read / dump data from Yaml)
Then you need write user interface which suits your needs for that
It is fairly easy to upload a file using web form. But I need to accomplish this through DLL.
I have classic ASP page with file upload form and I need to create an object that handles the uploaded file from customer and save the file to the server. What would be the best way to approach this? I have been digging and came across Web.HttpPostedFile and HttpWebRequest. but I don't know which route to take.
Also, I am a bit confused about how to pass the uploaded file to DLL so my class can upload and manipulate the file. is there any sample code for this?
Thanks for any help or advice.
This question doesn't make much sense, as you kind of asking "I have old car's parts and I need to assemble one by using a wheel". What? That doesn't make sense.
A dll is a container for some code. You do not use a container per se to upload a file. You should search for "classic asp upload file sample", find a solution, give it a try and come back with a specific problem.
I also noticed HTTPS tag, the idea with S, is that you don't care whether it is secure or not from the programming perspective. If you are able to use HTTP, it is trivial to upload files to HTTPS - just change the URL in the UI. The server code itself wouldn't change. What will change is the server hosting configuration, you would have to add certificate details.
When you have a system of multiple application, web services and windows services, which is better option?
Option 1) Put all settings in database table and cache it somewhere, probably you will have to use a web service to share the cache object across applications. You can then view some of those settings in a grid for user manipulation.
Option 2) Put all settings in a common configuration file, and let web.config or app.config of each application points to that file, I am sure there is a way to put those settings in a grid, but probably you will lose the capability of "showing settings based on Role".
Thanks
A lot of this comes down to preference, what settings you're talking about, when you need access to the settings, and how often they'll change.
Generally, I try and keep my web.config & app.config pretty small. Settings for infrastructural things (e.g. modules to load, connectionstrings, log settings, ORM settings, etc) go in there. Anything that I really need or want to have access to on App_start or in my Main() method, basically.
Anything more complex, or that's applicable to less of the application, etc, I generally don't put in the config files, but instead either have settings objects which I inject through my IoC container, or else pull them from a database.
I prefer option 1, as it makes deployments easier, as each environment can have different configurations, yet you're still able to do a xcopy deploy, as settings aren't stored in the web.config.
I would suggest putting the configuration in the database and then retrieving it based on the application. You can also write a single XML that contains different configurations and load it on the datagrid etc..This way management of the configuration becomes easier, because you have a single file to maintain.
Why do we store connection strings in web.config file? What are the benefits of doing so?
The web config file is used so you can reference the connection anywhere in your app. It avoids having to deal with a fairly long connection string within your application.
Here is a good article which may give you detailed information: http://articles.sitepoint.com/article/web-config-file-demystified#
There is even a wiki page for it :) (surprisingly):
http://en.wikipedia.org/wiki/Web.config
If you ever move / change to a different database format the connection string setting inside of the web.config file can be changed in one place rather then digging through your entire application looking for it. This also avoids having to recompile or build an application to get the new connection string setting.
If you are wondering how to access the information from within a web.config file that can be found here:
http://msdn.microsoft.com/en-us/library/4c2kcht0(VS.85).aspx
There is also sample code right in there.
Imagine you have several classes which access your database; you can:
Place your connection string in every class
Create a constant to store that value
Place it inside your configuration file and to refer it
These have following characteristics:
Every time a connection string changes, for instance, migrating from development to production environment, you'll need to change everywhere;
By using a constant, you just need to change a single place. But in this case, when your string needs to be changed, you'll need to recompile it.
Same as above, without that recompile part. You can to develop your application and other people set that database connection to you
So, by storing a connection string into your web.config file you gain more flexibility to change that setting than other alternatives.
Reason #1
As everyone is mentioning, having the connection string in the web.config makes it easy to update/change as needed. It becomes a single source where the arguments can be easily be changed.
Reason #2
Beyond that though, IIS is configured not serve up web.config to users who request the file. If your website is,
www.mydomain.com
someone can't hit http://www.mydomain.com/web.config and scrape all your confidential settings, passwords, and so forth.
(As a side, note, IIS won't serve up files in the App_Code directory either to a user, so the web.config file isn't unique in this respect.)
Reason #3
ASP.NET automatically detects changes to configuration files and will immediately applies new settings.
More info..
MSDN has a discussion of the ASP.NET configuration system at,
http://msdn.microsoft.com/en-us/library/aa719558%28VS.71%29.aspx
What I like most about having the connection string in the web.config is when you have multiple environments that you test on. Say you have a Test server, Staging server and a Production server. Well you don't need to have code that checks which server you're on, or have to recompile different versions for each... just use the web.config to store your connection strings and that way you can have a different web.config on each server but the same web application with no hassles. You may want to Encrypt your Connection String Settings as well so they're not visible to everyone that has access to the folder.
You can reference them using the ConfigurationManager via the ConnectionStrings property.
http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.connectionstrings.aspx
It allows the connection string to be configured by someone maintaining the site.
You don't have to re-build the application if the connection string changes. An admin can make the change and the code remains the same.