I've researched 2 methods that could reproduce the functionality coolblue.nl has.
They have 83 webshops, and all shopping baskets are merged. So if you add a product
to your basket on laptopshop.nl and go to one of their other shops (ie. smartphoneshop.nl) the product is already in your basket.
But how does it exactly work?
Single Sign on? I guess not, users are not required to log in
Identifying pixel? But how is the product directly available?
Unique links? They are not using it.
Can anyone give me some detailed info how i could get this to work?
Single Sign on? I guess not, users are not required to log in
Simply share the sessions between your servers. Store everything in a central memcached server. Only limitation is the cookie placed for one domain, not directly accessable by the other domain. Maybe it's JavaScript / JSONP used to circumvent this.
I personally use memcached too because it's faster, has less disc i/o, can be clustered, integrated into PHP and is dispatched from your webserver.
Identifying pixel?
Session IDs are stored per domain, so one domain usually cannot read other domains data (security). You can circumvent this using JSON(P). So you send a JSON(P) request to your central (web)session server and ask it "is there already a session for the user, if yes, return me the id".
You'd simply reuse the session then.
But how is the product directly available?
You can be sure all their Shops share the same database server and a unique product id like SKU/EAN.
Related
I have a (hopefully) quick question regarding sessions. Whilst I have used sessions extensively, I have not used them in a situation whereby the values change depending on a users actions.
After logging in to my application, a user can select a company area, which has many levels of pages and folders. All of these pages will need this 'company_id'. At the moment I send the company_id via GET, but as I get deeper into the application this is becoming increasingly hard to maintain, with various other data being stored in the URL.
Therefore, when a user selects their company, I could set their company_id in $_SESSION array. However, when a user changes company, I would then need to change $_SESSION['company_id'] to the new value.
Is this a good use of sessions? I could potentially clean up my urls by using session data rather than always using GET, but I am unsure if this is a recommended way of using sessions.
Thanks in advance
This is a bad implementation of the HTTP design philosophy. All HTTP requests should be self contained, RESTful. All information needed to get a specific page should be present in the request itself (URL, headers and body), not dependent on hidden state.
Super trivial example: you can't copy a URL to someplace or someone else and have them see the same page. The content of the page is dependent on session state, which has been laboriously set through the visit history of several previous pages. To return to this same page, you need to retrace the same steps, recreating some hidden server-side state to arrive at the same page.
This gets even more complex and messier if you take into account that a visitor may want to open pages requiring different states in two or more simultaneous tabs/windows.
All this isn't to say that it can't work, only that it's hideously complex and will break the usual expected behaviour of browsers, unless you really bend over backwards to somehow prevent that.
If the many levels of pages and levels are per-company, you can put the company_id in a specific include file - this part of the site being dedicated to a given company.
However if they're shared by multiple companies, and this is probably what you want, this is potentially misleading, or even dangerous depending on the user actions, since the user may jump to a given page (link...) and access a page with unexpected data linked to a company which ID is provided by the session or cookie.
You could dynamically build the links on a page, based on IDs, to ensure consistency during the navigation from that page. Any direct "jump" to another part of the site will not carry the ID with it (and the page may offer to select a company).
Depending on your web server and if you have control over it you could build the URL having "company ID" as an element of the URL path, not the GET parameters
Eg
http://example.com/invoicing/company382/listprices.php
using a rewrite (web server configuration) to change the URL to be actually used to
http://example.com/invoicing/listprices.php?compid=company382
(URL not visible to the user) that informs of the company ID via the GET parameters.
Is it at all possible to retrieve user information that can be used as a unique identifier between domains?
As a quick example of what I am trying to do (not exactly this but the theory is the same) say you had a main website at UK-news.com. You also had three other sites - England-news.com, Scotland-news.com and Wales-news.com, all hosted on the same server.
All 4 sites will share the same database and each would just pull the relevant info out of it. If a user becomes a member of one of the sites, they will also be given the option to become a member of any or all of the others. If a user signs-in to one of the sites he is a member of, and then goes to another how can I get that site to recognise him from the one he signed-in on so he is automatically logged in?
My theory was to store some user information (IP, USER_AGENT, browser, screen resolution, computer name, OS) in the database via PhP and then check against all of those as the user moves between sites. however, even checking against all of these, I am sure it will be possible for two different people to have exactly the same details.
Are there any truly unique identifiers that will guarantee that a person is recognised between domains?
Thanks
Steve
I dont know what is the configuration of your server, but. If one site is under something.domain.com, and another something2.domain.com, and the domains England-news.com and Scotland-news.com are only links to those sites, you can use url overwrite, and cookies sharing over subdomains option in php. But I think that this is not the case. So...
There is no 100% sure user recognition. And this is great, imagine what will happen if there would be. You can NEVER trust user data, and headers data, while sometime you can not even trust $_SERVER array. So there is no option to recognize the same user over few domains.
1) The only answer that is useful is to suggest you to share the user mysql table, and make all the logins and passwords same for each site. IN that case someone can login into another site using the same data.
2) You can try to rely on second hand services like google acount or facebook acount to verify users on your site. But you must remember that there are people without gmail and facebook, and availability of such a site will be reduced.
3) Use a serrvice like forever cookie, or something like that, but this is also not 100% sure. It is using html5 storage, flash objects, and everything to verify if this is the same user. But as far as I know, everything can be ommited, if you are patient enough.
Best regards!
I had problem with session sharing. Can session be shared across domain? I'm using PHP codeigniter framework for my project.
I had this case where I got 2 domain name register in server and I use 1 application.
Eg:
domainA = www.domainA.com
domainB = www.domainB.com
for domainA, i used default application
—-application
—-images
—-system
for domainB, i create new folder named domainB
—-application
—-domainB
—-application
—-images
—-system
By using htaccess, i rewrite rule whenever link is www.domainB.com it will pointing to domainB folder. This case, it working fine.
The problem is, the session created in domainA are not same as domainB. This is troublesome if we had to gather data from both domainA and domainB. Eg, let said, I add product A to add to cart in domainA, and another product B in domainB, i want to collect these both product and call it in shopping cart in domainA. Can i do that?
Need advise on how to implement these kind of problems? Usually when coding shopping cart we have to use session to keep the products in shopping cart at certain amount of times. Are there any other methods beside this? I had searched in google mostly i read the replied was something like this:
Assume you have a sites called www.innovativephp.com and www.innovativejs.com hosted on same server. Even though both sites are on same server, domain names are different hence you will see that the cookies will not be working in another top domain. :(
Thanks.
I had the same problem and still reading about it:
Extending session in another application
you might want to look on Single Sign on, openid,or even the answer given in the link provided.
I am using Magento 1.3.2 in a multi-store setup. www.example.com is the main store, and abc.example.com, foo.example.com and bar.example.com are affiliate stores with separate subdomains, separate inventory, separate carts, separate designs.
My problem is that some orders being placed through the affiliates are showing up as coming from the main store. It doesn't happen frequently, maybe once in every 1000 orders. I notice these when I go to fulfill the order and I see that the SKU is not one of mine but rather it is one of the affiliate's, despite the fact that the website, store and store view on the order screen all show the main store. I know that the customers are adding the product to their cart from the affiliate site (we don't even list affiliate products on the main site) and they go through the checkout process on the affiliate site. Does anybody have any ideas what could be causing this?
EDIT: I wish I could recreate this so I could post some code that I think might be buggy or something else helpful, but I've tried every permutation I can think of (logging in on the affiliate site vs the main site, having two carts open, adding/removing products in various sequences) but I still can't reproduce the issue.
You should follow some steps :
Make sure affiliates use different databases. Provide them with different database username/password sets. This ensures they are not messing with your database.
Make sure you have CSRF tokens, Or some URL Redirection/DNS config would make orders of affiliates to end up on the main shop.
If you feel like it, Browse web server logs to see what happened (might be time-consuming)
Provide people you ask for help with your system configuration, e.g Web Server, Server-side Scripting Language, Database Server, Operating System, etc.
If it is 1 in a 1000 problem, Then there are two general case of triggers for that:
Some particular costumers with particular system setup / clicking habits result in that.
You have concurrency problems in your code (Database Transactions?)
Hope it helped
two years ago I had to design a system to share authentication data across multiple domains, all of them shared the same server/db. I was able to pull this off with a complex system of cookie sharing which, to date still works.
I'm now in the process of redesigning the system and I was wondering if there are better ways to achieve this without having to write cross domain cookies.
Basically the system MUST do this.
Once logged in one site the user must be logged in all of the other site seamlessly, not only following a link, but even by directly writing the domain name on the address bar.
To my knowledge the only way to achieve this are cross-domain cookies, if there are alternatives please tell me.
Thank you very much
My Idea would be to include a login-Javascript from a third domain which gets includet in all sites. This javascript sets and reads the session-cookie and calls the current domains server via ajax with the result. (No validation should be done in the JS - this simply sets and reads the cookie)
If cross domain AJAX does not work, you can still call the thirds domain server which acts like a proxy and calls the current domains server.
The StackOverflow sites have implemented something similar to this. Check out the details at the following links.
Here is a post giving an outline of how they did it.
And here is even more detail.
For this you do have to use cookies, but you can vary what you store in the cookie. The cookie doesn't have to contain user credentials but can instead contain something more like a token that you use to "centralize" your sessions.
Easies way would be to let all hosts share a single memcached server and use the content of the users cookie as your key.