Persisting User Specific Settings in ASP.NET Server-Side - c#

I'm working on a .NET 3.5 Web Application and I was wondering what would be good way to persist user specific settings (i.e. user preferences) server-side?
Here are the conditions:
It needs to be able to store/retrieve
settings based on a User ID
I don't want to use SQL Server or any such DB engine
I don't want to store it in cookies
Any guidance would be greatly appreciated.
Edit: If it makes any difference, it doesn't have to support a web farm.

Use the ASP.NET Profile feature for this. See ASP.NET Profile Properties Overview

If you want to persist data, and you don't want to use a database, then you need to save the data to disk (such as XML). If you're looking for something that isn't local to your server, you could use a SaaS solution that would host your data for you, such as Amazon's S3 service. If you do that, the latency of data retrieval will slow your application down, so you'll want to cache the data.

Text files (JSON/XML/etc), though security then becomes an associated problem.

Given those parameters, you could just keep track of your own user preferences XML file on the server.

Related

Reading from a confidential file

(See what I did there?)
I am developing a WinForms application which needs to retrieve information from a file which contains sensitive information. The information retrieved is used to perform some complex calculations, but it includes things like salaries of certain pay bands for employees of a large company. The WinForms application will eventually need to be deployed to members of that company, but I need to make sure that I do not reveal the contents of this file to them.
The file itself is a JSON file, and is currently stored locally within the Visual Studio project file structure.
If I was to "Publish" this application through Visual Studio's Build menu, and release it through a web link, would people be able to open up this JSON file and view it? If so, is there some way this can be avoided? I have considered storing the file online and accessing it via HTTP request, however I don't really know much about that so could do with some advice.
Cheers,
Josh
If I was to "Publish" this application through Visual Studio's Build menu, and release it through a web link, would people be able to open up this JSON file and view it?
Yes.
If so, is there some way this can be avoided?
Only by not publishing the file.
You should look into storing this information in a database that can only be accessed through an authorised account via HTTPS. I'd recommend using WCF as it will integrate well with C# and WinForms. The best approach would be to perform the calculations on the server side (either in the WCF service itself or as stored procedures in the database). Thus you only need to gather the inputs on the client, pass these back to the server and then display the result.
You can also do things like logging all attempts (successful or not) to access this data so you have a complete audit trail. You can also expose your WCF service to other clients if necessary.
I would look into creating a separate (WebAPI or WCF) service that has access to that file and knows how to serve up the public facing portions of it to your application.
So let's assume the file lives at \\hrserver\C$\sensitive.dat. Your service has access to that file, but the client applications do not. Your client applications access the service (https://hrserverhelper/GetHrData), which encapsulates the authentication/authorization to that file. It then parses out the sensitive data (perhaps from the JSON you already are set up to create for that file), and passes the non-sensitive data to your client application.
If it turns out that all the data in the file is sensitive, then have your service provide operations to perform the calculations that your WinForms app performs currently. For example, your WinForms app submits the inputs it wishes to perform to a WebMethod that knows how to perform those calculations with the sensitive data - the WebMethod spits out the results.
However, in this scenario, be aware that basic mathematical skills will likely be able to reverse engineer the "sensitive" data here. If I submit 2 and get back 4, and I submit 3 and get back 6, I'll assume the "sensitive" number is 2.

How to audit an asp.net/SQL Server user

I am building a very simple asp.net application that will have a SQL Server 2008 backend.
Some users will be entering data and storing in the database and some users will be viewing data.
The SQL Server 2008 is working with Windows authentication for every user; however, I am unable to get ASP.NET working with Windows authentication yet. Is there a simple way to allow windows authentication with ASP.NET? I found a very convoluted way, but I don't like it.
I will need to audit every action that the users perform.
Should I audit the users at the application level or at the SQL Server level?
Are there already built in methods to do this? If so, how?
On the contrary, I have always found Windows Authentication to be quite easy to set up and relatively painless. Here's some guides:
Setting up
More Setting up
I didn't realize that you could audit what users did at the ASP.NET level. My answer would be to use SQL Server for this one. You'd need to log:
timestamps and user name for every action
do you need to log workstation or location where the actions were performed?
can users go to mul
if multiple locations use this application, consider storing UTC time only
all actions, even deletes, which mean that delete's only get "hidden" from the user, but never erased from the database. Same for edits, the old record should never be changed or taken out of the database.
Your best bet here is to talk to your boss about this one. Auditors can have very specific needs, and you definitely don't want to forget anything. Every situation is different, so be sure to sit down and double check all your requirements and specifications.
Two things:
Here is example on Win auth on asp.net app:
http://weblogs.asp.net/scottgu/archive/2006/07/12/Recipe_3A00_-Enabling-Windows-Authentication-within-an-Intranet-ASP.NET-Web-application.aspx
I suggest you implement a log framework like log4net to log your application. It's simple and easy to use http://logging.apache.org/log4net/download.html
I would do this from the application if it is significant HOW people accessed the data as much as the WHO, but that's quite different from rlb.usa's answer. In my past jobs, it's often been as important to know which application the person changed data from as when/who. If it's primarily for application issues, log4net is a good option.

web based remote connections in c# advice

I am going to write up a webapp hosted on a windows 2003 server to allow me to connect to local and remote servers to do some basic things.
The webapp will be hosted on serverA. It will need to be able to copy files/folders from one folder to another on this server.
It will need to be able to connect to ServerB and copy files in the same way, e.g. copy \serverB\path\to\sourcefiles to \serverB\path\to\destinationfiles
ServerB hosts an installation of MSSQL 2008, I want to be able to create new database/login etc.
How do I go about this please? I've been reading a bit about Windows Authentication, Impersonation, Delegation but i don't know where to focus on.
thanks
S
To be honest there isn't really a one size fits all complete answer to your question, however there are a number of things that you need to take into consideration early in development to ensure that your platform is built on solid foundations.
From the description you have given the most critical consideration has to be security and everything you develop has to have this at its core. Judging by your post if the wrong person was to access your front end then they could wreak havoc.
As for the model to use, I would suggest Windows Authentication as this is built into the framework and gives you the ability to segregate into usergroups with differing levels of access. It will also open up some of the functionality you need, i.e. network copy of files etc
As for the database management aspect, this again can easily be done via Windows Authentication as you can grant (in SQL) windows users the ability to perform certain tasks, i.e. Create Database, Create Login, drop x, etc
All this said, it of course assumes that the two servers share user credentials, i.e. domain controller etc.
Another method, would be to use the web "interface" as a pass through onto a WCF service that operates under a specific user account that has the access you need. You would then seperately manage authentication/authorisation in a manner that you decide.
Like I said, no simple one size answer - but hopefully this will give you something to chew on.
If your goal is to create new databases or logins, why can't you use the create database and create login commands?

How to share sessions between PHP and ASP.net application?

My company took some old php application over. Due to our preference to ASP.net and to the lack of any documentation from the previous developer, we do not want to spend much resources on developing in PHP.
For implementing new features, we will create an Asp.net application that has the same look to the user. We want to develop a kind of 'coexisting' web application. Therefore we must share sessions between an PHP and an Asp.net webapplication project, because there is a usermanagement involved with an existing MySQL database.
(e.g. link 'A' directs to the PHP website, and link 'B' directs to the asp.net application)
How can we share the session between and PHP and an asp.net application?
And does anyone have a hint for this 'coexisting' thing, that might be useful in development?
Edit: IIS 6 would be our targeted server, altough IIS 7.5 would also be an option
I want to tell you, how I ended up doing it.
Both applications access a MySQL database and access a "session" table, which consists of a Guid, the ID of the user, and a confirmationString (I guess I encoded the IDUser in it, somehow) and a date.
Sessions are only started by the PHP application (due to the fact, that the PHP application is still the main application). A new session will result in a new entry in the log table. Every link in the PHP application, that links to the ASP.Net application contains GET-Parameters, containing the Guid etc.
The ASP.net application checks for the GET-Parameters and sets the IDUser in the ASP.Net Session, if the GET-Parameters point to an existing session.
The links pointing back to the PHP application use the same technique.
(There are also other things to consider, like timeouts or logouts, but that can be handled as well)
All in all, I'd say that my approach is useful and none of the customers complained since the deployment (over 1 year ago)
I don't think it's natively possible to share sessions between PHP and ASP.NET.
However, it might be possible by using a PHP page that reads the contents of the session, stores them in hidden fields and then call an ASP.NET page that would read these fields and load them into ASP.NET session.
Theoretically it's possible.
This is an old question, but I didn't think any of the current answers were complete.
First, I think it is a bad idea to store session data in a database server like mysql or SQL Server. The DB is a precious resource, and there's really no reason to thrash it just for session data.
If you are going to store session in a database like that, there are "better" ways of doing it, like making sure that the session data is on it's own independent disk, etc... but honestly, I still feel like it's a mistake and will limit your scalability.
For storing session, you want to go with a simple key/value store, and in my opinion you can't beat memcached (though I've also had good luck with redis + nodejs).
memcached has clients available for pretty much every language on earth: http://code.google.com/p/memcached/wiki/Clients
So, basically all you need to do when using memcached is generate a pseudo-random token for the key, and do a memcached.set. Then store that key in a cookie called session-id or something.
The session-id cookie can be read from any server language, .net, php, python, whatever - and the session value retrieved with a simple memcached.get.
Check out the memcached docs: http://code.google.com/p/memcached/wiki/NewStart
This is a very simple and scalable way to do sessions, and will work with almost any language/server.
http://cz.php.net/manual/en/function.session-set-save-handler.php
http://support.microsoft.com/kb/317604
You can write PHP's sessions into MsSQL, and configure .NET to use MsSQL as backend for sessions.
Not a big deal.
Your asp app should do a three simple things:
Recieve a sessionid cookie from the client
look for the sess_<id> file in the PHP session save path
implement a PHP serialize/unserialize functions to read/write session data.
A nicer way than just hacking into session storage mechanisms on both sides would be setting up OpenId provider and plugging OpenId consumers to both asp.net and php applications.
There's lot of existing code to do it. It would be both more elegant and error prone than the low level solutions. As a bonus you could use integrated OpenId login in the rest of your company applications and become a company hero.
See: Using OpenID for both .NET/Windows and PHP/Linux/Apache web sites
Oh dear, maybe one day you'll see the error of your ways, in the meantime.....
By default, PHP writes its session data as a serialized array into a file named according to the session. The session is identified usually by a cookie with name PHPSESSID.
So in PHP to manually read the session:
$imported_session=unserialize(file_get_contents(session_save_path() . '/' . $_COOKIE[session_name()]));
The format of the file is very straightforward and simple to parse.
However its quite easy to implement your own PHP session handler to write the files in any format/to any storage you like (have a look at auto-prepend for how to associate the revosed code with every page without having to rewrite each one). Or change the name the cookie used to store the session.
C.

Sharepoint Authentication for Access by a Web App

I am using sharepoint solely as a repository to store and retrieve large files (~100 MBs). How can I authenticate a web application such that it can upload and download files to a document list on Sharepoint 2007 without using Windows intergrated authentication?
The web application will handle the authorization - it'll figure out which users are allowed to access the repository via integrated windows authentication and a bunch of business rules that depend on the application's state. When the user wants a file they will use the web app. The web app will then download that file on the user's behalf using some sort of credentials. I prefer that these credentials be somewhat permanent so it's password doesn't expire every so often. I was thinking of using basic authentication because the files that I'm access controlling aren't high valued files (so its poor security is tolerable), and it seems to be the simplest. What are my options?
I wouldn't recommend using SharePoint for this at all. Its value comes from the features it provides through its user interface. If you remove this then you are looking at an expensive and over-complicated data store.
SharePoint stores all data in a database. Storage for databases is more expensive than storage for files. It's more costly to configure, administer, backup, load balance, scale, etc...
Development time is more costly with SharePoint. It's a big and complex product that's not trivial or quick to develop against. There needs to be a solid business case and using SharePoint for its back end only isn't a good one.
Please seriously consider this approach before going down it!
You are better off just enabling windows auth on your web application and then setting the permissions to the folders/files.
If you do need to get just the files however...go to www.codeplex.com and search for sharepoint powershell. There is a script there to upload stuff. This could be modified to download I believe.
As mentioned above, using SharePoint as a repository pretty much nullifies any of its benefits. You might as well just use a database to store your content (that's what SharePoint is doing behind the scenes anyway.)

Categories

Resources