Cookies are great because a value written in website.com can be used in www.website.com (www is considered a sudomain of no-www). The downside is all the cookie values are sent along with every HTTP request to the server. So I'm looking for a local storage mechanism available natively to Javascript that works cross-subdomain and isn't transmitted to the server. Does such a mechanism exist? LocalStorage doesn't work cross-subdomain and Flash Cookies wouldn't work on iPhone.
Perhaps just redirect website.com to www.website.com or vice versa?
This seems like it would be the simplest fix.
http://www.scriptalicious.com/blog/2009/04/redirecting-www-to-non-www-using-htaccess/
If your users have an actual account that they login to on your server, then you could store the info server-side and just include a little javascript in the each page that will need that data with the appropriate data. When you render the page server-side, you can define a user object in javascript with appropriate attributes set to the data values that can then be referenced client-side. That way, you only include the data that is needed in a given page, the same user data is available no matter what computer the user logs in from (no reliance on persistent cookies). If larger pieces of data are needed only occasionally and you don't want to include them in the page in case they are needed, then make those pieces of data queryable via ajax/json so they can be retrieved only when needed.
If you're still intent on only storing it locally, then cookies or HTML5 local storage are your only options and cookies will be your only cross browser option that covers all browsers in use. At the addition of implementation complexity, you could combine a number of the suggestions:
Always redirect to www.domain.com so all user activity is on the same domain.
Use HTML5 local storage when available (the redirect in step 1 prevents sub-domain lockout).
Fall back to cookie storage when HTML5 local storage is not available.
One could presumably write or find an abstraction for HTML5 local storage and cookies so 99% of your code could be independent of which storage mechanism was actually being used. It looks like there are some jQuery plugins that do exactly that.
Related
So I have 2 domains: http://domain1.com and http://domain2.com
domain1.com has a bunch of cookies for the user stored on it.
I want to access all of those cookies but from domain2.com (to keep them synchronized).
Is this possible in JQuery? I was thinking of making a Cookie php file and somehow connect to that file from domain2.php to pull all of the data in.
Thanks for any help
NOTE: These are NOT sub-domains but 2 completely different domains I Control
In a strict sense? No. It isn't. In a more loose sense, yes it is.
If you're storing all of your data in cookies, you're actually storing the data in the browser, which means that jQuery, Prototype, Mootools... can't help you because of browser security (unless you can turn their browser into a server (might work with a Firefox extension (I swear, FF could be an OS if needs be...), but that would be gratuitous)).
I said that in a loose sense it is possible because PHP lets you do two very important things. First, it lets you store your session in a database, and second it lets you assign the session ID directly. It is possible, then, to have two servers point to the same DB and then share SESSION data by switching the user's session ID.
no. this would violate the security model on which browser cookies operate.
to work around this you can implement an iframe (perhaps invisible to the user) on domain1.com which is served from domain2.com and pass data between the two sites with JS.
I would look at a server-side solution, creating a common database that all sites can access. When the user logs in, generate a time-sensitive, IP-keyed token that can be passed from site to site either in GET or POST. Then, validate each request on token, IP, and time. The combination of the three will resolve most security concerns.
or you can look at this SO question for ideas its in .Net though Store cookie for other site
I've made a web app that stores persistent user data in localStorage. I've enabled HTTPS on my site, and I'd really like to flip the switch on HSTS. However, as far as I can tell, localStorage considers http://example.com and https://example.com to be different, so if existing users are redirected to the HTTPS version of my site, they can no longer access their data (though it still exists).
Long term, I want to build a new version of this app that offers more options for data storage. But in the short term, all I can think of is having a transition period where users at the http version are asked to migrate their data via some other (unknown) mechanism that both versions can access.
Is this a fair assessment of my options? Is there a way for https://example.com to access the localStorage of http://example.com? If not, is there anywhere I can put user data such that both versions can access it but other sites can't? Or should I ask them to download their data and re-upload it? That doesn't see ideal from a UX or (user) security standpoint.
Note that this web app doesn't interact with a server at all; everything happens with localStorage and the client.
Unfortunately there does not seem to be any way to directly retrieve localStorage contents for the less secure http copy of the site from the https site. reference
The workaround I have seen is to use an iframe loading a special page on the insecure site similar to this answer. The general theory is to have code in the iframe that sends messages using postMessage with localStorage data back to the secure page.
Unfortunately this approach does not allow you to disable http entirely, because otherwise your iframed http copy would not load.
I'm depending heavily on localStorage for a plugin I'm writing. All the user settings are stored in it. Some settings require the user the write regex'es and they would be sad if their regex rules are gone at some point.
So now I am wondering just how persistent the localStorage is.
From the specs:
User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user.
The above looks like it works just like cookies on the clientside. I.e. when the user clears all browser data (history, cookies, cache etc) the localStorage will also be truncated. Is this assumption correct?
Mozilla implements it like cookies:
DOM Storage can be cleared via "Tools -> Clear Recent History -> Cookies" when Time range is "Everything" (via nsICookieManager::removeAll)
https://developer.mozilla.org/en/DOM/Storage
In DOM Storage it is not possible to specify an expiration period for any of your data. All expiration rules are left up to the user. In the case of Mozilla, most of those rules are inherited from the Cookie-related expiration rules. Because of this you can probably expect most of your DOM Storage data to last at least for a meaningful amount of time.
http://ejohn.org/blog/dom-storage/
Chrome implements it like cache:
LocalStorage is Not Secure Storage
HTML5 local storage saves data unencrypted in string form in the regular browser cache.
Persistence
On disk until deleted by user (delete cache) or by the app
https://developers.google.com/web-toolkit/doc/latest/DevGuideHtml5Storage
As for a "replacement for the Cookie", not entirely
Cookies and local storage really serve difference purposes. Cookies are primarily for reading server-side, LocalStorage can only be read client-side. So the question is, in your app, who needs this data — the client or the server?
Basically, you should not heavily depend on Local Storage.
Local Storage, along with Session Storage, aims to be a replacement of the cookies, defining a more consistent API. There are a few differences from the cookies:
While the cookies are accessible from both client and server side, Web Storage, in general, and Local Storage, in particular, are accessible only from client side.
Enhanced capacity (official for cookies is 4 KB) to more than 5MB per domain (Firefox, Google Chrome, and Opera and 10MB in IE).
So yes, your assumption is correct.
One thing to note about using local storage. It is very browser specific. If you store data with firefox it won't be available in chrome or ie etc. Also as far as clearing cookies and sessions, I've noticed it is also browser specific as to whether or not the local storage is cleared. I'd look into the details a lot if you're really planning on relying on local storage for an app.
Local Storage is designed to be a dependable, persistent store of data on a client. It is not designed as a "better cookie": that function is designed to be met by Session Storage.
From the Dec 2011 Web Storage Spec Candidate Recommendation,
(Local Storage) is designed for storage that spans multiple windows,
and lasts beyond the current session. In particular, Web applications
may wish to store megabytes of user data, such as entire
user-authored documents or a user's mailbox, on the client side for
performance reasons.
As client-side data - it is as persistent as any client side data, within the size limits that the browser implements. Users can delete it at any time, open it up in a text editor and edit etc. - just like ANY client side data.
If you're using localStorage for a iOS app, be very careful. THe latest version of iOS (5.1 off the top of my head) has moved localstorage and localdb data to a part of the cache that is regularly cleared, i.e. not at all persistent. I can't tell yet if this is a bug or a policy change.
I'm storing some preference data in cookies. However, I just noticed that this data gets sent to the server with every request. Is there a way to prevent that from happening?
A friend tipped off web storage, but this still leaves IE6/7 without a solution.
You can set cookies to be HTTP Only (so supporting browsers won't let JS access them), but not the other way around.
Web storage is the ideal solution, but you'll need to fallback to cookies for legacy browsers.
You can reduce the number of requests that include the cookies by moving some content (images, css and stylesheets in particular) to a different hostname, and limit the cookies to your primary host name.
The appropriate solution is to not store a huge amount of data in a cookie in the first place. Store it on your server, and only store a reference to the information (like a row identifier from a database) in the cookie.
Nope, no way to change it. Cookie data gets sent back with every single request to the same server, including requests for static stuff like images, stylesheets and javascript.
If you want to speed up the site and minimize server bandwidth, use a different domain name - or better yet, a CDN like Rackspace Cloudfiles - for your static stuff. The cookies won't get sent to the different domain.
Good luck!
I want to send some data to a user after they log in to a web site, some kind of secret string for encryption.
I want to allow them to navigate around the web site, and I want to be able to use javascript on their machine to encrypt data before it's sent back to the server. Note: This will be in addition to using SSL.
I don't want to use cookies for this because they are sent to the server on each request.
So my aim is to have some data that will be sent across the wire only once for the whole session, but that when the user visits multiple pages, javascript will be able to access this secret. To be clear I never want to see the user's decrypted data, nor be able to.
Is this possible, maybe using HTML5 persistence or something? I need a cross-browser compatible solution please that will ideally work with IE6 (so that might shoot down any HTML5 magic).
Thanks
If you are worried about snooping, use HTTPS. It sounds like a pretty fragile encryption mechanism though, why not go more 'traditional'?
I'd doubt you can do this. A session is normally tied to a cookie (ie jsessionid), so to tie it to the "session" (ie you said "some data that will be sent across the wire only once for the whole session"), and have it available to the user, you need to put it in a cookie.
You can use localStorage on HTML5-supporting browsers (IE8, FF3+, Chrome, Safari 4+, Opera 9+). You can fall back to userData for IE6 and IE7. That gives you a guaranteed minimum of 64 KB of data on all platforms (minimum userData size).
There's a library that encapsulates the various strategies for storing data locally: PersistJS
I use this to store client-side state that doesn't need to be sent to the server with every request (e.g. resizable panel dimensions). I don't think it could offer any additional security though, because any attacker that can decrypt the SSL stream can get at your data, because they can observe all your javascript code.
You could use a RIA plug-in like Flash or Silverlight. Both have mechanisms for storing data locally w/o sending it back to the server on each request. Java might as well.
How about keeping the user on the secure page and sending the encrypted data back with ajax calls?
I also remember seeing a php script that would load a given page into an iframe based on some criteria. I think the example I saw was just a demo, where you selected a page from a select form. The page containing the iframe can be used to persist data.
I think i'll take inspiration from the banking world and perform all of the encryption on the server. I can think of a way that I could generate a private key from the user's password making it impossible for me to decrypt data without the user being logged in.
I don't think there's a robust solution to my initial question, but thanks for the responses.