Bk wrote:
Hi
I've to set up a shared shopping cart to buy items from four different sites and pay them at once passing trough a single checkout.
Provided that these sites are hosted on the same server (actually in the same directory), but have different names, is it possible to share php sessions across multiple domains? How?
Bk,
I notice your question has basically been answered i.e. you have to pass something e.g. session_id, between the sites via a GET/POST. So just a couple of related points:
1. I seem to remember that you can set sessions to use IP addresses or URL'ed session_ids as well as cookie'd session ids. Either of these techniques would solve your problem as well, (although cookies strike me as a better route if you must use sessions ;)).
2. If you are doing this kind of "multi-site" stuff and have Apache, it's worth checking out the php virtual() and header() commands.
With these you can leave your "shops" to just handle their own stuff and use a "master" domain to do all the basket/order processing.
The basic technique is to direct your order forms/buttons to a script on the master domain which does the procesing, (and can set cookies if it wants). Once it's finished, instead of generating its own page it uses a Location header to redirect the user back to an appropriate page on the "shop" domain. The user never knows you've done this.
Similarily, the checkout button can go to the master domain to do the actual procesing, where it automatically picks up any cookies (e.g. session_ids), that you set from a master domain page.
The virtual command might come into the picture if you want to show the user the status of their shopping basket while in one of the shops.
Virtual allows you to run a http request behind the scenes and include the output in your page. So your page can mix output from different php scripts running on different domains. They don't even have to be scripts in domains on the same server if you set up an Apache proxy to point to the remote script.
You can use this to include a "basket status" section on your shop pages without having to run the code to create it in your script. You can have one set of "basket status" code across as many shops/domains as you like i.e. code once, use often.
Unfortunately, what you can't do with a virtual() is to get the "foreign" script to pick up any cookies set for its domain. (That's because the user's browser never sees the http request, so it doesn't know that it should send the cookies for the domain). That means you would still have to swap the session_id, (or basket key), around between sites.
You can see these techniques in action at any "Ishop" e.g. www.levitron.co.uk. All the main procesing is done by www.ishop.co.uk, but the shop has entirely its own identity. Order buttons, searches and checkouts go to the master "ishop" domain and product pages include a checkout status line generated on the master domain.
You'll notice that there is no use of php sessions. Basket information is stored in the database and then the database key is cookied, posted and urled. Partly that's because there's still a mix of php, C and perl coded pages. Sessions are not really appropriate for heterogeneous environments. C or Perl or any other language can easily pick up a cookied database key and query a database but how do they get hold of data in a php session?
Even if it was all php, I still wouldn't use sessions. My view is that if data is to be stored on a server it should be stored properly in a structured format in a database, not in a unstructured and pretty much inaccessible session object. For example, it's hard to prove to a third party what data you have stored about users, if some of it might be in stored sessions.
Ummm, I wonder if I should explicitly raise my concerns about sessions in a separate thread? I don't use sessions so it doesn't bother me, but I wonder if some people are just storing up trouble for themselves by basing their code on the use of sessions...
Anyway, hope this helps,
George
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
