Cross-Domain Solutions and Same-Origin Policy Practices in the Cloud Account Platform

58 Group operates many product lines with various account systems, including legacy 58 accounts and acquired non‑58 accounts, leading to duplicated development effort and uneven security capabilities.

The cloud account platform aggregates basic and security capabilities into a middle‑platform service, offering a unified SDK for rapid reuse, data isolation, and consistent security guarantees, thereby improving efficiency.

What is cross‑domain? When the protocol, domain (including sub‑domain), or port differs between two URLs, they are considered different origins, and accessing resources across them is called cross‑domain.

What is the Same‑Origin Policy (SOP)? Introduced by Netscape in 1995, SOP requires that protocol, domain, and port all match; it is a core browser security mechanism that prevents XSS, CSRF, and other attacks.

The cloud account platform’s cross‑domain practice requires: (1) writing the platform’s main ticket into passport.58.com cookie, (2) writing the business ticket into the business domain’s cookie, and (3) invoking a JavaScript callback after login.

JSONP cross‑domain + proxy address – The SDK makes a GET request to the business side’s proxy address; the proxy sets the cookie on the business domain and returns a JSONP response that triggers the front‑end callback.

Iframe + script + proxy address – For POST‑based APIs, an iframe posts to the server, which returns a script (served via a 302 redirect to the proxy) that sets the cookie and calls parent.jscallback('data'); . The client then executes the script to complete the callback.

To simplify integration, the proxy’s internal logic is fully encapsulated for the client.

On iOS 10+ devices, browsers block cross‑site tracking, which can affect cookie‑based solutions.

Independent domain – Each account system receives its own domain, reducing legal and technical complications and allowing front‑end and back‑end to follow domain‑based rules to avoid cross‑origin issues.

302 redirect – Directly redirects to the target domain to set cookies, then redirects back, avoiding cross‑origin restrictions but interrupting the user flow.

CORS (Cross‑Origin Resource Sharing) – A W3C standard that enables browsers to make cross‑origin XMLHttpRequests when both client and server support it; all modern browsers support CORS, with IE requiring version 10 or XDomainRequest for IE8/9.

Summary – The cloud account platform combines multiple cross‑domain techniques (JSONP, iframe, independent domains, 302 redirects, and CORS) to meet various integration needs while maintaining security and efficiency.

Author bio – Sun Jingchao, backend architect of the User Platform team, responsible for building and optimizing the cloud account platform and its risk‑control systems at 58 Group.