multi-site cart

[eluser]theprodigy[/eluser]
Hey all,

I have a client who has suggested a multi-site cart. By this, I mean the user can put items into the cart from site a, site b, site c, etc and only have to check out one time to purchase all items entered.

I would like to build this in such a way that adding another site to the mix would be as relatively painless as possible. The client wants to start with a set number of sites, but I'm not sure if that number will grow in the future.

These different sites are full domains, not sub-domains, so any session data will be lost (but still reachable via db, I believe). I have an idea, but am looking for second opinions / other ideas.

My idea:

Code:

1. Setup the shopping cart / catagory code as a web service. All heavy lifting will be done through this.
2. All sites are setup with their site specific designs, config files to set site_id, and data will be pulled via connection to shopping cart web service
3. Either setup links to the other sites as form submissions passing in hidden variables containing necessary session data, or set cookies to store this data.
4. When on next site, check to see if posted value or cookie exists, if not create new session, if so, connect to that session to continue user shopping.

I don't like the idea of hacking a session to continue shopping, but not exactly sure how to do this otherwise. Any and all comments will be greatly appreciated.

[eluser]summery[/eluser]
Hola!

I assume talking your client into a single site isn't an option. But consider the benefits: not only will this multi-site-shopping-cart problem go away, but you can focus on developing one beautiful, functional site instead of having a bunch of just-good-enough ones. Quality over quantity, baby.

You can not access cookies from a different domain than the one that set them -- the browser won't send those cookies to you. But your idea of sharing data between sites by submitting POST data might work with a bit of script.

Code:

<form name="myForm" method="post" action="other site's page">
<input type="hidden" name="user" value="encrypted user id #">
<input type="hidden" name="cart" value="encrypted cart id #">
</form>

Then, submit your form with an onclick event in your link tag to the other site.

Think about security. You want to make sure people can't access someone else's cart just by constructing a form submission with false credentials. Using https:// and encrypting both user and cart information, and checking that they match using your web service, should do the trick.

Good luck!
~S

[eluser]theprodigy[/eluser]
Well, one of my friends just mentioned that I should be able to use the user-agent header information since that will be unique to each browser, and more often then not, if a user goes to site_a via their favorite browser (firefox, ie, opera, safari, etc, etc), they will also go to site_b in the same browser. That way, I don't have to worry about cookies, posted data, or anything like that. I guess I will have to use database session management, and when they start a new session, put the user-agent into session. If they go to another site, I'll check to see if a session entry in the db table exists with that user-agent, and if so, use that session rather then creating a new one.

Any thoughts? Any comments? Any wise-cracks?

Thanks

[eluser]summery[/eluser]
A user agent says which browser you're using, but it's not a unique string: people who use the same browser as you (admittedly, also the same exact build) will have the same user agent as you. Check out this site: http://whatsmyuseragent.com/ and this one: http://www.useragentstring.com/

You could examine the IP address; but there might be more than one user per IP address.

You can't use cookies to transfer data between sites, per my earlier post.

So I think the way to transfer information between multiple sites is using POST data like you initially suggested.

Good luck!

[eluser]theprodigy[/eluser]
I really don't like having to depend on the user to get to each site via a specific route. With the way my luck has been, if I do that, that will be the road least traveled. lol

What if I set it up as:

Code:

1. Shopping cart is it's own site, full domain access, just no design put in place
2. Each site is a design "front", pulls all necessary data from the shopping cart
3. Shopping cart site is the one that handles the cookies

I'm not exactly the biggest fan of cookies, but I believe that this way, the shopping cart domain is the only one setting and accessing cookies, so no cross-domain restrictions. Plus I don't have to worry about which way the user gets from site_a to site_b (they can follow links, open a new tab and type in a url, use their bookmarks, use jedi mind tricks, etc).

Ideas, comments, wise cracks?

[eluser]theprodigy[/eluser]
If I set it up in the above manner, is cURL-ing my only option for setting and retrieving data?

If the shopping cart is setup as the bulk of the processing, and I want to send and retrieve data from it, is there a way other than curl-ing to do this?

Is there a better way to set this up?

All info is appreciated.

[eluser]theprodigy[/eluser]
any ideas at all?

[eluser]Ben Edmunds[/eluser]
If I was you I would set it up as separate "fronts" to the same backend and have a single sign-on across all of the sites. And then store each step of the cart in the DB.

[eluser]theprodigy[/eluser]
I have no problem doing that when the user is signed in, but users have gotten quite used to being able to fill a cart, and not have to sign in until the checkout process. That seems to have become the standard nowadays. Normally, this wouldn't be an issue, but when dealing with multiple sites, I can't use session to hold anything, but I'm still wanting to try to keep the whole "sign in only required on checkout". Now, I'm not against making users sign in once they add their first item to the cart, but I'll have to ask the client on Monday.