I am looking to store a few random global settings in an ASP.net MVC4 application that would affect the entire application.
These setting need to be editable by the admins of the site (i made a small form)
They are things like current site wide discounts, promotion expiration dates, keys to partner services, etc.
They dont fit in a database because they are single (scalar) values that don't fit into any list (or table). They should just be in some singleton object at the application level. Yet the need to be persisted - once an admin changes the value they dont want it to be reset just because the server (or application) was reset.
I thought of storing them in the web.config file through the setting object. But I publish upgrades on a regular basis and that would overwrite the we.config on the server.
You could use the following;
Database (prefered)
XML File
Plain text file
Any of these would give you a way of storing the information and a simple interface to read and write would allow your application access. You can then store these in either the Application or Session objects and use them accordingly.
Related
there are few variables in my application which i need to set and are used at various places.
Which is the best place other than web.config file to store them.
Write a class with static members that are set on Application_Start() inside global.asax
If these variables can change their values after application has been built then web.config is the best place to store them. Other options can be database, registry or in short, any persistent medium. Of course, to use these values through-out your application, you should have a wrapper static class that will expose these settings as properties. Settings will be read once at application start-up (or on demand whenever first requested.)
I have few settings which I could place in a separate XML file and have them accessed in the Web app. Then I thought (thinking of one additional file to deploy), why not have them in the web.config itself. However, just because I need to have custom nodes, I can not have the settings under . So, I am thinking of creating a custom config handler following this. Would that be better than having a separate XML file? Is It going to be an overkill or performance wise? Is there a better way to go?
From performance standpoint putting custom settings in web.config and creating a configuration handler will be OK because the config values are cached and read only once when the application starts. Putting the values in a separate XML file you will need to handle the caching your self if you want to avoid parsing it every time you need to access those values.
I have one requirement from client where they want to browse and save their choice Logo image in a website which i am developing.
Really i don't know how it happens and Is there any issue like security i need to consider while implementing this logic?
Please help me to solve
How user (client) will browse image file and where should i store that file in server?
Every indivisual user can browse file of different size and different name; how can i manage at server side so that image appear at right place and in right manner?
Where should i store image corresponding to user id at server; i.e. in database or file?
Is there any security issue/ folder rights when saving file at server?
Please help?
asp.net has a built in file upload control.. that should be all you need
http://msdn.microsoft.com/en-us/library/aa479405.aspx
https://web.archive.org/web/20211020140211/https://www.4guysfromrolla.com/webtech/091201-1.shtml
http://ondotnet.com/pub/a/dotnet/2002/04/01/asp.html
There are also some awesome Third Party controls that have far more power... I happen to like the RadUpload
This is all dealt with the built in controls
Not sure what you're asking in question 2
If images are user specific, then you should store them in some unique file (I personally prefer using the UniqueIdentifier of the UserID in the Membership Provider... It's harder to "crack" than an ID number (depending on how hidden these image need to be)... you could also store in the database if you need to keep the images completely away from the application so that they cannot be accessed outside of you application.
the application needs to have write permissions to the folder that your storing the images in if you choose to store in a folder instead of the database.
I've been reading others questions regarding storing settings in the web.config. Most of you agree that's a good way to store settings.
I just have another doubt about that.
In my app, I need to map some ID's in the web.config. For example:
[Table = UserType]
1 - User
/2 - Admin
Is it a good idea to store these settings in the web.config so I know what is the right ID in my application? Do you have a better solution?
Thanks guys,
G
If that values doesn't change too often, it's better to create a enum to store that values. An enum sample could be:
enum UserType
{
User = 1,
Admin = 2
}
For more options, also take a look into [Flags] attribute: Enums, Flags, and C# — Oh my! (bad pun…)
Keep in mind every time you edit your web.config file, your IIS application pool get recycled.
I typically use the web.config to store things like connection strings, or key/value pairs that rarely [or never] change.
What you described would be ideal for an enum or perhaps a look up table in the database.
In my web application I have a number of "Configuration" settings that exceed the structure of the Web.Config file, and don't want the web site to restart after changing them.
I ended up creating a number of xml config files where the xml data maps to objects that get cached into collections. This allows us to change the config on the fly, while not restarting the web site. We have a filewatcher that triggers a reload of the cache objects from the Xml files when something in the configuration directory gets modified.
You can also use the database for this obviously, but in our case this was configuration data that is maintained by development and deployed with the build.
What would be the best method to implement the following scenario:
The web site calls for a image gallery that has both private and public images to be stored. I've heard that you can either store them in a file hierarchy or a database. In a file hierarchy setup how would prevent direct access to the image. In a database setup access to the images would only be possible via the web page view. What would be a effective solution to pursue?
[Edit] Thanks all for the responses. I decided that the database route is the best option for this application since I do not have direct access to the server. Confined to a webroot folder. All the responses were most appreciated.
Having used both methods I'd say go with the database. If you store them on the filestore and they need protecting then you'd have to store them outside the web-root and then use a handler (like John mentions) to retrieve them, anyway. It's as easy to write a handler to stream them direct from database and you get a few advantages:
With database you don't need to worry about filestore permissions or generating unique filenames or folder hierarchies etc.
With database you can easily apply permissions and protection directly - no trying to work out who can view what based on paths etc.
With a database you can store the image and metadata all together - when you delete the metadata you delete the image - no possibility of orphaned records where you delete from database but not from filestore
Easier to back-up database and images and then restore
The disadvantage is that of performance, but you can use caching etc. to help with that. You can also use FILESTREAM storeage in SQL Server 2008 (and 05?) which means you get filesystem performance but via the DB:
"FILESTREAM integrates the SQL Server
Database Engine with an NTFS file
system by storing varbinary(max)
binary large object (BLOB) data as
files on the file system. Transact-SQL
statements can insert, update, query,
search, and back up FILESTREAM data.
Win32 file system interfaces provide
streaming access to the data.
FILESTREAM uses the NT system cache
for caching file data. This helps
reduce any effect that FILESTREAM data
might have on Database Engine
performance. The SQL Server buffer
pool is not used; therefore, this
memory is available for query
processing."
Using file hierarchy, you can put the files out of the website file folder, for example, suppose the web folder is c:/inetpub/wwwroot/somesite, put the file under c:/images/, so that the web users won't be able to access the image files. but you cannot use the direct link in your website neither, you need to create some procedure to read the file, return the stream.
personally I think it's better to put the file in the database, still create some procedure to retrieve the binary image data and return to wherever it needed.
In reality both scenarios are very similar, so it's up to you... Databases weren't designed to serve files, but if the size isn't really a concern for you, I don't see a problem with doing it.
To answer your question about direct access, you'd setup the file images the same way you would for the database: You'd use some sort of page (probably a .ashx handler) that serves the images, allowing you a layer of logic between the user and image to determine whether or not they should have access to it. The actual directory the images are located in would then need to either a) not be part of the directory structure in IIS or b) if it is part of IIS, only allow windows authenticated access, and only allow the account the application process is running under access to the directory.
If you're using IIS7, since .net jumps in the pipeline early I believe you can protect jpg files as well, just by using a role manager and applying roles to file system folders. If you're using IIS6, I've done something similar to the answer by John, where I store the actual file outside of the wwwroot, and use a handler to decide if the user has the correct credentials to view the image.
I would avoid the database unless you have a strong reason to do this - and I don't think a photo gallery is one of them.
Neither. Amazon S3 offers a very simple API for accepting uploads. You can use SimpleDB or your SQL database to track the URLs and permissions. Set the entire S3 bucket to private, and authenticate to it using your AWS key on the ASP.NET server.
Very little code is required to upload to S3, and very little more would be required to perform bookeeping in SQL.
Once they're in S3, grab the image resizer library and the S3 Reader plugin and you can have your entire system running in under an hour. And - it will scale properly. No disk or database space limits. Ever.
You can implement authorization using the AuthorizeImage event of the Image Resizer library. Just throw an AccessDeniedException if access isn't allowed for the current user.
If you want to tune performance a bit mare, add both the DiskCache and CloudFront plugins. CloudFront can edge-cache the public images (inexpensively), and DiskCache will handle the private images, serving them at static-file speeds.