Brian asked:
We are attempting to have a shopping cart that is shared over multiple domains(www.site1.com,www.site2.com,www.site3.com)I can think of a few ways to work around this, but let me propose one and see how badly the idea gets torn apart by my readers (and yes, that's an invitation, please share your ideas!). I spoke with Brian and confirmed that even though the sites are unique, they are all one machine. (Technically multiple machines in a cluster, but for all intents and purposes, one machine.) Given that they all share the same network, I think you can look at a solution that uses one database as the primary holder of the cart. So let's assume we have three sites:So far I haven't been able to share variables.
Not sure what there is to do and was looking to see if you have something that can at least give me a nudge in the right direction.
Thanks in advance.
- alpha.org
- beta.org
- gamma.org
(Note - I have no idea what those sites may actually be in real life. If you visit them and discover some new level of perversity heretofore unknown to you... sorry.)
Now let's assume we have one unique way of identifying you on all three sites. Most likely this would be an email address. Given that I'm foo@foo.com no matter where I'm at on the Internet, we could use my email address on all three sites as a way to uniquely identify me.
Given the assumptions so far, all three sites could query one database to fetch cart records for the email address. This would allow adding, editing, viewing, etc all to occur and "just" work across all three sites, again assuming that you are logged in. Even if not logged in, if you shop on alpha.org, pop over to beta and then log in, it should be able to restore your cart.
I think this will work fine. There are some caveats of course. I can go to beta.org and register as someone else's email address. If you don't do a followup email verification, then you will never know that foo@foo.com on alpha is not the same as in beta. It's also possible that folks may simply stop using an address. foo@apple.com may be let go. The new foo@apple.com may then go register on beta.org. I think though in that case you would want to use the same login system across all sites. That way you could also use the existing email address if you had the password. It would be annoying to the new guy, but at worse he can use an alternate email address.
Any thoughts on this technique?
Archived Comments
If all else fails you could always do something wacky like moving around an encrypted WDDX of the cart object.
By moving around, what do you mean? You can't use a cookie.
The user didn't say this but could you assume that each of the sites share a higher level domain cookie? For example:
1.com
2.com
3.com
Each site has an instance of a master.com domain cookie. It's how Google Analytics does it. Then they can reconcile sessions based on the domain cookie and session cookie for each site.
It's how we did it when I was at Dealerskins.
I was thinking the same as Andy M. Perhaps another way is to keep the cart content in a database rather than a session or cookie var. Then when you go to another site, you'd have to pass a key in the url (or form) so the new site picks up the cart for the user and continues to run with it.
In general, shopping cart functionality should work for users who are not logged in or registered. This is not made explicit in the request, but I suspect that's the real difficulty. The user must be identified only by a cookie (or url token), and since cookies set for www.site1.com can't be read by www.site2.com, it makes it hard to keep the shopping cart across domains, even if they share the same database server.
Jules' suggestion of passing a key in the url is good, but only works if the user will only be going from site to site via links. If someone manually enters "site2.com" in their browser, it won't work.
I have dealt with a similar problem in the past in a very inelegant but effective way. The process is:
- Someone goes to site2.com.
- If they don't already have a cookie set, they are redirected to a special page on site1.com.
- If they have a cookie set on site1.com, they are redirected back to site2.com with the cookie value in the url.
- The cookie is set on site2.com, and now the user is known to be the same user on site1.com and site2.com. If both sites have access to the same database, they can display the same shopping cart on both sites.
This gets more complicated with 3 or more sites, of course.
David...
That's why I put forth my suggestion of an overarching master domain cookie. The company would use THAT cookie to access shopping cart data.
@Andy, sorry, I guess I ignored your idea because I didn't understand it. How would you share a master domain cookie between site1.com and site2.com?
Dealerskins uses an ASP model. Multiple sites running on the same code base, same server, and same database. When a user visits a site, he gets a cookie from site1.com, and masterdomain.com. When he visits site2.com he gets a cookie from that site, they then check for the existence of a masterdomain cookie. If it's there, they update references in the database. If it's not, then they give him one.
This let DS track customer usage between car dealership websites and upsell customers on cars they looked at on one site, while they were on the lot of the other site.
I think I see what you're saying. But you still can't read cookies from site2.com and masterdomain.com in the same page request. So unless all shopping cart functionality is served from masterdomain.com (e.g. via ajax), you still need some way to transfer identity information between the two domains, such as the mechanism I described. Or do I continue to miss something?
I could be wrong but I am 99% sure that master domain is also how the stackexchange (stackoverflow.com) guys handle their logins.
You can login on one site and it uses http://stackauth.com/ to store stuff (cookie or local storage I can't quite remember which).
Ah of course I found the post I was looking for minutes after posting - http://blog.stackoverflow.c...
I'd look at CF 9 and CFCache with a distributed cache setup too.
If the user is signed in you are all set with follwoing the user.
If not logged in, you could write an iframe to go fishing for cart id cookies. Basically loop thru your pool of sites in the iframe and then use javascript to tell your current site about open carts.
That third site authentication that Andy discusses is pretty common in environments I've seen -- it's still very hard to maintain session across cluster nodes unless they're sharing the same memory spaces and database backends in a robust way. A centralized token issuer allows everyone to stay in sync, and the token issuer can better deal with hard session expirations.
I've seen this in SharePoint environment where, because of the difficulty managing logins using smartcard environments, a user will authenticate into a server for authentication sake, and then it is tokened out and that token is distributed across multiple destination servers.
Seems to me that the best way to do it would be to create a fourth site, www.abc-shopping.com.
Site four would handle the cart and ordering process for all three sites.
Site 4 would set its own cookies, handle its own login process, and so on. If one of the other sites needed cart info, a small iframe linking to site 4 should do the trick.
Any "add to cart" links would link to site 4. If the user is logged in, you could also pass an encrypted user id string at that time.
Site 4 would be also be cheaper to maintain since you only need a cert for a single site, and the cart and order processing code would be on a single server and not cloned across the other 3 site.