CN104426862B - 实现跨域请求登录的方法、系统及浏览器 - Google Patents

实现跨域请求登录的方法、系统及浏览器 Download PDF

Info

Publication number
CN104426862B
CN104426862B CN201310378892.4A CN201310378892A CN104426862B CN 104426862 B CN104426862 B CN 104426862B CN 201310378892 A CN201310378892 A CN 201310378892A CN 104426862 B CN104426862 B CN 104426862B
Authority
CN
China
Prior art keywords
domain
cookie
request
access
access request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201310378892.4A
Other languages
English (en)
Other versions
CN104426862A (zh
Inventor
温建文
徐永
李燕燕
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Tencent Cloud Computing Beijing Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201310378892.4A priority Critical patent/CN104426862B/zh
Publication of CN104426862A publication Critical patent/CN104426862A/zh
Application granted granted Critical
Publication of CN104426862B publication Critical patent/CN104426862B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H04L61/106—Mapping addresses of different types across networks, e.g. mapping telephone numbers to data network addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明涉及一种实现跨域请求登录的方法、系统及浏览器，其方法包括：第一域业务服务器在浏览器登录第一域成功后，获取第二域的认证串写入第一域的cookie，将此cookie发给浏览器；浏览器在接收到对第二域的访问请求时，将第二域的访问请求的域名修改为带有第二域专用标识的第一域的相关域，将此请求携带第一域的cookie发送给第一域接入服务器；第一域接入服务器通过域名匹配识别判断当前请求为第二域的访问请求，从第一域的cookie中获取第二域的认证串写入第二域cookie，将第二域cookie携带在第二域的访问请求中转发至第二域业务服务器。由此完成跨域认证请求，使前端不存在跨域的问题，实现灵活且成本低。

Description

实现跨域请求登录的方法、系统及浏览器
技术领域
本发明涉及互联网技术领域，尤其涉及一种基于nginx（一种接入服务器）的实现跨域请求登录的方法、系统及浏览器。
背景技术
通过浏览器访问网页时，通常会涉及跨域请求访问。其中，跨域请求是指一个域名站点中的资源去访问另外一个不同域名站点上的资源。跨域请求访问可以将请求分摊到不同的服务器，减轻单个服务器压力以提高响应速度；另外还可以将不同的业务逻辑分布到不同的服务器上以降低负载。
目前实现单点登录带认证态的跨域请求方式主要有JSONP跨域请求、iframe嵌入第二域的页面的请求方式以及服务端中转请求方式。
其中，JSONP跨域请求有以下两种实现方式：
第一种方式：当用户在第一域登录认证后，浏览器前端获取到skey（用户登录认证后拿到的认证串，用于后续请求中判断用户是否己登录）后，再发送登录第二域的特定的url（Uniform/Universal Resource Locator，统一资源定位符，也称网址）请求，该url请求将skey写入第二域的cookie中，后续jsonp调用第二域的请求时即可认证通过；
第二种方式：在第一域登录认证后，浏览器前端获取到skey，后续再往第二域发送请求，将上述skey作为参数传递到第二域进行认证；
iframe嵌入第二域的页面的请求有以下两种实现方式：
第一种方式：在第一域登录认证后，浏览器前端获取到skey，再发送登录第二域的特定的url请求，该url请求将skey写入第二域的cookie中，后续iframe的第二域请求就会认证通过；
第二种方式：在第一域登录后，浏览器前端获取到skey，以参数的形式传入iframe的url请求中，这样通过iframe访问第二域时，就可以认证通过；
对于服务端中转请求，其包括以下两种实现方式：
第一种方式：第一域的服务端实现所有第二域接口，第一域所有发往第二域的请求通过服务端中转，服务端中转时将skey携带在请求中发送给第二域（skey以cookie或参数的形式传递）；
第二种方式：第一域的服务端实现一个通用接口，针对第一域所有发往第二域的请求，将第二域的参数和请求的url以参数形式传给第一域的通用接口，该通用接口带上skey再中转请求给第二域（skey以cookie或参数的形式传递）。
但是，现有的上述三种跨域请求存在以下缺点：jsonp跨域请求只能在第二域提供了jsonp接口的情况下调用，对于非jsonp的ajax接口，则无法实现跨域请求；对于iframe嵌入第二域的页面的请求方式，在iframe页面跳转时，地址栏的地址不会变化，且第一域的js无法与第二域的js进行互相调用，因此，其实现过程不够灵活；对于服务端中转请求的方式，则存在服务端实现成本高的缺陷。
发明内容
本发明实施例提供一种实现灵活、通用性好且成本低的跨域请求登录实现方法、系统及浏览器。
本发明实施例提出一种实现跨域请求登录的方法，包括：
第一域业务服务器在浏览器登录第一域成功后，获取第二域的认证串写入所述第一域的cookie，并将所述第一域的cookie发送给浏览器；
所述浏览器在接收到对第二域的访问请求时，将所述第二域的访问请求携带所述第一域的cookie发送给第一域接入服务器，所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域；
所述第一域接入服务器通过域名匹配识别到所述第一域的相关域中的所述第二域专用标识时，判断当前接收的请求为第二域的访问请求，从所述第一域的cookie中获取所述第二域的认证串，写入第二域的cookie，并将所述第二域的cookie携带在第二域的访问请求中转发至第二域业务服务器。
本发明实施例还提出一种实现跨域请求登录的方法，包括：
接收对第一域的访问请求，将所述第一域的访问请求经所述第一域接入服务器转发至第一域业务服务器；
在浏览器登录第一域成功后，接收所述第一域业务服务器返回的携带有第二域的认证串的第一域的cookie；
接收对第二域的访问请求，所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域；
将所述第二域的访问请求携带所述第一域的cookie发送给第一域接入服务器；由所述第一域接入服务器通过域名匹配识别到第二域的访问请求时，将所述第一域的cookie中的第二域的认证串写入第二域的cookie，携带在第二域的访问请求中转发至第二域业务服务器。
本发明实施例还提出一种实现跨域请求登录的系统，包括：浏览器、第一域接入服务器、第一域业务服务器、至少一第二域业务服务器；
所述第一域业务服务器，用于在浏览器登录第一域成功后，获取第二域的认证串写入所述第一域的cookie，并将所述第一域的cookie发送给浏览器；
所述浏览器，用于接收所述第一域业务服务器发送的所述第一域的cookie；在接收到对第二域的访问请求时，将所述第二域的访问请求携带所述第一域的cookie发送给所述第一域接入服务器；所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域；
所述第一域接入服务器，用于通过域名匹配识别到所述第一域的相关域中的所述第二域专用标识时，判断当前接收的请求为第二域的访问请求，从所述第一域的cookie中获取所述第二域的认证串，写入第二域的cookie，并将所述第二域的cookie携带在第二域的访问请求中转发至所述至少一第二域业务服务器。
本发明实施例还提出一种实现跨域请求登录的浏览器，包括：
第一转发模块，用于接收对第一域的访问请求，将所述第一域的访问请求经所述第一域接入服务器转发至第一域业务服务器；
接收模块，用于在浏览器登录第一域成功后，接收所述第一域业务服务器返回的携带有第二域的认证串的第一域的cookie；以及接收对第二域的访问请求，所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域；
第二转发模块，用于将所述第二域的访问请求携带所述第一域的cookie发送给第一域接入服务器；由所述第一域接入服务器通过域名匹配识别到第二域的访问请求时，将所述第一域的cookie中的第二域的认证串写入第二域的cookie，携带在第二域的访问请求中转发至第二域业务服务器。
本发明实施例提出的一种实现跨域请求登录的方法、系统及浏览器，在浏览器登录第一域成功后，通过第一域业务服务器将携带有第二域的认证串的第一域的cookie发送给浏览器；浏览器在接收到对第二域的访问请求时，将该第二域的访问请求携带第一域的cookie发送给第一域接入服务器，该第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域；第一域接入服务器通过域名匹配识别到第一域的相关域中的所述第二域专用标识时，判断当前接收的请求为第二域的访问请求，从第一域的cookie中获取所述第二域的认证串，写入第二域的cookie，并将第二域的cookie携带在第二域的访问请求中转发至第二域业务服务器，由此，通过将第二域的所有请求变成第一域的子域等相关域的请求，通过第一域的接入服务器带上第二域的认证串进行转发，完成跨域认证请求，使前端不存在跨域的问题，其实现方式灵活、通用性好且成本低。
附图说明
图1是本发明实现跨域请求登录的方法第一实施例的流程示意图；
图2a是发明实施例实现跨域请求登录的一种实例的流程示意图；
图2b是发明实施例实现跨域请求登录的另一种实例的流程示意图；
图3是本发明实现跨域请求登录的方法第二实施例的流程示意图；
图4是本发明实现跨域请求登录的系统较佳实施例的结构示意图；
图5是本发明实现跨域请求登录的浏览器较佳实施例的结构示意图。
为了使本发明的技术方案更加清楚、明了，下面将结合附图作进一步详述。
具体实施方式
本发明实施例涉及的技术术语包括：
skey：用户登录认证后拿到的认证串，用于后续请求中判断用户是否己登录；
nginx：是高性能的Web服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，并在一个BSD-like协议下发行。其特点是占有内存少，并发能力强，国内使用nginx网站的用户有：新浪、网易、腾讯等；
cookie：有时也用其复数形式cookies，指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据（通常经过加密）。由网络服务器发送出来以存储在网络浏览器上；cookie是个存储在浏览器目录的文本文件，当浏览器运行时，存储在RAM中。一旦用户从该网站或网络服务器退出，cookie也可存储在计算机的硬驱上。当用户结束其浏览器对话时，即终止的所有cookie。
网站可以利用cookies跟踪统计用户访问该网站的习惯，比如什么时间访问，访问了哪些页面，在每个网页的停留时间等。利用这些信息，一方面是可以为用户提供个性化的服务，另一方面，也可以作为了解所有用户行为的工具。
目前cookies最广泛的的应用是记录用户登录信息，这样下次访问时可以不需要输入自己的用户名、密码，以便简化登录手续。
基于上述技术，如图1所示，本发明第一实施例提出一种实现跨域请求登录的方法，包括：
步骤S101，第一域业务服务器在浏览器登录第一域成功后，获取第二域的认证串写入所述第一域的cookie，并将所述第一域的cookie发送给浏览器；
本实施例方法运行环境涉及浏览器、第一域接入服务器、第一域业务服务器及至少一第二域业务服务器，其中：
浏览器作为前端接收用户的访问请求，根据该访问请求经第一域接入服务器转发从后台服务器（第一域业务服务器及至少一第二域业务服务器）获取访问数据，并展示给用户。
本实施例第一域接入服务器具体可以采用但不限于nginx服务器。如前所述，nginx服务器是高性能的Web服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器。通过第一域接入服务器实现访问请求的接入，并根据访问请求的类型转发至不同域的业务服务器。
本实施例可以实现不同于现有的JSONP跨域请求、iframe嵌入第二域的页面的请求方式以及服务端中转请求方式的跨域带登录态请求，以提高跨域请求登录的灵活性与通用性好，且成本低。
具体地，该跨域带登录态请求基于第一域的成功登录而实现。
首先，用户向浏览器发送对第一域的访问请求，浏览器接收到该第一域的访问请求后，将此访问请求转发至第一域接入服务器，由第一域接入服务器将此对第一域的访问请求转发至第一域业务服务器，以获取第一域的业务数据。
第一域业务服务器在收到对第一域的访问请求后，对此访问请求进行登录验证，当验证登录通过后，获取第二域的认证串（skey）写入第一域的cookie，并将携带有第二域的认证串的第一域的cookie发送给浏览器。
其中，获取第二域的认证串写入第一域的cookie，是为了后续第一接入服务器从第一域的cookie取出第二域的认证串，并在接入服务器向第二域业务服务器转发第二域的访问请求时带上该第二域的认证串，以实现跨域认证请求。
本实施例获取第二域的认证串写入第一域的cookie的方式具体可以采用以下两种：
对于第一域与第二域具有相同的认证串的情形，第一域业务服务器在浏览器登录第一域成功后，将第一域登录认证后得到的认证串写入第一域的cookie，该认证串可以作为后续第一域再次登录请求以及第二域登录请求时的登录认证，以判断用户是否己登录。
对于第一域的认证串与第二域的认证串不相同但可置换的情形，第一域业务服务器在浏览器登录第一域成功后，向第二域业务服务器置换获取第二域的认证串并写入所述第一域的cookie；当然作为第一域的正常登录流程，第一域业务服务器在浏览器登录第一域成功后，还会将第一域登录认证后得到的认证串写入第一域的cookie，该认证串作为后续第一域再次登录请求时的登录认证，以判断用户是否己登录。
步骤S102，所述浏览器在接收到对第二域的访问请求时，将第二域的访问请求携带所述第一域的cookie发送给第一域接入服务器；所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域；
在浏览器侧，浏览器在接收到第一域业务服务器发送的携带有第二域的认证串的第一域的cookie后，会将此携带有第二域的认证串的第一域的cookie保存在本地。
之后，浏览器在接收到用户对第二域的访问请求时，将携带有第二域的认证串的第一域的cookie携带在第二域的访问请求中，一同发送给第一域接入服务器，由第一域接入服务器将此对第二域的访问请求转发至第二域业务服务器。
其中，所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域，以便通过第一域接入服务器进行域名匹配，将此第二域的访问请求转发至第二域业务服务器，以实现跨域请求登录，同时又能避免前端存在跨域的问题，进而可以提高跨域请求登录的灵活性与通用性。
将第二域的访问请求的域名修改为带有第二域专用标识的第一域的相关域是为了便于第一域接入服务器对第二域的访问请求的判断识别，对于第二域的访问请求的域名的修改可以由开发人员预先根据用户需要来修改完成，上述域名修改具体可以采用以下方式：
第一种方式：
将第二域的访问请求的域名修改为第一域的子域，比如：第一域www.a.com需要请求带登录态的第二域地址www.b.com/xx/url.xhtml；用户登录后将skey写入www.a.com的cookie中，www.a.com的页面中本来请求第二域地址www.b.com/xx/url.xhtml，现在改请求为s.a.com/xx/url.xhtml，其中s.a.com为第二域请求专用子域，后续，第一域接入服务器收到请求后识别s.a.com为第二域的请求，将www.a.com的cookie中第二域的skey写入www.b.com的cookie中，并请求www.b.com/xx/url.xhtml完成跨域认证请求。
第二种方式：
将第二域的访问请求的域名修改为携带有第二域专用前缀、后缀或相关参数的第一域的相关域。比如，上述例子中，可将第二域地址www.b.com/xx/url.xhtml修改为www.a.com/p_b/xx/url.xhtml，其中p_b为第二域专用前缀，类似的修改方式，还可以在URL地址中采用后缀或其他相关参数。
步骤S103，所述第一域接入服务器通过域名匹配识别到所述第一域的相关域中的所述第二域专用标识时，判断当前接收的请求为第二域的访问请求，从所述第一域的cookie中获取所述第二域的认证串，写入第二域的cookie，并将所述第二域的cookie携带在第二域的访问请求中转发至第二域业务服务器。
第一域接入服务器接收到浏览器发送的域名修改后的第二域的访问请求后，对该请求进行域名匹配，识别到所述第一域的相关域中的第二域专用标识时，则可以判断当前接收的请求为第二域的访问请求，从第一域的cookie中获取第二域的认证串，写入第二域的cookie。
另外，第一域接入服务器还会将第二域的访问请求的域名由带有第二域专用标识的第一域的相关域还原为第二域地址的访问请求，并将第二域的cookie携带在第二域地址的访问请求中转发至第二域业务服务器，由此完成跨域登录认证请求的发送。
之后，第二域业务服务器接收到第二域的访问请求后，对此访问请求进行登录认证，在第二域登录成功之后，向浏览器返回业务数据。完成第二域的跨域访问。
本实施例通过将第二域的所有请求变成第一域的子域等相关域的请求，通过第一域的接入服务器带上第二域的认证串进行转发，完成跨域认证请求，使前端不存在跨域的问题，其实现形式灵活、通用性好且成本低。
下面以nginx接入服务器转发第二域的访问请求为例再次对本实施例方案进行详细阐述：
本实例使用nginx接入服务器转发请求，将第二域的所有请求变成第一域子域的请求，通过第一域的nginx带上skey进行转发，这样前端就不存在跨域的问题。详细过程如下：
如图2a所示，首先，用户通过浏览器、第一域的nginx向第一域业务服务器发送第一域的登录访问请求。
在第一域登录成功后，第一域业务服务器将认证通过后得到的skey（本实例以第一域与第二域具有相同的认证串进行举例）写入第一域cookie；
开发人员预先将所有原来访问第二域的请求的域名修改成第一域的子域（该子域只用于第二域的请求）；
浏览器将访问第二域的请求发送给第一域的nginx，第一域的nginx接收到请求后，通过域名匹配，判断为第二域的请求，将第一域cookie中的skey写入第二域的cooike中，将第二域的cooike携带在第二域的访问请求中转发至第二域业务服务器，完成跨域认证请求，
具体举例如下：
比如：第一域www.a.com需要请求带登录态的第二域地址www.b.com/xx/url.xhtml；用户登录后将skey写入www.a.com的cookie中，www.a.com的页面中本来请求第二域地址www.b.com/xx/url.xhtml，现在改请求为s.a.com/xx/url.xhtml，其中s.a.com为第二域请求专用子域，nginx收到请求后识别s.a.com为第二域的请求，将www.a.com的cookie中的skey写入www.b.com的cookie中，并请求www.b.com/xx/url.xhtml完成跨域认证请求。
另外，当第一域和第二域的skey不相同但可以置换时，该方案也可以支持，只需要在用户第一域登录成功后，第一域业务服务器向第二域业务服务器置换获取到第二域的skey，写入第一域的cookie，第一域的nginx在转发请求时，将第一域的cookie中的第二域的skey取出，写入第二域的cookie中转发请求即可，如图2b所示。
如前所述，第一域接入服务器判断是否为第二域的请求，除了用子域的方式，也可以是url带前缀（比如上边例子中可用www.a.com/p_b/xx/url.xhtml，其中p_b为第二域专用前缀）、后缀或者参数的方式，在此不再赘述。
本实施例通过上述方案，nginx通过第二域专用标识识别出第二域的请求，获取第一域cookie中的skey写到第二域的cookie里，转发到第二域，从而避开浏览器跨域及认证的问题，提高了跨越登录请求的灵活性、通用性，同时还可以降低成本。
如图3所示，本发明第二实施例针对浏览器侧提出一种实现跨域请求登录的方法，包括：
步骤S10，接收对第一域的访问请求，将所述第一域的访问请求经所述第一域接入服务器转发至第一域业务服务器；
步骤S20，在浏览器登录第一域成功后，接收所述第一域业务服务器返回的携带有第二域的认证串的第一域的cookie；
其中，浏览器作为前端接收用户的访问请求，根据该访问请求经第一域接入服务器转发从后台服务器（第一域业务服务器及至少一第二域业务服务器）获取访问数据，并展示给用户。
本实施例第一域接入服务器具体可以采用但不限于nginx服务器。如前所述，nginx服务器是高性能的Web服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器。通过第一域接入服务器实现访问请求的接入，并根据访问请求的类型转发至不同域的业务服务器。
本实施例可以实现不同于现有的JSONP跨域请求、iframe嵌入第二域的页面的请求方式以及服务端中转请求方式的跨域带登录态请求，以提高跨域请求登录的灵活性与通用性好，且成本低。
具体地，该跨域带登录态请求基于第一域的成功登录而实现。
首先，用户向浏览器发送对第一域的访问请求，浏览器接收到该第一域的访问请求后，将此访问请求转发至第一域接入服务器，由第一域接入服务器将此对第一域的访问请求转发至第一域业务服务器，以获取第一域的业务数据。
第一域业务服务器在收到对第一域的访问请求后，对此访问请求进行登录验证，当验证登录通过后，获取第二域的认证串（skey）写入第一域的cookie，并将携带有第二域的认证串的第一域的cookie发送给浏览器。
其中，获取第二域的认证串写入第一域的cookie，是为了后续第一接入服务器从第一域的cookie取出第二域的认证串，并在接入服务器向第二域业务服务器转发第二域的访问请求时带上该第二域的认证串，以实现跨域认证请求。
本实施例获取第二域的认证串写入第一域的cookie的方式具体可以采用以下两种：
对于第一域与第二域具有相同的认证串的情形，第一域业务服务器在浏览器登录第一域成功后，将第一域登录认证后得到的认证串写入第一域的cookie，该认证串可以作为后续第一域再次登录请求以及第二域登录请求时的登录认证，以判断用户是否己登录。
对于第一域的认证串与第二域的认证串不相同但可置换的情形，第一域业务服务器在浏览器登录第一域成功后，向第二域业务服务器置换获取第二域的认证串并写入所述第一域的cookie；当然作为第一域的正常登录流程，第一域业务服务器在浏览器登录第一域成功后，还会将第一域登录认证后得到的认证串写入第一域的cookie，该认证串作为后续第一域再次登录请求时的登录认证，以判断用户是否己登录。
浏览器在接收到第一域业务服务器发送的携带有第二域的认证串的第一域的cookie后，会将此携带有第二域的认证串的第一域的cookie保存在本地。
步骤S30，接收对第二域的访问请求，所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域；
步骤S40，将第二域的访问请求携带所述第一域的cookie发送给第一域接入服务器；由所述第一域接入服务器通过域名匹配识别到第二域的访问请求时，将所述第一域的cookie中的第二域的认证串写入第二域的cookie，携带在第二域的访问请求中转发至第二域业务服务器。
浏览器在接收到用户对第二域的访问请求时，将携带有第二域的认证串的第一域的cookie携带在第二域的访问请求中，一同发送给第一域接入服务器，由第一域接入服务器将此对第二域的访问请求转发至第二域业务服务器。
其中，所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域，以便通过第一域接入服务器进行域名匹配，将此第二域的访问请求转发至第二域业务服务器，以实现跨域请求登录，同时又能避免前端存在跨域的问题，进而可以提高跨域请求登录的灵活性与通用性。
将第二域的访问请求的域名修改为带有第二域专用标识的第一域的相关域是为了便于第一域接入服务器对第二域的访问请求的判断识别，对于第二域的访问请求的域名的修改可以由开发人员预先根据用户需要来修改完成，上述域名修改具体可以采用以下方式：
第一种方式：
将第二域的访问请求的域名修改为第一域的子域，比如：第一域www.a.com需要请求带登录态的第二域地址www.b.com/xx/url.xhtml；用户登录后将skey写入www.a.com的cookie中，www.a.com的页面中本来请求第二域地址www.b.com/xx/url.xhtml，现在改请求为s.a.com/xx/url.xhtml，其中s.a.com为第二域请求专用子域，后续，第一域接入服务器收到请求后识别s.a.com为第二域的请求，将www.a.com的cookie中第二域的skey写入www.b.com的cookie中，并请求www.b.com/xx/url.xhtml完成跨域认证请求。
第二种方式：
将第二域的访问请求的域名修改为携带有第二域专用前缀、后缀或相关参数的第一域的相关域。比如，上述例子中，可将第二域地址www.b.com/xx/url.xhtml修改为www.a.com/p_b/xx/url.xhtml，其中p_b为第二域专用前缀，类似的修改方式，还可以在URL地址中采用后缀或其他相关参数。
然后，浏览器将携带有第二域的认证串的第一域的cookie携带在域名修改后的第二域的访问请求中，一同发送给第一域接入服务器，由第一域接入服务器将此对第二域的访问请求转发至第二域业务服务器。
第一域接入服务器接收到浏览器发送的域名修改后的第二域的访问请求后，对该请求进行域名匹配，识别到所述第一域的相关域中的第二域专用标识时，则可以判断当前接收的请求为第二域的访问请求，从第一域的cookie中获取第二域的认证串，写入第二域的cookie。
另外，第一域接入服务器还会将第二域的访问请求的域名由带有第二域专用标识的第一域的相关域还原为第二域地址的访问请求，并将第二域的cookie携带在第二域地址的访问请求中转发至第二域业务服务器，由此完成跨域登录认证请求的发送。
之后，第二域业务服务器接收到第二域的访问请求后，对此访问请求进行登录认证，在第二域登录成功之后，向浏览器返回业务数据。浏览器接收到第二域业务服务器返回的业务数据后展示给用户，由此完成第二域的跨域访问。
本实施例通过将第二域的所有请求变成第一域的子域等相关域的请求，通过第一域的接入服务器带上第二域的认证串进行转发，完成跨域认证请求，使前端不存在跨域的问题，其实现形式灵活、通用性好且成本低。
下面以nginx接入服务器转发第二域的访问请求为例再次对本实施例方案进行详细阐述：
本实例使用nginx接入服务器转发请求，将第二域的所有请求变成第一域子域的请求，通过第一域的nginx带上skey进行转发，这样前端就不存在跨域的问题。详细过程如下：
如图2a所示，首先，用户通过浏览器、第一域的nginx向第一域业务服务器发送第一域的登录访问请求。
在第一域登录成功后，第一域业务服务器将认证通过后得到的skey（本实例以第一域与第二域具有相同的认证串进行举例）写入第一域cookie；
开发人员预先将所有原来访问第二域的请求的域名修改成第一域的子域（该子域只用于第二域的请求）；
浏览器将访问第二域的请求发送给第一域的nginx，第一域的nginx接收到请求后，通过域名匹配，判断为第二域的请求，将第一域cookie中的skey写入第二域的cooike中，将第二域的cooike携带在第二域的访问请求中转发至第二域业务服务器，完成跨域认证请求，
具体举例如下：
比如：第一域www.a.com需要请求带登录态的第二域地址www.b.com/xx/url.xhtml；用户登录后将skey写入www.a.com的cookie中，www.a.com的页面中本来请求第二域地址www.b.com/xx/url.xhtml，现在改请求为s.a.com/xx/url.xhtml，其中s.a.com为第二域请求专用子域，nginx收到请求后识别s.a.com为第二域的请求，将www.a.com的cookie中的skey写入www.b.com的cookie中，并请求www.b.com/xx/url.xhtml完成跨域认证请求。
另外，当第一域和第二域的skey不相同但可以置换时，该方案也可以支持，只需要在用户第一域登录成功后，第一域业务服务器向第二域业务服务器置换获取到第二域的skey，写入第一域的cookie，第一域的nginx在转发请求时，将第一域的cookie中的第二域的skey取出，写入第二域的cookie中转发请求即可，如图2b所示。
如前所述，第一域接入服务器判断是否为第二域的请求，除了用子域的方式，也可以是url带前缀（比如上边例子中可用www.a.com/p_b/xx/url.xhtml，其中p_b为第二域专用前缀）、后缀或者参数的方式，在此不再赘述。
本实施例通过上述方案，nginx通过第二域专用标识识别出第二域的请求，获取第一域cookie中的skey写到第二域的cookie里，转发到第二域，从而避开浏览器跨域及认证的问题，提高了跨越登录请求的灵活性、通用性，同时还可以降低成本。
如同4所示，本发明较佳实施例提出一种实现跨域请求登录的系统，包括：浏览器201、第一域接入服务器202、第一域业务服务器203、至少一第二域业务服务器204（图4中以一个第二域业务服务器204进行举例）；
所述第一域业务服务器203，用于在浏览器201登录第一域成功后，获取第二域的认证串写入所述第一域的cookie，并将所述第一域的cookie发送给浏览器201；
所述浏览器201，用于接收所述第一域业务服务器203发送的所述第一域的cookie；在接收到对第二域的访问请求时，将第二域的访问请求携带所述第一域的cookie发送给所述第一域接入服务器202；所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域；
所述第一域接入服务器202，用于通过域名匹配识别到所述第一域的相关域中的所述第二域专用标识时，判断当前接收的请求为第二域的访问请求，从所述第一域的cookie中获取所述第二域的认证串，写入第二域的cookie，并将所述第二域的cookie携带在第二域的访问请求中转发至所述至少一第二域业务服务器204。
其中，浏览器201作为前端接收用户的访问请求，根据该访问请求经第一域接入服务器202转发从后台服务器（第一域业务服务器203及至少一第二域业务服务器204）获取访问数据，并展示给用户。
本实施例第一域接入服务器202具体可以采用但不限于nginx服务器。如前所述，nginx服务器是高性能的Web服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器。通过第一域接入服务器202实现访问请求的接入，并根据访问请求的类型转发至不同域的业务服务器。
本实施例可以实现不同于现有的JSONP跨域请求、iframe嵌入第二域的页面的请求方式以及服务端中转请求方式的跨域带登录态请求，以提高跨域请求登录的灵活性与通用性好，且成本低。
具体地，该跨域带登录态请求基于第一域的成功登录而实现。
首先，用户向浏览器201发送对第一域的访问请求，浏览器201接收到该第一域的访问请求后，将此访问请求转发至第一域接入服务器202，由第一域接入服务器202将此对第一域的访问请求转发至第一域业务服务器203，以获取第一域的业务数据。
第一域业务服务器203在收到对第一域的访问请求后，对此访问请求进行登录验证，当验证登录通过后，获取第二域的认证串（skey）写入第一域的cookie，并将携带有第二域的认证串的第一域的cookie发送给浏览器201。
其中，获取第二域的认证串写入第一域的cookie，是为了后续第一接入服务器从第一域的cookie取出第二域的认证串，并在接入服务器向第二域业务服务器204转发第二域的访问请求时带上该第二域的认证串，以实现跨域认证请求。
本实施例获取第二域的认证串写入第一域的cookie的方式具体可以采用以下两种：
对于第一域与第二域具有相同的认证串的情形，第一域业务服务器203在浏览器201登录第一域成功后，将第一域登录认证后得到的认证串写入第一域的cookie，该认证串可以作为后续第一域再次登录请求以及第二域登录请求时的登录认证，以判断用户是否己登录。
对于第一域的认证串与第二域的认证串不相同但可置换的情形，第一域业务服务器203在浏览器201登录第一域成功后，向第二域业务服务器204置换获取第二域的认证串并写入所述第一域的cookie；当然作为第一域的正常登录流程，第一域业务服务器203在浏览器201登录第一域成功后，还会将第一域登录认证后得到的认证串写入第一域的cookie，该认证串作为后续第一域再次登录请求时的登录认证，以判断用户是否己登录。
浏览器201在接收到第一域业务服务器203发送的携带有第二域的认证串的第一域的cookie后，会将此携带有第二域的认证串的第一域的cookie保存在本地。
之后，浏览器201在接收到用户对第二域的访问请求时，将携带有第二域的认证串的第一域的cookie携带在第二域的访问请求中，一同发送给第一域接入服务器202，由第一域接入服务器202将此对第二域的访问请求转发至第二域业务服务器204。
其中，所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域，以便通过第一域接入服务器202进行域名匹配，将此第二域的访问请求转发至第二域业务服务器204，以实现跨域请求登录，同时又能避免前端存在跨域的问题，进而可以提高跨域请求登录的灵活性与通用性。
将第二域的访问请求的域名修改为带有第二域专用标识的第一域的相关域是为了便于第一域接入服务器202对第二域的访问请求的判断识别，对于第二域的访问请求的域名的修改可以由开发人员预先根据用户需要来修改完成，上述域名修改具体可以采用以下方式：
第一种方式：
将第二域的访问请求的域名修改为第一域的子域，比如：第一域www.a.com需要请求带登录态的第二域地址www.b.com/xx/url.xhtml；用户登录后将skey写入www.a.com的cookie中，www.a.com的页面中本来请求第二域地址www.b.com/xx/url.xhtml，现在改请求为s.a.com/xx/url.xhtml，其中s.a.com为第二域请求专用子域，后续，第一域接入服务器202收到请求后识别s.a.com为第二域的请求，将www.a.com的cookie中第二域的skey写入www.b.com的cookie中，并请求www.b.com/xx/url.xhtml完成跨域认证请求。
第二种方式：
将第二域的访问请求的域名修改为携带有第二域专用前缀、后缀或相关参数的第一域的相关域。比如，上述例子中，可将第二域地址www.b.com/xx/url.xhtml修改为www.a.com/p_b/xx/url.xhtml，其中p_b为第二域专用前缀，类似的修改方式，还可以在URL地址中采用后缀或其他相关参数。
第一域接入服务器202接收到浏览器201发送的域名修改后的第二域的访问请求后，对该请求进行域名匹配，识别到所述第一域的相关域中的第二域专用标识时，则可以判断当前接收的请求为第二域的访问请求，从第一域的cookie中获取第二域的认证串，写入第二域的cookie。
另外，第一域接入服务器202还会将第二域的访问请求的域名由带有第二域专用标识的第一域的相关域还原为第二域地址的访问请求，并将第二域的cookie携带在第二域地址的访问请求中转发至第二域业务服务器204，由此完成跨域登录认证请求的发送。
之后，第二域业务服务器204接收到第二域的访问请求后，对此访问请求进行登录认证，在第二域登录成功之后，向浏览器201返回业务数据。浏览器201接收到第二域业务服务器204返回的业务数据后展示给用户，由此完成第二域的跨域访问。
本实施例通过将第二域的所有请求变成第一域的子域等相关域的请求，通过第一域的接入服务器带上第二域的认证串进行转发，完成跨域认证请求，使前端不存在跨域的问题，其实现形式灵活、通用性好且成本低。
下面以nginx接入服务器转发第二域的访问请求为例再次对本实施例方案进行详细阐述：
本实例使用nginx接入服务器转发请求，将第二域的所有请求变成第一域子域的请求，通过第一域的nginx带上skey进行转发，这样前端就不存在跨域的问题。详细过程如下：
如图2a所示，首先，用户通过浏览器201、第一域的nginx向第一域业务服务器203发送第一域的登录访问请求。
在第一域登录成功后，第一域业务服务器203将认证通过后得到的skey（本实例以第一域与第二域具有相同的认证串进行举例）写入第一域cookie；
开发人员预先将所有原来访问第二域的请求的域名修改成第一域的子域（该子域只用于第二域的请求）；
浏览器201将访问第二域的请求发送给第一域的nginx，第一域的nginx接收到请求后，通过域名匹配，判断为第二域的请求，将第一域cookie中的skey写入第二域的cooike中，将第二域的cooike携带在第二域的访问请求中转发至第二域业务服务器204，完成跨域认证请求，
具体举例如下：
比如：第一域www.a.com需要请求带登录态的第二域地址www.b.com/xx/url.xhtml；用户登录后将skey写入www.a.com的cookie中，www.a.com的页面中本来请求第二域地址www.b.com/xx/url.xhtml，现在改请求为s.a.com/xx/url.xhtml，其中s.a.com为第二域请求专用子域，nginx收到请求后识别s.a.com为第二域的请求，将www.a.com的cookie中的skey写入www.b.com的cookie中，并请求www.b.com/xx/url.xhtml完成跨域认证请求。
另外，当第一域和第二域的skey不相同但可以置换时，该方案也可以支持，只需要在用户第一域登录成功后，第一域业务服务器203向第二域业务服务器204置换获取到第二域的skey，写入第一域的cookie，第一域的nginx在转发请求时，将第一域的cookie中的第二域的skey取出，写入第二域的cookie中转发请求即可，如图2b所示。
如前所述，第一域接入服务器202判断是否为第二域的请求，除了用子域的方式，也可以是url带前缀（比如上边例子中可用www.a.com/p_b/xx/url.xhtml，其中p_b为第二域专用前缀）、后缀或者参数的方式，在此不再赘述。
本实施例通过上述方案，nginx通过第二域专用标识识别出第二域的请求，获取第一域cookie中的skey写到第二域的cookie里，转发到第二域，从而避开浏览器201跨域及认证的问题，提高了跨越登录请求的灵活性、通用性，同时还可以降低成本。
如图5所示，本发明较佳实施例提出一种实现跨域请求登录的浏览器，包括：第一转发模块301、接收模块302以及第二转发模块303，其中：
第一转发模块301，用于接收对第一域的访问请求，将所述第一域的访问请求经所述第一域接入服务器转发至第一域业务服务器；
接收模块302，用于在浏览器登录第一域成功后，接收所述第一域业务服务器返回的携带有第二域的认证串的第一域的cookie；以及接收对第二域的访问请求，所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域；
第二转发模块303，用于将第二域的访问请求携带所述第一域的cookie发送给第一域接入服务器；由所述第一域接入服务器通过域名匹配识别到第二域的访问请求时，将所述第一域的cookie中的第二域的认证串写入第二域的cookie，携带在第二域的访问请求中转发至第二域业务服务器。
其中，浏览器作为前端接收用户的访问请求，根据该访问请求经第一域接入服务器转发从后台服务器（第一域业务服务器及至少一第二域业务服务器）获取访问数据，并展示给用户。
本实施例第一域接入服务器具体可以采用但不限于nginx服务器。如前所述，nginx服务器是高性能的Web服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器。通过第一域接入服务器实现访问请求的接入，并根据访问请求的类型转发至不同域的业务服务器。
本实施例可以实现不同于现有的JSONP跨域请求、iframe嵌入第二域的页面的请求方式以及服务端中转请求方式的跨域带登录态请求，以提高跨域请求登录的灵活性与通用性好，且成本低。
具体地，该跨域带登录态请求基于第一域的成功登录而实现。
首先，用户向浏览器发送对第一域的访问请求，浏览器接收到该第一域的访问请求后，通过第一转发模块301将此访问请求转发至第一域接入服务器，由第一域接入服务器将此对第一域的访问请求转发至第一域业务服务器，以获取第一域的业务数据。
第一域业务服务器在收到对第一域的访问请求后，对此访问请求进行登录验证，当验证登录通过后，获取第二域的认证串（skey）写入第一域的cookie，并将携带有第二域的认证串的第一域的cookie发送给浏览器，浏览器通过接收模块302接收第一域业务服务器发送的携带有第二域的认证串的第一域的cookie。
其中，第一域业务服务器获取第二域的认证串写入第一域的cookie，是为了后续第一接入服务器从第一域的cookie取出第二域的认证串，并在接入服务器向第二域业务服务器转发第二域的访问请求时带上该第二域的认证串，以实现跨域认证请求。
本实施例获取第二域的认证串写入第一域的cookie的方式具体可以采用以下两种：
对于第一域与第二域具有相同的认证串的情形，第一域业务服务器在浏览器登录第一域成功后，将第一域登录认证后得到的认证串写入第一域的cookie，该认证串可以作为后续第一域再次登录请求以及第二域登录请求时的登录认证，以判断用户是否己登录。
对于第一域的认证串与第二域的认证串不相同但可置换的情形，第一域业务服务器在浏览器登录第一域成功后，向第二域业务服务器置换获取第二域的认证串并写入所述第一域的cookie；当然作为第一域的正常登录流程，第一域业务服务器在浏览器登录第一域成功后，还会将第一域登录认证后得到的认证串写入第一域的cookie，该认证串作为后续第一域再次登录请求时的登录认证，以判断用户是否己登录。
浏览器在接收到第一域业务服务器发送的携带有第二域的认证串的第一域的cookie后，会将此携带有第二域的认证串的第一域的cookie保存在本地。
之后，浏览器在接收到用户对第二域的访问请求时，通过第二转发模块303将携带有第二域的认证串的第一域的cookie携带在域名修改后的第二域的访问请求中，一同发送给第一域接入服务器，由第一域接入服务器将此对第二域的访问请求转发至第二域业务服务器。
其中，将所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域，以便通过第一域接入服务器进行域名匹配，将此第二域的访问请求转发至第二域业务服务器，以实现跨域请求登录，同时又能避免前端存在跨域的问题，进而可以提高跨域请求登录的灵活性与通用性。
将第二域的访问请求的域名修改为带有第二域专用标识的第一域的相关域是为了便于第一域接入服务器对第二域的访问请求的判断识别，对于第二域的访问请求的域名的修改可以由开发人员预先根据用户需要来修改完成，上述域名修改具体可以采用以下方式：
第一种方式：
将第二域的访问请求的域名修改为第一域的子域，比如：第一域www.a.com需要请求带登录态的第二域地址www.b.com/xx/url.xhtml；用户登录后将skey写入www.a.com的cookie中，www.a.com的页面中本来请求第二域地址www.b.com/xx/url.xhtml，现在改请求为s.a.com/xx/url.xhtml，其中s.a.com为第二域请求专用子域，后续，第一域接入服务器收到请求后识别s.a.com为第二域的请求，将www.a.com的cookie中第二域的skey写入www.b.com的cookie中，并请求www.b.com/xx/url.xhtml完成跨域认证请求。
第二种方式：
将第二域的访问请求的域名修改为携带有第二域专用前缀、后缀或相关参数的第一域的相关域。比如，上述例子中，可将第二域地址www.b.com/xx/url.xhtml修改为www.a.com/p_b/xx/url.xhtml，其中p_b为第二域专用前缀，类似的修改方式，还可以在URL地址中采用后缀或其他相关参数。
第一域接入服务器接收到浏览器发送的域名修改后的第二域的访问请求后，对该请求进行域名匹配，识别到所述第一域的相关域中的第二域专用标识时，则可以判断当前接收的请求为第二域的访问请求，从第一域的cookie中获取第二域的认证串，写入第二域的cookie。
另外，第一域接入服务器还会将第二域的访问请求的域名由带有第二域专用标识的第一域的相关域还原为第二域地址的访问请求，并将第二域的cookie携带在第二域地址的访问请求中转发至第二域业务服务器，由此完成跨域登录认证请求的发送。
之后，第二域业务服务器接收到第二域的访问请求后，对此访问请求进行登录认证，在第二域登录成功之后，向浏览器返回业务数据。浏览器接收到第二域业务服务器返回的业务数据后展示给用户，由此完成第二域的跨域访问。
本实施例通过将第二域的所有请求变成第一域的子域等相关域的请求，通过第一域的接入服务器带上第二域的认证串进行转发，完成跨域认证请求，使前端不存在跨域的问题，其实现形式灵活、通用性好且成本低。
下面以nginx接入服务器转发第二域的访问请求为例再次对本实施例方案进行详细阐述：
本实例使用nginx接入服务器转发请求，将第二域的所有请求变成第一域子域的请求，通过第一域的nginx带上skey进行转发，这样前端就不存在跨域的问题。详细过程如下：
如图2a所示，首先，用户通过浏览器、第一域的nginx向第一域业务服务器发送第一域的登录访问请求。
在第一域登录成功后，第一域业务服务器将认证通过后得到的skey（本实例以第一域与第二域具有相同的认证串进行举例）写入第一域cookie；
开发人员预先将所有原来访问第二域的请求的域名修改成第一域的子域（该子域只用于第二域的请求）；
浏览器将访问第二域的请求发送给第一域的nginx，第一域的nginx接收到请求后，通过域名匹配，判断为第二域的请求，将第一域cookie中的skey写入第二域的cooike中，将第二域的cooike携带在第二域的访问请求中转发至第二域业务服务器，完成跨域认证请求，
具体举例如下：
比如：第一域www.a.com需要请求带登录态的第二域地址www.b.com/xx/url.xhtml；用户登录后将skey写入www.a.com的cookie中，www.a.com的页面中本来请求第二域地址www.b.com/xx/url.xhtml，现在改请求为s.a.com/xx/url.xhtml，其中s.a.com为第二域请求专用子域，nginx收到请求后识别s.a.com为第二域的请求，将www.a.com的cookie中的skey写入www.b.com的cookie中，并请求www.b.com/xx/url.xhtml完成跨域认证请求。
另外，当第一域和第二域的skey不相同但可以置换时，该方案也可以支持，只需要在用户第一域登录成功后，第一域业务服务器向第二域业务服务器置换获取到第二域的skey，写入第一域的cookie，第一域的nginx在转发请求时，将第一域的cookie中的第二域的skey取出，写入第二域的cookie中转发请求即可，如图2b所示。
如前所述，第一域接入服务器判断是否为第二域的请求，除了用子域的方式，也可以是url带前缀（比如上边例子中可用www.a.com/p_b/xx/url.xhtml，其中p_b为第二域专用前缀）、后缀或者参数的方式，在此不再赘述。
本实施例通过上述方案，nginx通过第二域专用标识识别出第二域的请求，获取第一域cookie中的skey写到第二域的cookie里，转发到第二域，从而避开浏览器跨域及认证的问题，提高了跨越登录请求的灵活性、通用性，同时还可以降低成本。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质（如ROM/RAM、磁碟、光盘）中，包括若干指令用以使得一台终端设备（可以是手机，计算机，服务器，或者网络设备等）执行本发明各个实施例所述的方法。具体地，图3所述的实现跨域请求登录的浏览器所对应的程序指令可以存储在计算机等用户终端的可读存储介质中，并被其中的至少一个处理器执行，以实现图1、图3所述的实现跨域请求登录的方法。
以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (12)

1.一种实现跨域请求登录的方法，其特征在于，包括：
第一域业务服务器在浏览器登录第一域成功后，获取第二域的认证串并将其与第一域的认证串写入所述第一域的cookie，并将所述第一域的cookie发送给浏览器；
所述浏览器在接收到对第二域的访问请求时，将所述第二域的访问请求携带所述第一域的cookie发送给第一域接入服务器；所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域；
所述第一域接入服务器通过域名匹配识别到所述第一域的相关域中的所述第二域专用标识时，判断当前接收的请求为第二域的访问请求，从所述第一域的cookie中获取所述第二域的认证串，写入第二域的cookie，并将所述第二域的cookie携带在第二域的访问请求中转发至第二域业务服务器。
2.根据权利要求1所述的方法，其特征在于，所述第一域与第二域具有相同的认证串；第一域业务服务器在浏览器登录第一域成功后，获取第二域的认证串写入所述第一域的cookie的步骤包括：
所述第一域业务服务器在浏览器登录第一域成功后，将第一域登录认证后得到的认证串写入所述第一域的cookie。
3.根据权利要求1所述的方法，其特征在于，所述第一域的认证串与第二域的认证串不相同但可置换；所述第一域业务服务器在浏览器登录第一域成功后，获取第二域的认证串并将其与第一域的认证串写入所述第一域的cookie的步骤包括：
所述第一域业务服务器在浏览器登录第一域成功后，向第二域业务服务器置换获取第二域的认证串并将其与第一域的认证串写入所述第一域的cookie。
4.根据权利要求1、2或3所述的方法，其特征在于，所述将所述第二域的cookie携带在第二域的访问请求中转发至第二域业务服务器的步骤包括：
将所述第二域的访问请求的域名由带有第二域专用标识的第一域的相关域还原为第二域地址的访问请求；
将所述第二域的cookie携带在所述第二域地址的访问请求中转发至所述第二域业务服务器。
5.根据权利要求4所述的方法，其特征在于，所述带有第二域专用标识的第一域的相关域为带有第二域专用标识的第一域的子域；或者，所述带有第二域专用标识的第一域的相关域为携带有第二域专用前缀、后缀或相关参数的第一域的相关域。
6.一种实现跨域请求登录的方法，其特征在于，包括：
接收对第一域的访问请求，将所述第一域的访问请求经所述第一域接入服务器转发至第一域业务服务器；
在浏览器登录第一域成功后，接收所述第一域业务服务器返回的携带有第二域的认证串的第一域的cookie；
接收对第二域的访问请求，所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域；
将所述第二域的访问请求携带所述第一域的cookie发送给第一域接入服务器；由所述第一域接入服务器通过域名匹配识别到第二域的访问请求时，将所述第一域的cookie中的第二域的认证串写入第二域的cookie，携带在第二域的访问请求中转发至第二域业务服务器。
7.一种实现跨域请求登录的系统，其特征在于，包括：浏览器、第一域接入服务器、第一域业务服务器、至少一第二域业务服务器；
所述第一域业务服务器，用于在浏览器登录第一域成功后，获取第二域的认证串并将其与第一域的认证串写入所述第一域的cookie，并将所述第一域的cookie发送给浏览器；
所述浏览器，用于接收所述第一域业务服务器发送的所述第一域的cookie；在接收到对第二域的访问请求时，将所述第二域的访问请求携带所述第一域的cookie发送给所述第一域接入服务器；所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域；
所述第一域接入服务器，用于通过域名匹配识别到所述第一域的相关域中的所述第二域专用标识时，判断当前接收的请求为第二域的访问请求，从所述第一域的cookie中获取所述第二域的认证串，写入第二域的cookie，并将所述第二域的cookie携带在第二域的访问请求中转发至所述至少一第二域业务服务器。
8.根据权利要求7所述的系统，其特征在于，所述第一域与第二域具有相同的认证串；
第一域业务服务器，还用于在浏览器登录第一域成功后，将第一域登录认证后得到的认证串写入所述第一域的cookie。
9.根据权利要求8所述的系统，其特征在于，所述第一域的认证串与第二域的认证串不相同但可置换；
第一域业务服务器，还用于在浏览器登录第一域成功后，向第二域业务服务器置换获取第二域的认证串并将其与第一域的认证串写入所述第一域的cookie。
10.根据权利要求7、8或9所述的系统，其特征在于，
所述第一域接入服务器，还用于将所述第二域的访问请求的域名由带有第二域专用标识的第一域的相关域还原为第二域地址的访问请求；将所述第二域的cookie携带在所述第二域地址的访问请求中转发至所述第二域业务服务器。
11.根据权利要求10所述的系统，其特征在于，所述带有第二域专用标识的第一域的相关域为带有第二域专用标识的第一域的子域；或者，所述带有第二域专用标识的第一域的相关域为携带有第二域专用前缀、后缀或相关参数的第一域的相关域。
12.一种实现跨域请求登录的浏览器，其特征在于，包括：
第一转发模块，用于接收对第一域的访问请求，将所述第一域的访问请求经所述第一域接入服务器转发至第一域业务服务器；
接收模块，用于在浏览器登录第一域成功后，接收所述第一域业务服务器返回的携带有第二域的认证串的第一域的cookie；以及接收对第二域的访问请求，所述第二域的访问请求的域名预先修改为带有第二域专用标识的第一域的相关域；
第二转发模块，用于将所述第二域的访问请求携带所述第一域的cookie发送给第一域接入服务器；由所述第一域接入服务器通过域名匹配识别到第二域的访问请求时，将所述第一域的cookie中的第二域的认证串写入第二域的cookie，携带在第二域的访问请求中转发至第二域业务服务器。
CN201310378892.4A 2013-08-27 2013-08-27 实现跨域请求登录的方法、系统及浏览器 Active CN104426862B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201310378892.4A CN104426862B (zh) 2013-08-27 2013-08-27 实现跨域请求登录的方法、系统及浏览器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201310378892.4A CN104426862B (zh) 2013-08-27 2013-08-27 实现跨域请求登录的方法、系统及浏览器

Publications (2)

Publication Number Publication Date
CN104426862A CN104426862A (zh) 2015-03-18
CN104426862B true CN104426862B (zh) 2019-02-22

Family

ID=52974819

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201310378892.4A Active CN104426862B (zh) 2013-08-27 2013-08-27 实现跨域请求登录的方法、系统及浏览器

Country Status (1)

Country Link
CN (1) CN104426862B (zh)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105871976A (zh) * 2015-11-24 2016-08-17 乐视体育文化产业发展（北京）有限公司 数据跨域请求方法、设备及系统
CN108011859B (zh) * 2016-10-27 2021-08-10 珠海金山办公软件有限公司 一种登录不同一级应用的方法和服务器
CN106878408A (zh) * 2017-02-08 2017-06-20 福建天泉教育科技有限公司 跨域请求数据的方法及系统
CN107315784B (zh) * 2017-06-07 2020-01-31 北京奇艺世纪科技有限公司 一种数据访问方法和浏览器
CN109150796B (zh) * 2017-06-15 2022-02-22 阿里巴巴（中国）有限公司 数据访问方法和装置
CN107743134A (zh) * 2017-11-28 2018-02-27 湖北三新文化传媒有限公司 登录信息处理方法、客户端、服务器及存储介质
CN110209959B (zh) * 2018-02-11 2024-01-12 北京京东尚科信息技术有限公司 信息处理方法和装置
CN108769189B (zh) * 2018-05-28 2020-01-03 上海恺英网络科技有限公司 跨网络域资源的访问方法及设备
CN109218389B (zh) * 2018-07-05 2021-08-27 东软集团股份有限公司 处理业务请求的方法、装置和存储介质以及电子设备
CN110716850B (zh) * 2018-07-11 2022-05-06 腾讯科技（深圳）有限公司 页面测试方法、装置、系统及存储介质
CN111190743A (zh) * 2018-11-14 2020-05-22 千寻位置网络有限公司 一种解决前端本地开发跨域问题的方法和装置
CN110149336A (zh) * 2019-05-24 2019-08-20 深圳绿米联创科技有限公司 单点登录方法、装置以及信息系统
CN112491955B (zh) * 2020-10-23 2023-07-07 北京思特奇信息技术股份有限公司 一种基于代理服务器实现iframe系统数据交换的方法和系统
CN112383542B (zh) * 2020-11-12 2023-01-24 建信金融科技有限责任公司 一种用户登录的方法和系统、认证端以及用户端
CN113965357B (zh) * 2021-09-28 2023-10-17 网宿科技股份有限公司 跨域网站登录状态同步方法、电子设备及存储介质
CN114024751B (zh) * 2021-11-05 2023-05-23 抖音视界有限公司 一种应用访问控制方法、装置、计算机设备及存储介质
CN114448722B (zh) * 2022-03-15 2023-01-10 太平金融科技服务(上海)有限公司深圳分公司 跨浏览器登录方法、装置、计算机设备和存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101482882A (zh) * 2009-02-17 2009-07-15 阿里巴巴集团控股有限公司 跨域处理cookie的方法及其系统
CN102143091A (zh) * 2010-08-06 2011-08-03 华为技术有限公司 跨域操作的实现方法、系统、服务器和浏览器
WO2012050697A3 (en) * 2010-09-30 2012-07-19 Microsoft Corporation Securely rendering online ads in a host page
CN102682009A (zh) * 2011-03-11 2012-09-19 腾讯科技（北京）有限公司 一种用户登录网页的方法及系统
CN103023790A (zh) * 2012-12-31 2013-04-03 北京京东世纪贸易有限公司 一种用于实现跨域交互访问的方法和系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101482882A (zh) * 2009-02-17 2009-07-15 阿里巴巴集团控股有限公司 跨域处理cookie的方法及其系统
CN102143091A (zh) * 2010-08-06 2011-08-03 华为技术有限公司 跨域操作的实现方法、系统、服务器和浏览器
WO2012050697A3 (en) * 2010-09-30 2012-07-19 Microsoft Corporation Securely rendering online ads in a host page
CN102682009A (zh) * 2011-03-11 2012-09-19 腾讯科技（北京）有限公司 一种用户登录网页的方法及系统
CN103023790A (zh) * 2012-12-31 2013-04-03 北京京东世纪贸易有限公司 一种用于实现跨域交互访问的方法和系统

Also Published As

Publication number Publication date
CN104426862A (zh) 2015-03-18

Similar Documents

Publication Publication Date Title
CN104426862B (zh) 实现跨域请求登录的方法、系统及浏览器
CN102682009B (zh) 一种用户登录网页的方法及系统
US8898309B2 (en) Website monitoring and cookie setting
CN101997903B (zh) 用于处理超文本传输协议请求的方法和系统
US20180212963A1 (en) Method and apparatus for accessing website
CN101388773B (zh) 身份管理平台、业务服务器、统一登录系统及方法
CN104468592B (zh) 登录方法和登录系统
US20100064234A1 (en) System and Method for Browser within a Web Site and Proxy Server
CN110300133B (zh) 跨域数据传输方法、装置、设备及存储介质
US20110289138A1 (en) Method, machine and computer program product for sharing an application session across a plurality of domain names
US9699177B2 (en) Secure transfer of web application client persistent state information into a new domain
CN103428179A (zh) 一种登录多域名网站的方法、系统以及装置
CN104767614B (zh) 一种信息认证方法及装置
CN102185830B (zh) 一种网络电视浏览器安全过滤的方法及系统
CN103634111B (zh) 单点登录方法和系统及单点登录客户端
CN105787750A (zh) 信息推送方法及装置
CN103560884B (zh) 用户身份信息的注销方法、系统、认证服务器及客户端
EP3151514B1 (en) A method in a client-server network and client-server network
US10375141B2 (en) Method for processing URL and associated server and non-transitory computer readable storage medium
CN106919595A (zh) 一种用于Cookie映射的方法、装置及电子设备
CN110633432A (zh) 一种获取数据的方法、装置、终端设备及介质
KR101404764B1 (ko) 모바일 기기에서의 싱글 사인온 방법
CN105245446A (zh) 一种报文发送方法及网关
CN102918527B (zh) Web应用托管的调查方法和系统
EP3635581A1 (en) System and method for identifying and tagging users

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20190807

Address after: 518000 Nanshan District science and technology zone, Guangdong, Zhejiang Province, science and technology in the Tencent Building on the 1st floor of the 35 layer

Co-patentee after: Tencent cloud computing (Beijing) limited liability company

Patentee after: Tencent Technology (Shenzhen) Co., Ltd.

Address before: Shenzhen Futian District City, Guangdong province 518044 Zhenxing Road, SEG Science Park 2 East Room 403

Patentee before: Tencent Technology (Shenzhen) Co., Ltd.