1

I've recently been developing a userscript to display a sidebar on all the websites we develop, to tell us things like whether the site is meant to be AA, browser support etc etc. This is for internal use only. I am limited to using Classic ASP and jQuery / JavaScript.

My problems are as follows:

  • There is a law coming in soon which means it is best that clients do not know about any cookies being used by the script.
  • The database team would not be happy with us creating a new database (or extending the main one) just for this script.
  • It has recently come to my attention that the maximum number of cookies per domain is around 50 for most browsers; bearing in mind that I was thinking of storing data on a per-site, per-server or for all servers, I am almost certain this would eventually take it over 50 cookies for this script alone.
  • I have heard that there are 'mini database' facilities in HTML 5 - however most of our websites are on HTML 4 so this is not an option.
  • If we were to go down the database route, we would not be able to use one single database - it would have to be one database per server. I reckon that syncing would be very difficult, even using one page to sync all servers using many iFrames (I believe, although not 100% sure, that if a user navigates away from a page prematurely, any iFrames terminate their request so data may not be updated - but feel free to correct me if I'm wrong).
  • Data needs to be stored permanently.

We have a set up as follows (very simplified representation):

  • a.b.com (server 1, own domain)
  • b.b.com (server 2, own domain)
  • c.b.com (server 3, own domain)
  • d.b.com (server 4, own domain)
  • jobs.a.com (URL mask)
  • careers.b.com (URL mask)
  • e.m.com (server 1, own domain)
  • f.m.com (server 2, own domain)
  • g.m.com (server 3, own domain)
  • h.m.com (server 4, own domain)

Based on the above, does anyone have any suggestions for the best way to be able to sync data and store as much as we need on a per-user basis? Note that this, ideally, needs to work with GreaseMonkey on Firefox, Chrome, Opera and Trixie on IE (6-9). IE 6-7 are not absolute musts, but are preferable.

ClarkeyBoy
  • 4,934
  • 12
  • 49
  • 64
  • Know that you can use HTML4 for your content and still take advantage of HTML5 features such as `localStorage` - it's up to the browser to utilize that, not the HTML standards revision the site is built upon. That being said, `localStorage` likely wouldn't apply here, as it's stored per domain, but it's worth pointing out. – Morgon Mar 07 '12 at 23:29
  • Most frontends are the same domain, just different subdomain. If localstorage is regardless of subdomain, that might be an option. We have two domains ourselves so it would be 1 iFrame to call + 1 per URL mask to update across all sites. Now it is just a matter of storage limits (researching that now). – ClarkeyBoy Mar 07 '12 at 23:33
  • This may help: http://stackoverflow.com/questions/2747285/html5-localstorage-restrictions-and-limits – Morgon Mar 07 '12 at 23:41
  • Thanks Morgon. Even at 2.5MB it is still over 2,500,000 characters (per user). May be able to do something with that. I think I just came up with a potential solution based around using databases - creating an additional subdomain for each domain (including URL masks with the clients permission) which points to one server only - dev.a.com, dev.b.com and dev.m.com based on the above example. Setting the document.domain to the same thing for the requesting page and the page which serves up data from the database would get around the same-origin policy. :) – ClarkeyBoy Mar 08 '12 at 00:02

1 Answers1

2

If it needs to be permanent and you do not want the clients to be able to see that you store info then client side storage is out of the question. It has to be stored server side..

Ao what you need is:

  1. A way of uniquely identifying users cross domain.
  2. A server side storage of some sort

The first one you could do using a third party cookie (like google and facebook do to track you on multiple domains). On each site include a link (0x0px iframe, small imgage or something else) that calls a service on a tracking server. The first time the user visits a site, set a long lived cookie. The cookie will be send to the tracking server every time thus uniquely identifying your user. Third party cookies must be enabled on the browser for this to work though.

The second one will have to be a database or file of some sort. I'd say if you cannot use a datebase create a service on one of the machines (the tracking server) and let that one write some info to a disk. This is a poor mans solution as files are hard to query.

Koen Peters
  • 12,798
  • 6
  • 36
  • 59
  • The method of using cookies (which the client can see) is exactly what we need to avoid - there is a law coming out soon to make it illegal to collect user-specific data in the EU without explicit consent from the user. We get around that by saying that the user accepts cookies if they install the script, if they don't want cookies then they can't use it. However some clients have been enquiring about whether out product uses cookies recently and I don't want to make matters worse, so hiding them is best. I am starting to think localstorage may be a good solution but still investigating. – ClarkeyBoy Mar 07 '12 at 23:45
  • if you want to stop using cookies completely (also from first party domains) make sure that you also do not store session cookies (which are automatically created by most webservers). Or is this only for third party cookies? – Koen Peters Mar 07 '12 at 23:48
  • I am not 100% sure... One of the sources I have used is http://www.cookielaw.org/optanon.aspx but there are many forums discussing the law (and how stupid it is). Many say that Google Analytics can't be used as it doesn't comply, but no-one knows for sure. I'm gonna be in discussions with my manager and a couple of other teams to decide how to proceed (with regards to warning clients and going thru their frontends etc) over the next couple of days. Really it's down to our legal team to tell us what this means, but I can't really continue developing the script without some method of storage. – ClarkeyBoy Mar 07 '12 at 23:54
  • Hmmm, I don;t believe they will bann first party cookies, only third party ones. If that is the case then you can just use cookies, but you will not be able to track over multiple domains. You will have to uniquely identify people some other way. MOst of the other ways will be kinda hacky and black hat. I'd try to avoid those as when you get caught it will not be good fpr the reputation of the sites. After all: cross domein tracking is what the law is the main issue trying to prevent. – Koen Peters Mar 07 '12 at 23:59
  • The thing is you have to get the explicit permission from the user - we will take them clicking 'install' as such permission. It will therefore definitely be above board / legal; the reason I want to hide the cookies (or not use them at all) is to avoid clients panicking and increasing our already heavy workload. – ClarkeyBoy Mar 08 '12 at 00:05
  • After reading that over the top law I must say I feel sorry for you and all other UK webdevelopers. This will break the internet as we know it. Let me know how you solved it in the end. Cheers! – Koen Peters Mar 08 '12 at 00:21
  • ok will do. Thanks for your help. I will see if I can get together with some of the best minds in the business to come up with a solution (we're a web software development company based all around the globe so I'm sure we will be able to find a solution somewhere). PS It is not just a UK law - it is EU-wide! Basically all of Europe has to abide by it, and I believe it applies to companies based outside the EU who target users within the EU - although again I am not 100% sure about that. – ClarkeyBoy Mar 08 '12 at 00:26
  • Good news on this - had a meeting with my boss and his boss today, regarding adding tables to the database on *each* server. I have been asked to create a working example, meaning creating tables on the dev server as much as I need to. This is only for half the script - we have decided that using cookies is likely ok as, firstly, it is internal only and secondly we can have a standard response to give to consultants / support with regards to enquiries about cookies. In otherwords I have the go-ahead for the entire script :) – ClarkeyBoy Mar 09 '12 at 22:46
  • I know there are limits on the *number* of cookies per domain, but I am sure we can get around that by combining cookies of the same name (but for different servers) into one cookie. I can also monitor the number of cookies and email myself the full cookie string if a user nears 50, then see if I can optimise it in any way by combining cookies or simply deleting and not using any. – ClarkeyBoy Mar 09 '12 at 22:47