The Bitrix Site Manager
system provides for creating and managing more
than one site
using a single product copy.
Such multiple site system features the following peculiarities:
Hence, a problem arises to distinguish a user visiting different sites
having different domain name. The problem in question concerns sites created in the context
of a single portal
User recognition is
achieved using the stored cookie storing the information sent by the web
server to a client browser. Cookies are stored on a client hard drive.
The following example will help you understand the gist of the problem.
- When a visitor opens a site A for the first time, he is assigned
a set of identifiers used by the variety of modules (e.g. a user ID in
the Statistics module or a customer ID int the e-Store
module etc.). These identifiers are stored in cookie of the site A.
- When the visitor opens a site A later, he will be recognized by
the information stored in cookie of the site A.
- Now imagine the visitor open the site B. The problem is to
recognize him as a visitor who opened the site A recently. By
saying "to recognize" we imply obtaining identifiers that he
have been given when opening the site A. Things may get
worse if the site B domain name differs from that of the site
A: information stored in cookie of the site A cannot be
retrieved by the site B, and vice versa: cookie set by the site
A cannot be assigned to the site B. This is stipulated
by the browser security policy.
To overcome these difficulties, a technology has been developed allowing to transfer
user cookie between different sites with different domain names but created
within the same portal. This technology
is also called UserMultiSiteTransfer.
The described technology functions by the following algorithm.
- When a visitor opens the site A, identifiers that the
system assigns to him are stored in cookie by calling CMain::set_cookie,
whose main purpose is not only set cookie for the current site
A, but also store the cookie data for further spread to other sites
(B, C, D).
- In the end of the epilogue visual
section, the method CMain::ShowSpreadCookieHTML
is called. This method displays a number of IFRAME's each calling
the script /bitrix/spread.php of the domain
for which the cookie is to be set. Thus, the system creates 3 IFRAME's
for each of the sites B, C and D each calling the
The system passes all the information required by this script to set cookie.
The information passed is strongly encrypted and signed with the
encrypted license key of the portal.
The result is that the cookie set by the site A is copied (transferred)
to sites B, C and D.
- The similar operations are performed for other sites. If a visitor opens
the site B and obtains an identifier that should be
stored in cookie, this identifier will be stored for sites A, C
and D. This ensures a unified set of cookie are set for all sites
of the single portal.
This technology allows the Statistics
module to register unique visitors of the whole portal.
and banners module becomes able to correctly count the number of a banner
shows to a specific visitor. Other modules make an active use of this technology