问题
They say Cookies are bad. I personally believe there should be a "smarter" way to detect the state of a user on a web app.
Say, currently this is how it works in a distributed environment where xyz.com has many pools and servers (which i know of):
- User logs in xyz.com
- The login module of xyz.com drops a cookie on client's local machine.
- Now, when the client goes to Feature1 of xyz.com, the feature1 pool checks for a local cookie, if he finds it and if it has not expired then Feature1 assumes that the client is good and lets him in.
So, feature1 blindly trusts the client due to the cookie dropped by login module.
But I feel a fundamental flaw here at stage 3. What if a hacker clones a cookie and tries to do something? (which is the first obvious thing a hacker will try to do, cookie sniffing)
So, is there any alternative to this? - how will web storage, flash stored objects do in future? or cookies will rule?
Not looking for an obvious answer, because there are none. I am interested in different viewpoints of approaching this probem.
Thanks
回答1:
One of the Fundamental principals of REST, and I mean real REST is not to store state on the server, if there is no state on the server, then there is no need for a cookie to be used as a key to look that state up.
回答2:
I believe the information in this resource from google and/or this link will help you to find alternatives for saving information on the client-side.
Basically... there are 4 different ways to store data on client-side without using cookies:
- Web SQL (my favorite, and it's NOT obsolete)
- IndexedDB (another Database with different structure and acceptance)
- Web Storage (Session and Local key/value pairs)
- Application Cache (Files for WebApps)
I believe that for your specific need the Web Storage Local pairs are the right solution.
来源：https://stackoverflow.com/questions/3287311/alternative-to-http-cookies