I have an application that is run on multiple user systems, and using OAuth, allows the users to log in via Facebook, Twitter, etc. The entire point of the user logging in is to get settings and actions that the same user made while logged in on other computers, as identified by logging in with the same OAuth provider + provider user id. The application itself is written in C++ using Qt.
My question is this: how can I save the settings that a user made, and allow them to retrieve it in a secure way? I have a centralized server that I can store information using MySql tables, but I'm not sure the best way to have the user application prompt the server, and receive the data stored for that user.
Any ideas or places you could point me towards?
There are several ways I could think of with this, all have trade offs:
Generally I would store the data in mysql using some kind of string or object encryption/serialization method. I do not use Qt much but http://qt-project.org/wiki/Simple_encryption has some examples of very simple encryption that could be used.
Then the question becomes: What do you use as the key? I would go either with the key provided by OAuth for that user (which could be an issue if users de-authorize the app but still want access to this data) or some other user provided key (which is counter to using OAuth in the first place).
Another option is to go with Qt Users session http://qt-project.org/doc/qt-4.8/qtwebkit-guide-cache.html
This would maybe remove the need to encrypt since it should only be accessible within the users scope.
NOTE: Based on comments below it seems the issue is more about securing communication with the MySQL versus the data inside of MySQL. Waiting on user comments to revise my answer.
i would like to know a good software engineering way to store user preferences in a web app.
to clarify further, my app has commands that the user can choose, so
i added a button that when some commands are selected, these commands are saved as favorites somewhere on the client's machine, that way if user X logs in at anytime he can check his favorite commands and load them automatically..
how to save these commands and where? and taking into consideration that several users using the same computer should not have access to each's favorites, so i want the favorite to be saved based on userID. where and how to save them? cookies? xml? and using php or javascript is better?
thx a lot for your help:)
The best way to do this is have them log in whenever accessing your site. Then you store all of the preferences on your server and deliver them down through your UI to their browser. This will mean that it doesn't matter what browser/device they happen to be using, their settings will follow them.
I'm not sure I like the idea of modifying someone's "favorites" in their browser. I'm not sure I'd stick with a site that wanted that level of control over my browser.
Now, if you are just talking about having a page on your site that had a list of "favorites", then that's okay. Just keep it server side.
Most typical would be to store them in a database of some sort on the server side, easily accessable by the UserID. Keep in mind 'preferences' are different from 'state'. State variables are usually stored via whatever cookie mechanism you are using.
What is your web app using to hold the data on the back-end? Most likely, that is where you will want to store user preferences. Since you will already be accessing that back-end (a database, perhaps?) to authenticate the user for login, retrieving that user's preferences is a simple step from there.
The real story here is that we need more details. Are you storing authentication information in a database, or something else? How are your user sessions stored (i.e., when a user logs in, how does your web app tell that his browser is logged in on subsequent requests)? Your question seems to state this, but to clarify, are these PHP pages containing some amount of Javascript?
Depends on your requirements. You will need to choose either to store user preferences in your database, provided your users authenticate, this is probably preferred solution. But if it meets your requirements you can save user preferences in a cookie.
Here is are javascript functions and jquery plugin with examples on how to work with cookies.
I am working to set up SSO for our intranet the idea is that a user would login to their workstation using their active directory username and password. Then a small application would run at login that would send some uniquely identifiable information,user name, and computers MAC address to the server were it would be entered into a database with a time stamp. Then when the user accesses the intranet a java applet would send the users mac address to the server and compare it to the database entry to see if it finds a match within a given time frame, if it does then it signs the user in and removes the entry from the database.
Unfortunately our intranet is not running on IIS so I can't use NTLM to do authentication which would be easier but not cross browser compatible which is one of the requirements. NTLM is also not an option because our intranet is only accessible in the form intranet.company.com and as far as I know NTLM does not work with addresses in that form.
Okay now onto the question. I am currently in the process of creating the client authentication application in C++ and need a way to get some unique identifier or token that would differentiate a legitimately logged in Active Directory user from some one who got a hold of the application and changed their local username to an AD user.
Yes I know this is probably the wrong way of doing it but right now it seems like the only option. If you have any suggestions beyond not doing it please let me know. Also I am aware of the huge gaping security hole it creates if you can think of a way to patch up that hole with out NTLM be sure to let me know.
AD is just Microsoft's implementation of Kerberos. One of the core features if Kerberos is to create such permission tickets. So, on that side your solution is not a hack at all. It's just the validation part that looks like a car crash.
However, I'm entirely lost at the client-side problem you have. The entire point of AD or Kerberos in general is that you can't spoof an authenticated user. You just ask the OS for a ticket for the logged-in user. It doesn't matter who gets hold of your app, or or what his local username would be. The OS knows precisely who is logged in.
I need to make a simple knowledge-base type application to use in company internal network. To make it simple and fast to use for end-users I would like to skip all the login in part (as it will be only visible to internal network users who we trust anyway) and automaticly pull the domain user name from the user and put it into the database (don't want people to waste time manually entering their name; the littler time they waste using the app, the higher chance they will actually use it).
So, is it possible to get that kind of information on a server? Do windows browsers send it in some headers that I could trust to be there?
If you are using IIS and Internet Explorer, you could turn on 'Integrated Windows Authentication' (NTLM authentication). This causes IE to automatically authenticate the user using your domain infrastructure. After automatic login, you can access the user name using the environment variable LOGON_USER. There is also a module for Apache (mod_ntlm) for this purpose, although I don't know its status.
Maybe you could event try to implement NTLM authentication yourself, but this will certainly be a lot of work.
Other than that, there seems to be no way since no reasonable browser will send the user name...
EDIT: It seems that python-win32 extensions or python-ntlm could do the trick, check out this thread. You still have to integrate it into Django, though.
You're building a web application. You need to store the state for a shopping cart like object during a user's session.
Some notes:
This is not exactly a shopping cart, but more like an itinerary that the user is building... but we'll use the word cart for now b/c ppl relate to it.
You do not care about "abandoned" carts
Once a cart is completed we will persist it to some server-side data store for later retrieval.
Where do you store that stateful object? And how?
server (session, db, etc?)
client (cookie key-vals, cookie JSON object, hidden form-field, etc?)
other...
Update: It was suggested that I list the platform we're targeting - tho I'm not sure its totally necessary... but lets say the front-end is built w/ASP.NET MVC.
It's been my experience with the Commerce Starter Kit and MVC Storefront (and other sites I've built) that no matter what you think now, information about user interactions with your "products" is paramount to the business guys. There's so many metrics to capture - it's nuts.
I'll save you all the stuff I've been through - what's by far been the most successful for me is just creating an Order object with "NotCheckedOut" status and then adding items to it and the user adds items. This lets users have more than one cart and allows you to mine the tar out of the Orders table. It also is quite easy to transact the order - just change the status.
Persisting "as they go" also allows the user to come back and finish the cart off if they can't, for some reason. Forgiveness is massive with eCommerce.
Cookies suck, session sucks, Profile is attached to the notion of a user and it hits the DB so you might as well use the DB.
You might think you don't want to do this - but you need to trust me and know that you WILL indeed need to feed the stats wonks some data later. I promise you.
I have considered what you are suggesting but have not had a client project yet to try it. The closest actually is a shopping list that you can find here...
http://www.scottcommonsense.com/toolbox.aspx
Click on Grocery Checklist to open the window. It does use ASPX, but only to manage the JS references placed on the page. The rest is done via AJAX using web services.
Previously I built an ASP.NET 2.0 site for a commerce site which used anon/auth cookies automatically. Each provides you with a GUID value which you can use to identify a user which is then associated with data in your database. I wanted the auth cookies so a user could move to different computers; work, home, etc. I avoided using the Profile fields to hold onto a complex ShoppingBasket object which was popular during the time in all the ASP.NET 2.0 books. I did not want to deal with "magic" serialization issues as the data structure changed over time. I prefer to manage db schema changes with update/alter scripts synced with software changes.
With the anon/auth cookies identifying the user on the client you can use the ASP.NET AJAX client-side to call the authentication web services using the JS proxies that are provided for you as a part of ASP.NET. You need to implement the Membership API to at least authenticate the user. The rest of the provider implementation can throw a NotImplementedException safely. You can then use your own custom ASMX web services via AJAX (see ScriptReference attribute) and update the pages with server-side data. You can completely do away with ASPX pages and just use static HTML/CSS/JS if you like.
The one big caveat is memory leaks in JS. Staying on the same page a long time increases your potential issue with memory leaks. It is a risk you can minimize by testing for long sessions and using tools like Firebug and others to look for memory leaks. Use the JS Lint tool as well as it will help identify major problems as you go.
I'd be inclined to store it as a session object. This is because you're not concerned with abandoned carts, and can therefore remove the overhead of storing it in the database as it's not necessary (not to mention that you'd also need some kind of cleanup routine to remove abandoned carts from the database).
However, if you'd like users to be able to persist their carts, then the database option is better. This way, a user who is logged in will have their cart saved across sessions (so when they come back to the site and login, their cart will be restored).
You could also use a combination of the two. Users who come to the site use the session-based cart by default. When they log in, all items are moved from the session-based cart to a database-based cart, and any subsequent cart activity is applied directly to the database.
In the DB tied to whatever you're using for sessions (db/memcache sessions, signed cookies) or to an authenticated user.
Store it in the database.
Do you envision folks needing to be able to start on one machine (e.g. their work PC) but continue/finsih from a different machine (e.g. home PC)? If so, the answer is obvious.
If you don't care about abandoned carts and have things in place for someone messing with the data on the client side... I think a cookie would be good -- especially if it's just a cookie of JSON data.
I'd use an (encrypted) cookie on the client which holds the ID of the users basket. Unless it's a really busy site then abandoned baskets won't fill up the database by too much, and you can run a regular admin task to clear the abandoned orders down if you care that much. Also doing it this way the user will keep their order if they close their browser and go away, a basket in the session would be cleared at this point..
Finally this means that you don't have to worry about writing code to deal with de/serialising the data from a client-side cookie, while later worrying about actually putting that data into the database when it gets converted into an order (too many points of failure for my liking)..
Without knowing the platform I can't give a direct answer. However, since you don't care about abandoned carts, then I would differ from my colleagues here and suggest storing it on the client. Why store it in the database if you don't care if it's abandoned?
Then again, it does depend on the size of the object you're storing -- cookies have their limits after all.
Edit: Ahh, asp.net MVC? Why not use the profile system? You can enable an anonymous profile if you don't want to bother making them log in
I'd say store the state somewhere on the server and correlate it to the user's session. While a cookie could ostensibly be an equal place to store things, if you consider security and data size, keeping as much data on the server as possible becomes a good thing.
For example, in a public terminal setting, would it be OK for someone to look at the contents of the cookie and see the list? If so, cookie's fine; if not, you'll just want an ID that links the user to the data. Doing that would also allow you to ensure the user is authenticated to the site in order to get to that data rather than storing everything on the machine - they'd need some form of credentials as well as the session identifier.
From a size perspective, sure, you're not going to be too concerned about a 4K cookie or something for a browser/broadband user, but if one of your targets is to allow a mobile phone or BlackBerry (not on 3G) to connect and have a snappy experience (and not get billed for the data), minimizing the amount of data getting passed to the client will be key.
The server storage also gives you some flexibility mentioned in some of the other answers - the user can save their cart on one machine and resume working with it on another; you can tie the cart to some form of credentials (rather than a transient session) and persist the cart long after the user has cleared their cookies; you get a little more in the way of fault tolerance - if the user's browser crashes, the site still has the data safe and sound.
If fault tolerance is important, you'll need some sort of persistent store like a database. If not, in application memory is probably fine, but you'll lose data if the app restarts. If you're in a farm environment, the store has to be centrally accessible, so you're again looking at a database.
Whether you choose to key by transient session or by credentials is going to depend on whether the users can save their data and come back later to get it. Transient session will eventually get cleaned up as "abandoned," and maybe that's OK. Tying to a user profile will let the user keep their data and explicitly abandon it. Either way, I'd make use of some sort of backing store like a database for fault tolerance and central accessibility. (Or maybe I'm overengineering the solution?)
If you care about supporting users without Javascript enabled, then the server side sessions will let you use URL rewriting.
If a relatively short time-out (around 2 hours, depending on your server config) is OK for the cart, then I'd say the server-side session. It's faster and more efficient than accessing the DB.
If you need a longer persistence (say some users like to leave and come back the next day), then store it in a cookie that is tamper-evident (use encryption or hashes).