WO2017045563A1 - 一种web app访问方法、装置和系统 - Google Patents
一种web app访问方法、装置和系统 Download PDFInfo
- Publication number
- WO2017045563A1 WO2017045563A1 PCT/CN2016/098388 CN2016098388W WO2017045563A1 WO 2017045563 A1 WO2017045563 A1 WO 2017045563A1 CN 2016098388 W CN2016098388 W CN 2016098388W WO 2017045563 A1 WO2017045563 A1 WO 2017045563A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- server
- web app
- file
- cloud
- token
- 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.)
- Ceased
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
Definitions
- the present application relates to the field of cloud computing technologies, and in particular, to a web app access method, apparatus, and system.
- a web app is an application that is accessed through a network (such as the Internet or an intranet); it can also mean that the computer software is hosted in a browser-supported environment or uses a browser-supported language (such as JavaScript, scripts) and relies on a web browser. Rendered application.
- the popularity of web apps is due to the popularity of web browsers and the user experience of using this thin and light client. Updates and maintenance can be implemented without having to download and install. It has the intrinsic properties of supporting cross-platform, which is the key reason why web apps are popular. Typical web app products include web mailboxes, web stores, wikis, and more. To implement the web app, the following key conditions must be met:
- the web app must provide an interface for the user to display data and user operations.
- Web apps developed by web app developers in the current technology are all developed based on server-local resources.
- it may develop the web app itself, and then deploy the web app on the first party's server for the user to access.
- the first party may not develop the web app by itself, but obtain a third-party developed web app from a third party, for example, the first party copies the complete web app package developed by the third party from the third party. It is then deployed on the first party's own server for user access.
- the user uploads and downloads data through the interface provided by the first party server, and uses the browser's cookie + server session to authenticate in the process, and the web app has high coupling. , can not be transplanted and reused.
- a web app access method including:
- the cloud interface of the cloud server is invoked to interact with the cloud server through the loaded web app file.
- a web app access device comprising:
- a document and a token obtaining module configured to obtain a webpage document for the web app and an authentication token from the first server
- a web app file loading module configured to load a web app file in the third server in the webpage document
- the cloud interaction module is configured to interact with the cloud server by using various cloud interfaces of the cloud server by using the loaded web app file based on the authentication token.
- a web app access system comprising:
- Client first server, third server, cloud server;
- the client includes:
- a document and a token obtaining module configured to obtain a webpage document for the web app and an authentication token from the first server
- a web app file loading module configured to load a web app file in the third server in the webpage document
- the cloud interaction module is configured to interact with the cloud server by using various cloud interfaces of the cloud server by using the loaded web app file based on the authentication token.
- the web app file that is developed by the third party and placed in the third server in the form of static text is provided, and is first by the first party.
- the server provides an authentication token for the client, so that the client user can click on the related functions of the web app in the webpage of the corresponding webpage document, so that the cloud server can be called with the webapp file after loading.
- the cloud interface interacts with the cloud server. therefore:
- the web app developed by the third party in the embodiment of the present application is stored in the third file because it can be static file.
- the user of the first server of any first party can simply load the web app in the domain name where the first server is located by using the first party webpage document, so that the first party client can use the web app.
- the web app is highly reusable, and the third party does not need to separately develop a web app for multiple first parties.
- the first party does not need to build a database and other servers for the web app, thereby reducing the cost of the first party device.
- the client uses the web app in its webpage, the client interacts with the cloud server through the authentication token given by the first server, and the client does not need the client cookie+server session authentication method when interacting with the cloud server.
- the web app's coupling low, it can be transplanted and reused flexibly.
- FIG. 1 is a flow chart showing the steps of an embodiment of a web app access method of the present application
- step 110 in the embodiment of the web application access method of FIG. 1;
- FIG. 3 is a preferred example of the step 120 in the embodiment of the web application access method in FIG. 1;
- FIG. 5 is a structural block diagram of an embodiment of a web app access device of the present application.
- FIG. 6 is a structural block diagram of an embodiment of a web app access system of the present application.
- a third party places a web app file developed by the third party in a third file in the form of a static file, and when the first server constructs a web page document, such as HTML (Hyper text Markup Language) , in the hypertext markup language), the code for loading the web app file is added to the HTML document, so that the client can obtain the HTML document for the web app from the first server and parse through the browser of the client.
- HTML Hyper text Markup Language
- the HTML document is loaded with the code of the web app file in the HTML document, the web app file is obtained from the third server for loading, and then rendered into the page of the browser, and the first server also assigns the identity verification to the client.
- the token so that the client can interact with the cloud server by calling various cloud interfaces of the cloud server through the loaded web app file based on the authentication token.
- the third-party web app of the embodiment of the present application has low coupling, which increases portability and reusability.
- FIG. 1 a flow chart of steps of an embodiment of a web app access method of the present application is shown. Including the following steps:
- Step 110 Obtain a webpage document for the web app and an authentication token from the first server.
- the client may access the first server, and obtain an HTML document for the web app from the first server.
- an authentication token can also be obtained from the first server.
- the user can input his identity information, such as a user name and password, in the login page displayed by the browser, and then the user can click on the login in the page, then the client browses.
- the device can obtain the HTML document corresponding to the web app as a web mailbox from the first server.
- the authentication token may use an STS token (Security Token Service token).
- STS token Security Token Service token
- other types of authentication tokens may also be used.
- the method before step 110, the method further includes:
- Step 101 In a primary account corresponding to the first server in the cloud server, allocate a sub-account and generate an original token for the sub-account;
- the cloud server can preset a set of account systems, such as RAM (Resource Access Management), and the first-party administrator can apply for a master account in the cloud server, and then in the master account.
- the sub-accounts of various rights are set below, so that the user of the sub-account can use the sub-account to perform management operations such as corresponding access to the resources of the main account according to their rights.
- the first account manager applies for a master account in the cloud server by using the account system, and the master account is applied to the first server.
- the primary account is then assigned a plurality of sub-accounts, and the original token is generated for the sub-account, such as AccessKeyId and AccessKeySecret, that is, the account and password of the sub-account of the login cloud server.
- the number of sub-accounts allocated in the primary account may be determined according to the number of client users, for example, according to the number of users registered in the first server using their webabb. It can be understood that the number of sub-accounts is greater than or equal to the number of client users. Preferably, the number of sub accounts is equal to the number of client users
- Step 102 The first server corresponds the identity information of the client user to a sub-account, and generates an identity verification token based on the original token.
- the first server of the embodiment of the present application corresponds to one sub-account of one client user, that is, one AccessKeyId and one accessKeySecret correspond to one sub-account.
- the embodiment of the present application generates an identity token based on the original token when the user accesses the foregoing HTML document, such as the foregoing STS token, and the STS token may be one for the client user. Access credentials with custom timeliness and access rights.
- the first server may look up the sub-account of the non-corresponding identity information recorded by the client, and the sub-account corresponds to the newly registered client.
- the identity information of the user and then the first server can invoke the STS API of the cloud server for the logged-in client user to generate an authentication token for the identity information of the client user based on the original token.
- the STS API such as AssumeRole, obtains a temporary identity for operating the sub-account through the interface.
- the AssumeRole includes the following parameters:
- the specified authorization policy The default length is limited to 1024 bytes, and the full identity of the temporary identity owned role returned is not specified.
- Expiration time range 900 to 3600, the default value is 3600.
- the step 110 includes:
- Sub-step 111 sending a webpage request for the web app to the first server; the webpage request includes identity information of the client user;
- Sub-step 112 receiving a webpage document for the web app returned by the first server, and receiving an authentication token returned by the first server for the identity information of the client user; wherein the first server is based on the identity of the client Information, obtaining an authentication token corresponding to the identity information.
- the first server puts the HTML document for the web app online, it corresponds to a web address, and the client user needs to enable the client to first send a webpage request for the web app, and the identity information is also The request is sent to the first server through the web page.
- the webpage request may be a login request.
- the client user first needs to open the login page in the client browser, and the login page does not load the webpage of the webmail. file. Then the user can fill in the identity information in the login page, such as the username and password of the client user, such as the username A123 and the password 123456. Then the user clicks login in the login page, then the client sends a login request to the first server. After receiving the login request, the first server verifies whether the username 123 and the password 123456 are correct; if correct, returns to the web app.
- Step 120 Load a web app file in the third server in the webpage document.
- the web app files developed by the third party include js (javascript, script) files and CSS (Cascading Style Sheets) files.
- the two files are respectively stored in the form of static text and a third-party server in the third party, and each file corresponds to a URL link.
- the first party when developing the HTML document code, it can add the corresponding script and CSS style code in its code according to the W3C (World Wide Web Consortium) standard, which can be the jab of webabb.
- the link of the file is added to the ⁇ script> tag of the HTML code, and the link style of the CSS file is linked in the tag ⁇ link>, and the pseudo code is as follows:
- the step 120 includes:
- Sub-step 121 loading the script file in the third server by using a link of the corresponding script file in the script tag ⁇ script> in the webpage document;
- Sub-step 122 loading the cascading style sheet file of the third server by a link of the corresponding cascading style sheet file in the style link tag ⁇ link> in the webpage document.
- the DOM Document Object Model
- the DOM Document Object Model
- the DOM node is Execution
- the js script is obtained from the third server for loading; for the aforementioned style link
- the link in the attribute "href" in the ⁇ link> tag is loaded from the third server to get the css file.
- the DOM tree is rendered as a page, and the web app is displayed as a page element in a web page of the first server.
- Step 130 Based on the identity verification token, the cloud interface of the cloud server is invoked to interact with the cloud server through the loaded web app file.
- step 120 after the client browser loads the web app file in the HTML document, the web app is presented in the web page in the form of a page element. Then, the user can perform various operations such as clicking, input, and the like in the webpage, and the various operations may need to interact with the cloud server to perform functions such as data transmission or downloading.
- the page may include an inbox, an outbox, a junk e-mail, a deleted e-mail, a sent e-mail, a write e-mail, etc.
- the user clicks on the e-mail in the webpage.
- the pop-up interface the user can enter the recipient's email address in the recipient field, you can enter the subject in the subject field, you can also click the add attachment button, add an attachment, you can click the send button to send,
- the web mailbox sends a request to the cloud server to call the cloud interface to store the mail under the sub-account corresponding to the username and password.
- the cloud storage interface can be called to send the mail to the mail server.
- the client browser when the client browser sends a request to the cloud server, it also needs to send the authentication token to the cloud server.
- the cloud server's account system such as RAM, verifies that the authentication token is correct. If it is correct, it is allowed to invoke the cloud interface to perform the above operations.
- the step 130 includes:
- Sub-step 131 initiating an interface call request to the cloud server by using the loaded web app file; the interface call request includes an identity verification token;
- the js file and the css file of the web app are loaded, the css file is used to render various buttons of the web app, and the js file is used to implement the logic of each control of the web app, when the user is in the web app area of the page.
- the js file will perform the corresponding operation. For example, if the user clicks to send an email, the logic of the js file initiates an interface call request to the cloud server, and at the same time, the identity STS token can be placed in the interface call request.
- Sub-step 132 verifying whether the authentication token is correct
- the cloud server After receiving the interface call request, the cloud server extracts the identity verification token, and verifies the identity verification token through the local authentication device of the RAM. If the verification is correct, the process proceeds to sub-step 133; if the verification is incorrect , the user is prompted to be wrong.
- Sub-step 133 if the authentication verification token is correct, allowing the interface to call the request to call the corresponding The cloud interface interacts.
- the request can invoke the corresponding interface of the cloud server to interact with the client.
- the foregoing email request may call an open storage service interface, such as an OSS (Object Storage Service) to store the mail in the outbox, and also store the mail to the cloud mail server.
- OSS Object Storage Service
- the cloud interface may include:
- Open structured data service interfaces such as Facebook Cloud's OTS, which is a NoSQL database service built on a distributed system that provides massively structured data storage and real-time access;
- Open search service interface such as OpenSearch, which supports document index structure customization, and free modification, supports automatic docking of cloud storage products, automatic data synchronization update, support for multi-table data push, and field text processing and conversion, such as in web mailboxes.
- the interface can be called by searching for a message;
- Open storage service interfaces such as OSS (Object Storage Service)
- OSS Object Storage Service
- users can upload and download data in any application, anytime, anywhere by calling the API, or simply by using the user's web console.
- Management, OSS is suitable for storing any file type.
- the web app file that is developed by the third party and placed in the third server in the form of static text is provided, and is first by the first party.
- the server provides an authentication token for the client, so that the client user can click on the related functions of the web app in the webpage of the corresponding webpage document, so that the cloud server can be called with the webapp file after loading.
- the cloud interface interacts with the cloud server.
- the first party web app service provider which may develop the web app itself, then deploy the web app on the first party's first server, and the first party from the first The third party, copying the complete web app package developed by the third party, and then deploying it on the first party's own third server, the embodiment of the present application has the following advantages:
- the web app developed by the third party in the embodiment of the present application can be stored in the third server in a static file manner, and the user of the first server of any first party can simply pass the web document of the first party.
- the web app is loaded in the domain where the server is located, so that the first party's client can use the full functionality of the web app.
- the web app is highly reusable, and the third party does not need to separately develop a web app for multiple first parties.
- the first party does not need to build a database and other servers for the web app, thereby reducing the cost of the first party device, and there is no cross. Domain problem.
- the client uses the web app in its webpage, the client interacts with the cloud server through the authentication token given by the first server, and the client does not need the client cookie+server session authentication method when interacting with the cloud server. , so that the web app has low coupling degree and can be flexibly transplanted and reused;
- the first server of the first party can provide an authentication token for the web application of the client, which is equivalent to the web application loaded in the authorized client browser can use the cloud resource corresponding to the first server, which is convenient for the first party.
- the management and control of privacy by a server is not easily obtained by a third party's third server.
- the first party provides a service plan for the user by jumping to the third server of the third party, since the first server of the first party is pure It only acts as a springboard, and all of the first-party first servers essentially use the same web app platform for users to access.
- the client still uses the browser cookie + server session to authenticate, the coupling is high, and the data from the transmission has cross-domain problems, and the implementation of the present application, for example, the foregoing process, has low coupling and does not exist.
- this method can not transplant the web app platform to each first-party server, so that each first-party server can have its own web app platform, and the web app of the present application can be arbitrarily transplanted to any
- the first party enables the first server of the first party to have its own web app platform; again, this way the browser cookie + server session is authenticated, and all its files are stored in the third server of the third party.
- the first server of the first party of the embodiment of the present application can provide an authentication token for the web application of the client, which is equivalent to authorizing the web loaded in the client browser.
- the app can use the cloud resource corresponding to the first server to facilitate the management and control of the first server of the first party, which is not light. Easy to be acquired by a third party's third server.
- FIG. 5 a structural block diagram of an embodiment of a web app access device of the present application is shown, which may specifically include the following modules:
- a document and token obtaining module 510 configured to obtain a webpage document for the web app and an authentication token from the first server
- a web app file loading module 520 configured to load a web app file in the third server in the webpage document;
- the cloud interaction module 530 is configured to interact with the cloud server by using various cloud interfaces of the cloud server by using the loaded web app file based on the identity verification token.
- the document and token obtaining module 510 includes:
- a webpage request sending module configured to send a webpage request for a web app to the first server; the webpage request includes identity information of the client user;
- a receiving module configured to receive a webpage document for the web app returned by the first server, and receive an authentication token returned by the first server for the identity information of the client user; wherein the first server is according to a client Identity information, obtaining an authentication token corresponding to the identity information.
- the method before the document and the token obtaining module 510, the method further includes:
- an identity allocation module configured to allocate a sub-account and generate an original token for the sub-account in a primary account of a corresponding first server in the cloud server;
- the first server includes: an authentication token generating module, configured to, by the first server, the identity information of the client user is in one-to-one correspondence with a sub-account, and generate an identity verification token based on the original token.
- the cloud interaction module 530 includes:
- An interface call request sending module is configured to initiate an interface call request to the cloud server by using the loaded web app file; the interface call request includes an identity verification token;
- An authentication token verification module configured to verify whether the authentication token is correct
- the calling module is allowed to allow the interface call request to invoke the corresponding cloud interface for interaction if the authentication verification token is correct.
- the web app file includes:
- the web app file loading module 520 includes:
- a script file loading module configured to load the script file in the third server by using a link of a corresponding script file in the script tag ⁇ script> in the webpage document;
- the cascading style sheet loading module is configured to load the cascading style sheet file of the third server by using a link of the corresponding cascading style sheet file in the style link tag ⁇ link> in the webpage document.
- an open structured service service interface In a preferred embodiment of the embodiments of the present application, one or more of an open structured service service interface, an open search service interface, and an open storage service interface are opened.
- FIG. 6 a structural block diagram of an embodiment of a web app access device of the present application is shown, which may specifically include the following modules:
- Client 610 first server 620, third server 630, cloud server 640;
- the client includes:
- a document and token obtaining module 611 configured to obtain a webpage document for the web app and an authentication token from the first server
- a web app file loading module 612 configured to load a web app file in the third server in the webpage document;
- the cloud interaction module 613 is configured to interact with the cloud server by using various cloud interfaces of the cloud server by using the loaded web app file based on the identity verification token.
- the first server 620 can include a first returning module, which can be used to return a webpage document for the web app and an authentication token according to the webpage request of the server.
- the third server 630 can be a second return module, which can be used to return the web app file to the client according to the loading request of the web application of the client.
- the cloud server 640 includes an interaction module that can be used to authenticate the client identity and interact with the client.
- the document and token obtaining module 611 includes:
- a webpage request sending module configured to send a webpage request for a web app to the first server; the webpage request includes identity information of the client user;
- a receiving module configured to receive a webpage document for the web app returned by the first server, and receive an authentication token returned by the first server for the identity information of the client user; wherein the first server is according to a client Identity information, obtaining an authentication token corresponding to the identity information.
- the method further includes:
- the cloud server 640 includes: an identity allocation module, configured to allocate a sub-account in the primary account of the corresponding first server in the cloud server, and generate an original token for the sub-account;
- the first server 620 includes: an authentication token generating module, configured to, by the first server, the identity information of the client user is in one-to-one correspondence with a sub-account, and generate an identity verification token based on the original token.
- the cloud interaction module 613 includes:
- An interface call request sending module is configured to initiate an interface call request to the cloud server by using the loaded web app file; the interface call request includes an identity verification token;
- An authentication token verification module configured to verify whether the authentication token is correct
- the calling module is allowed to allow the interface call request to invoke the corresponding cloud interface for interaction if the authentication verification token is correct.
- the web app file includes:
- the web app file loading module 612 includes:
- a script file loading module configured to load the script file in the third server by using a link of a corresponding script file in the script tag ⁇ script> in the webpage document;
- the cascading style sheet loading module is configured to load the cascading style sheet file of the third server by using a link of the corresponding cascading style sheet file in the style link tag ⁇ link> in the webpage document.
- the cloud interface includes one or more of an open structured data service interface, an open search service interface, and an open storage service interface.
- the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
- embodiments of the embodiments of the present application can be provided as a method, apparatus, or computer program product. Therefore, the embodiments of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Moreover, embodiments of the present application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
- computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
- the computer device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
- the memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory.
- RAM random access memory
- ROM read only memory
- Memory is an example of a computer readable medium.
- Computer readable media includes both permanent and non-persistent, removable and non-removable media.
- Information storage can be implemented by any method or technology. The information can be computer readable instructions, data structures, modules of programs, or other data.
- Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optics Storage, magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by computing devices.
- computer readable media does not include non-persistent computer readable media, such as modulated data signals and carrier waves.
- Embodiments of the present application are described with reference to flowcharts and/or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the present application. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG.
- These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor or other programmable data processing terminal device to produce a machine such that instructions are executed by a processor of a computer or other programmable data processing terminal device
- Means are provided for implementing the functions specified in one or more of the flow or in one or more blocks of the flow chart.
- the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
- the instruction device implements the functions specified in one or more blocks of the flowchart or in a flow or block of the flowchart.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本申请实施例提供了一种web app访问方法、装置和系统,涉及云计算技术领域。所述方法包括:从第一服务器中获取针对web app的网页文档以及身份验证令牌;在所述网页文档中加载第三服务器中的web app文件;基于所述身份验证令牌,通过加载后的web app文件调用云服务器的各种云接口与云服务器进行交互。本申请使webapp耦合度低,可以灵活移植和复用。
Description
本申请要求2015年09月17日递交的申请号为201510595357.3、发明名称为“一种web app访问方法、装置和系统”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
本申请涉及云计算技术领域,特别是涉及一种web app访问方法、装置和系统。
web app是一种通过网络(如互联网或内联网)访问的应用程序;也可以指计算机软件承载在浏览器支持环境下或使用浏览器支持语言(如JavaScript,脚本)并依赖于web浏览器来渲染的应用程序。web app的流行归功于网页浏览器的普及,以及使用这一轻薄客户端方便的用户体验。不必下载安装就可以实现更新和维护,具有支持跨平台的内在属性,是web app开始流行的关键原因。典型的web app产品包括web邮箱、web商店、wikis等等。要实现web app必须满足以下几点关键条件:
(1)用户交互。web app必须可以提供界面给用户进行数据展示和用户操作。
(2)数据交互。web app必须可以使用http协议通过互联网与web服务进行交互,如数据下载和上传
(3)安全保证。web app必须有能力识别用户身份和权限。
目前的技术中web app开发者开发的web app都是基于服务器本地的资源进行开发。对于第一方的web app服务提供者,其可能自身去开发web app,然后将该web app部署在第一方的服务器上,以供用户访问。
另外,对于第一方来说,其可能不自己开发web app,而是从第三方处获取第三方开发的web app,比如第一方从第三方处,拷贝第三方开发的完整web app包,然后部署在第一方自己的服务器上,以供用户访问。
但是,上述几种方案中,用户都是通过第一方的服务器提供的接口将数据进行上传和下载,在此过程中使用浏览器的cookie+服务器session的方式进行鉴权,web app的耦合性高、无法进行移植和复用。
发明内容
鉴于上述问题,提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种web app访问方法和相应的一种web app访问装置。
为了解决上述问题,本申请公开了一种web app访问方法,包括:
从第一服务器中获取针对web app的网页文档以及身份验证令牌;
在所述网页文档中加载第三服务器中的web app文件;
基于所述身份验证令牌,通过加载后的web app文件调用云服务器的各种云接口与云服务器进行交互。
还公开了一种web app访问装置,包括:
文档及令牌获取模块,用于从第一服务器中获取针对web app的网页文档以及身份验证令牌;
web app文件加载模块,用于在所述网页文档中加载第三服务器中的web app文件;
云交互模块,用于基于所述身份验证令牌,通过加载后的web app文件调用云服务器的各种云接口与云服务器进行交互。
还公开了一种web app访问系统,包括:
客户端、第一服务器、第三服务器、云服务器;
所述客户端包括:
文档及令牌获取模块,用于从第一服务器中获取针对web app的网页文档以及身份验证令牌;
web app文件加载模块,用于在所述网页文档中加载第三服务器中的web app文件;
云交互模块,用于基于所述身份验证令牌,通过加载后的web app文件调用云服务器的各种云接口与云服务器进行交互。
本申请实施例包括以下优点:
本申请实施例,由于第一方的第一服务器的网页文档中,提供了可加载由第三方开发的以静态文本形式放置于第三服务器中的web app文件,并且由第一方的第一服务器为客户端提供了身份验证令牌,从而客户端的用户可以在其对应网页文档中网页中,对web app的相关功能进行点击操作,从而可以与通过加载后的web app文件调用云服务器的各种云接口与云服务器进行交互。因此:
首先:本申请实施例第三方开发的web app由于可以静态文件的方式存储于其第三
服务器中,任意第一方的第一服务器的用户,可以简单的通过第一方的网页文档,在第一服务器所在的域名中加载该web app,使第一方的客户端即可使用web app的完整功能。使该web app可复用性高,第三方不用为多个第一方单独开发一个web app,第一方也不用为web app构建数据库等服务器,降低第一方的设备成本。
其次,客户端在其网页中使用web app时,客户端通过第一服务器给予的身份验证令牌与云服务器进行交互,客户端与云服务器进行交互时不需要客户端cookie+服务器session的鉴权方式,使web app的耦合度低,可以灵活移植和复用。
图1是本申请的一种web app访问方法实施例的步骤流程图;
图2是本申请对图1中一种web app访问方法实施例中步骤110的一种优选示例;
图3是本申请对图1中一种web app访问方法实施例中步骤120的一种优选示例;
图4是本申请对图1中一种web app访问方法实施例中步骤130的一种优选示例;
图5是本申请的一种web app访问装置实施例的结构框图;
图6是本申请的一种web app访问系统实施例的结构框图。
为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本申请作进一步详细的说明。
本申请实施例的核心构思之一在于,第三方将其开发的web app文件以静态文件的形式放置在其第三服务器中,而在第一服务器构建网页文档时,如HTML(Hyper text Markup Language,超文本标记语言)文档时,在HTML文档中加入加载所述web app文件的代码,从而客户端可以在从第一服务器获取到针对该web app的HTML文档后,通过客户端的浏览器解析所述HTML文档,通过HTML文档中加载所述web app文件的代码,从第三服务器中获取web app文件进行加载,然后渲染到浏览器的页面中,并且第一服务器还为该客户端分配身份验证令牌,从而可以使客户端基于所述身份验证令牌,通过加载后的web app文件调用云服务器的各种云接口与云服务器进行交互。使本申请实施例的第三方的web app的耦合性低,增加了移植性和可复用性。
参照图1,示出了本申请的一种web app访问方法实施例的步骤流程图,具体可以包
括如下步骤:
步骤110,从第一服务器中获取针对web app的网页文档以及身份验证令牌。
在本申请实施例中,客户端可以访问第一服务器,从第一服务器获取针对web app的HTML文档。
同时,还可以从第一服务器获取身份验证令牌。比如对于针对第一服务器中对应web app为web邮箱的HTML文档,用户可以在浏览器显示的登录页面中输入其身份信息,如用户名和密码,然后用户可在页面中点击登录,那么客户端浏览器即可从第一服务器获取该对应web app为web邮箱的HTML文档。并且可以接收第一服务器返回的针对该用户名和密码的身份验证令牌,该身份验证令牌为可通过云服务器认证的令牌。
在本申请实施例中该身份验证令牌可以采用STS token(Security Token Service token,安全令牌服务的令牌),当然,也可以采用其他类型的身份验证令牌。
在本申请实施例的一种优选实施例中,,在步骤110之前,还包括:
步骤101,在云服务器中的对应第一服务器的主账户内,分配子账户并为所述子账户生成原始令牌;
在实际应用中,在云服务器可以预置一套账户系统,如RAM(Resource Access Management,资源访问控制系统),第一方的管理人员可以在云服务器中申请一个主账户,然后在该主账户之下设置各种权限的子账户,使子账户的使用者可以采用该子账户对该主账户的资源按照其权限进行相应的访问等管理操作。
而本申请实施例中,则利用上述账户系统,由第一方的管理人员在云服务器中申请一个主账户,该主账户应用于第一服务器中。然后该主账户分配多个子账户,同时为该子账户生成原始令牌,该令牌如AccessKeyId和AccessKeySecret,即登录云服务器的该子账户的账户和密码。
需要说明的是,在主账户中分配的子账户的个数可以根据客户端用户的个数确定,比如根据在第一服务器中注册的使用其webabb的用户数确定。可以理解子账户的个数大于等于客户端用户的个数。优选地,子账户的个数等于客户端用户的个数
步骤102,所述第一服务器将客户端用户的身份信息与一子账户一一对应,并基于所述原始令牌生成身份验证令牌。
为了避免客户端用户a对客户端用户b的资源进行操作,本申请实施例的第一服务器将一个客户端用户对应一个子账户,即一个AccessKeyId和AccessKeySecret对应一个子账户。
然后,为了保证原始令牌的安全,本申请实施例则在用户访问前述HTML文档时,基于所述原始令牌生成身份令牌,如前述STS token,该STS token可为针对客户端用户的一个具备自定义时效和访问权限的访问凭证。
需要说明书的,对于客户端用户在第一服务器注册的身份信息,如用户名和密码,则第一服务器可以查找其记录的未对应身份信息的子账户,将该子账户对应该新注册的客户端用户的身份信息,然后第一服务器对于登录的客户端用户可以调用云服务器的STS API,基于所述原始令牌,生成针对客户端用户的身份信息的身份验证令牌。
其中,所述STS API比如AssumeRole,通过该接口,获取一个操作该子账户的临时身份。该AssumeRole包括如下参数:
1、请求参数:
(1)Action
类型:String
必须:是
描述:系统规定参数,取值:AssumeRole
(2)RoleArn
类型:String
必须:是
描述:指定角色的资源描述符
(3)RoleSessionName
类型:String
必须:是
描述:指定临时身份的会话名称,此参数用来区分不同的临时身份;建议使用您外部客户的ID。格式:^[a-zA-Z0-9\.@\-_]+$
(4)Policy
名称:Policy
类型:String
必须:否
描述:指定的授权策略。默认长度限制为1024字节,不指定则返回的临时身份拥有角色的完整权限。
(5)DurationSeconds
名称:DurationSeconds
类型:Integer
必须:否
描述:指定的过期时间,单位为秒。过期时间范围:900~3600,默认值为3600。
2、返回参数
(1)Credentials
类型:Credentials
描述:访问凭证
(2)AssumedRoleUser
类型:AssumedRoleUser
描述:角色扮演临时身份
当然,如果所有子账户都已经对应了一个身份信息,则可以登录云服务器以在其主账户之下在分配一个子账户,并生成AccessKeyId和AccessKeySecret,然后将该子账户记录到第一服务器中,并与该新注册的客户端用户的身份信息。
在本申请实施例的一种优选实施例中,参照图2,所述步骤110,包括:
子步骤111,向第一服务器发送针对web app的网页请求;所述网页请求中包括客户端用户的身份信息;
子步骤112,接收由第一服务器返回的针对web app的网页文档,以及接收第一服务器返回的针对所述客户端用户的身份信息的身份验证令牌;其中所述第一服务器根据客户端的身份信息,获取与所述身份信息对应的身份验证令牌。
在本申请实施例中,第一服务器将针对web app的HTML文档上线后,会以一个网址与之对应,客户端用户需要使客户端先发送针对web app的网页请求,并将其身份信息也通过该网页请求发送至服第一服务器。
在实际应用中,该网页请求可以为登录请求,比如对于前述针对web app为web邮箱的网页,客户端用户首先要在客户端浏览器打开登录页面,该登录页面并没有加载web邮箱的web app文件。然后用户可以在该登录页面中填入身份信息,如客户端用户的用户名和密码,如用户名为A123、密码为123456。然后用户在登录页面中点击登录,那么客户端则发送登录请求至第一服务器,第一服务器收到该登录请求后,先验证用户名123和密码123456是否正确;如果正确,则返回针对web app为web邮箱的HTML代码,并且,查找对应用户名123和密码123456的子账户,基于该子账户的原始令牌生成STS
stoken返回客户端浏览器。
步骤120,在所述网页文档中加载第三服务器中的web app文件。
在申请实施例中,第三方开发的web app文件包括js(javascript,脚本)文件和CSS(Cascading Style Sheets,级联样式表)文件。该两个文件分别以静态文本的形式存储与第三方的第三服务器中,每个文件对应一个网址链接。
而对于第一方来说,其在开发HTML文档代码时,则可以在其代码中按照W3C(World Wide Web Consortium,万维网联盟)标准,添加相应的脚本和CSS样式代码,其可以将webabb的js文件的链接加入到HTML代码的标签<script>中,将CSS文件的链接样式链接标签<link>中,其伪代码例如如:
在本申请实施例的一种优选实施例中,参照图3,所述步骤120,包括:
子步骤121,通过网页文档中的脚本标签<script>中的对应脚本文件的链接,加载第三服务器中的所述脚本文件;
子步骤122,通过网页文档中的样式链接标签<link>中的对应级联样式表文件的链接,加载第三服务器所述级联样式表文件。
如前述HTML文档的伪代码中,客户端浏览器获取到该HTML文档后,按照浏览器内核的逻辑,从HTML文档中解析DOM(Document Object Model,文档对象模型)树,对DOM节点中的内容进行执行,那么对于前述脚本标签<script>,则根据该标签的中的属性src中的链接,从第三服务器中获取js脚本进行加载;对于前述的样式链接
标签<link>中的属性“href”中的链接,从第三服务器中获取css文件进行加载。最终,将DOM树渲染为一个页面,那么web app则以页面元素的形式展现在第一服务器的一个网页中。
步骤130,基于所述身份验证令牌,通过加载后的web app文件调用云服务器的各种云接口与云服务器进行交互。
如步骤120中所述,客户端浏览器将HTML文档中的web app文件加载完之后,web app以页面元素的形式呈现在网页中。那么用户可以在该网页中进行点击、输入等各种操作,该各种操作则可能需要与云服务器进行交互,进行数据的传输或者下载等功能。
比如web app为web邮箱时,该页面中可包括收件箱、发件箱、垃圾邮箱、已删除邮件、已发送邮件、写邮件等按钮,以写邮件为例,用户在网页中点击写邮件,则在弹出写邮件的界面,用户可以在收件人一栏输入收件人的邮箱地址,在主题栏可以输入主题,还可以点击添加附件按钮,添加附件,可以点击发送按钮进行发送,则该web邮箱会向云服务器发送请求,以调用云接口将邮件存入该用户名和密码对应的子账户下。同时可调用云存储接口将邮件发送至邮件服务器。
可以理解,在客户端浏览器发送请求到云服务器时,其也需要把身份验证令牌发送至云服务器。云服务器的账户系统如RAM,则验证该身份验证令牌是否正确,如果正确,则允许其调用云接口,执行上述操作。
优选的,参照图4,所述步骤130,包括:
子步骤131,通过加载后的web app文件向云服务器发起接口调用请求;所述接口调用请求包括身份验证令牌;
在实际应用中,加载的是web app的js文件和css文件,css文件用于渲染web app的各种按钮,js文件用于实现web app的各个控件的逻辑,当用户在页面的web app区域内,点击各种按钮,则js则执行相应操作。比如前述,用户点击发送邮件,则js文件的逻辑则向云服务器发起接口调用请求,同时,可将身份STS token放入该接口调用请求中。
子步骤132,验证所述身份验证令牌是否正确;
云服务器接收到该接口调用请求后,则从中提取身份验证令牌,通过RAM本地的认证装置,对该身份验证令牌进行验证,如果验证为正确,则进入子步骤133;如果验证为不正确,则提示用户身份错误。
子步骤133,如果所述身份验证验证令牌正确,则允许所述接口调用请求调用相应
云接口进行交互。
在身份验证令牌通过后,则该请求即可调用云服务器的相应接口与客户端进行交互。比如前述发邮件的请求,其可以调用开放存储服务接口,如OSS(Object Storage Service,云对象存储)将邮件存储到发件箱,同时还可以将该邮件存储到云邮件服务器。
在本申请实施例中,不同的web app功能可能调用不同的云接口进行不同的交互。其中,所述云接口可包括:
开放结构化数据服务接口,如阿里云的OTS,OTS是构建在分布式系统之上的NoSQL数据库服务,提供海量结构化数据的存储和实时访问;
开放搜索服务接口,如OpenSearch,其支持文档索引结构定制,以及自由修改,支持云存储产品的自动对接,数据自动同步更新,支持多表数据推送,及字段文本处理和转换等,如在web邮箱中搜索邮件就可以调用该接口;
开放存储服务接口,如OSS(Object Storage Service,云对象存储),用户可以通过调用API,在任何应用、任何时间、任何地点上传和下载数据,也可以通过用户客户端的Web控制台对数据进行简单的管理,OSS适合存放任意文件类型。
当然,在实际应用中,web app的不同功能调用不同的云接口,不受限于上述的云接口。
本申请实施例,由于第一方的第一服务器的网页文档中,提供了可加载由第三方开发的以静态文本形式放置于第三服务器中的web app文件,并且由第一方的第一服务器为客户端提供了身份验证令牌,从而客户端的用户可以在其对应网页文档中网页中,对web app的相关功能进行点击操作,从而可以与通过加载后的web app文件调用云服务器的各种云接口与云服务器进行交互。
因此相对于目前的技术中,第一方的web app服务提供者,其可能自身去开发web app,然后将该web app部署在第一方的第一服务器上的方案,和第一方从第三方处,拷贝第三方开发的完整web app包,然后部署在第一方自己的第三服务器上的方案,本申请实施例具备如下优点:
1、本申请实施例第三方开发的web app由于可以静态文件的方式存储于其第三服务器中,任意第一方的第一服务器的用户,可以简单的通过第一方的网页文档,在第一服务器所在的域名中加载该web app,使第一方的客户端即可使用web app的完整功能。使该web app可复用性高,第三方不用为多个第一方单独开发一个web app,第一方也不用为web app构建数据库等服务器,降低第一方的设备成本,并且不存在跨域问题。
2、客户端在其网页中使用web app时,客户端通过第一服务器给予的身份验证令牌与云服务器进行交互,客户端与云服务器进行交互时不需要客户端cookie+服务器session的鉴权方式,使web app的耦合度低,可以灵活移植和复用;
3、第一方的第一服务器,可以为客户端的web app提供身份验证令牌,相当于授权客户端浏览器中加载的web app可以使用第一服务器对应的云资源,方便第一方的第一服务器对隐私的管理和控制,不轻易被第三方的第三服务器获取。
另外,相对于第三方开发完整的web app放在第三方的第三服务器上,第一方通过跳转到第三方的第三服务器为用户提供服务的方案,由于第一方的第一服务器纯粹只是起到一个跳板的作用,其所有的第一方的第一服务器本质上都采用的同一个web app平台,以供用户访问。该种方式客户端来说,其还是采用的浏览器cookie+服务器session的方式进行鉴权,耦合性高,并且数据从传输存在跨域问题,而本申请实施例如前述过程,耦合性低,不存在跨域问题;其次,该种方式不能将web app平台移植到各个第一方的服务器上,使各个第一方的服务器可以有自己的web app平台,而本申请的web app可以任意移植到任意第一方,使第一方的第一服务器可以拥有自己的web app平台;再次,该种方式浏览器cookie+服务器session的方式进行鉴权,并且其所有的文件都存储于第三方的第三服务器中,无法统一对第一服务器的隐私进行管理,而本申请实施例的第一方的第一服务器,可以为客户端的web app提供身份验证令牌,相当于授权客户端浏览器中加载的web app可以使用第一服务器对应的云资源,方便第一方的第一服务器对隐私的管理和控制,不轻易被第三方的第三服务器获取。
需要说明的是,对于方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请实施例并不受所描述的动作顺序的限制,因为依据本申请实施例,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作并不一定是本申请实施例所必须的。
参照图5,示出了本申请的一种web app访问装置实施例的结构框图,具体可以包括如下模块:
文档及令牌获取模块510,用于从第一服务器中获取针对web app的网页文档以及身份验证令牌;
web app文件加载模块520,用于在所述网页文档中加载第三服务器中的web app文件;
云交互模块530,用于基于所述身份验证令牌,通过加载后的web app文件调用云服务器的各种云接口与云服务器进行交互。
在本申请实施例的一种优选实施例中,所述文档及令牌获取模块510,包括:
网页请求发送模块,用于向第一服务器发送针对web app的网页请求;所述网页请求中包括客户端用户的身份信息;
接收模块,用于接收由第一服务器返回的针对web app的网页文档,以及接收第一服务器返回的针对所述客户端用户的身份信息的身份验证令牌;其中所述第一服务器根据客户端的身份信息,获取与所述身份信息对应的身份验证令牌。
在本申请实施例的一种优选实施例中,在文档及令牌获取模块510之前,还包括:
在云服务器中包括:身份分配模块,用于在云服务器中的对应第一服务器的主账户内,分配子账户并为所述子账户生成原始令牌;
在第一服务器中包括:身份验证令牌生成模块,用于所述第一服务器将客户端用户的身份信息与一子账户一一对应,并基于所述原始令牌生成身份验证令牌。
在本申请实施例的一种优选实施例中,所述云交互模块530,包括:
接口调用请求发送模块,用于通过加载后的web app文件向云服务器发起接口调用请求;所述接口调用请求包括身份验证令牌;
身份验证令牌验证模块,用于验证所述身份验证令牌是否正确;
允许调用模块,用于如果所述身份验证验证令牌正确,则允许所述接口调用请求调用相应云接口进行交互。
在本申请实施例的一种优选实施例中,所述web app文件包括:
web app的脚本文件和级联样式表文件。
在本申请实施例的一种优选实施例中,所述web app文件加载模块520包括:
脚本文件加载模块,用于通过网页文档中的脚本标签<script>中的对应脚本文件的链接,加载第三服务器中的所述脚本文件;
级联样式表加载模块,用于通过网页文档中的样式链接标签<link>中的对应级联样式表文件的链接,加载第三服务器所述级联样式表文件。
在本申请实施例的一种优选实施例中,开放结构化数据服务接口,开放搜索服务接口,开放存储服务接口中的一个或者多个。
参照图6,示出了本申请的一种web app访问装置实施例的结构框图,具体可以包括如下模块:
客户端610、第一服务器620、第三服务器630、云服务器640;
所述客户端包括:
文档及令牌获取模块611,用于从第一服务器中获取针对web app的网页文档以及身份验证令牌;
web app文件加载模块612,用于在所述网页文档中加载第三服务器中的web app文件;
云交互模块613,用于基于所述身份验证令牌,通过加载后的web app文件调用云服务器的各种云接口与云服务器进行交互。
其中,该第一服务器620可包括第一返回模块,可用于根据服务器的网页请求返回针对web app的网页文档以及身份验证令牌。
该第三服务器630可第二返回模块,可用于根据客户端的web app的加载请求,返回web app文件至客户端。
云服务器640包括交互模块,可用于认证客户端身份和与客户端交互。
在本申请实施例的一种优选实施例中,所述文档及令牌获取模块611,包括:
网页请求发送模块,用于向第一服务器发送针对web app的网页请求;所述网页请求中包括客户端用户的身份信息;
接收模块,用于接收由第一服务器返回的针对web app的网页文档,以及接收第一服务器返回的针对所述客户端用户的身份信息的身份验证令牌;其中所述第一服务器根据客户端的身份信息,获取与所述身份信息对应的身份验证令牌。
在本申请实施例的一种优选实施例中,还包括:
在云服务器640中包括:身份分配模块,用于在云服务器中的对应第一服务器的主账户内,分配子账户并为所述子账户生成原始令牌;
在第一服务器620中包括:身份验证令牌生成模块,用于所述第一服务器将客户端用户的身份信息与一子账户一一对应,并基于所述原始令牌生成身份验证令牌。
在本申请实施例的一种优选实施例中,所述云交互模块613,包括:
接口调用请求发送模块,用于通过加载后的web app文件向云服务器发起接口调用请求;所述接口调用请求包括身份验证令牌;
身份验证令牌验证模块,用于验证所述身份验证令牌是否正确;
允许调用模块,用于如果所述身份验证验证令牌正确,则允许所述接口调用请求调用相应云接口进行交互。
在本申请实施例的一种优选实施例中,所述web app文件包括:
web app的脚本文件和级联样式表文件。
在本申请实施例的一种优选实施例中,所述web app文件加载模块612包括:
脚本文件加载模块,用于通过网页文档中的脚本标签<script>中的对应脚本文件的链接,加载第三服务器中的所述脚本文件;
级联样式表加载模块,用于通过网页文档中的样式链接标签<link>中的对应级联样式表文件的链接,加载第三服务器所述级联样式表文件。
在本申请实施例的一种优选实施例中,所述云接口包括:开放结构化数据服务接口,开放搜索服务接口,开放存储服务接口中的一个或者多个。
对于装置实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白,本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此,本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
在一个典型的配置中,所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学
存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非持续性的电脑可读媒体(transitory media),如调制的数据信号和载波。
本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上,使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请实施例的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例做出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对本申请所提供的一种web app访问方法、一种web app访问装置和一种web app访问系统,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。
Claims (15)
- 一种web app访问方法,其特征在于,包括:从第一服务器中获取针对web app的网页文档以及身份验证令牌;在所述网页文档中加载第三服务器中的web app文件;基于所述身份验证令牌,通过加载后的web app文件调用云服务器的各种云接口与云服务器进行交互。
- 根据权利要求1所述的方法,其特征在于,所述从第一服务器中获取针对web app的网页文档以及身份验证令牌的步骤,包括:向第一服务器发送针对web app的网页请求;所述网页请求中包括客户端用户的身份信息;接收由第一服务器返回的针对web app的网页文档,以及接收第一服务器返回的针对所述客户端用户的身份信息的身份验证令牌;其中所述第一服务器根据客户端的身份信息,获取与所述身份信息对应的身份验证令牌。
- 根据权利要求2所述的方法,其特征在于,在从第一服务器中获取针对web app的网页文档以及身份验证令牌的步骤之前,还包括:在云服务器中的对应第一服务器的主账户内,分配子账户并为所述子账户生成原始令牌;所述第一服务器将客户端用户的身份信息与一子账户一一对应,并基于所述原始令牌生成身份验证令牌。
- 根据权利要求3所述的方法,其特征在于,所述基于所述身份验证令牌,通过加载后的web app文件调用云服务器的各种云接口与云服务器进行交互的步骤,包括:通过加载后的web app文件向云服务器发起接口调用请求;所述接口调用请求包括身份验证令牌;验证所述身份验证令牌是否正确;如果所述身份验证验证令牌正确,则允许所述接口调用请求调用相应云接口进行交互。
- 根据权利要求1至4中任一项所述的方法,其特征在于,所述web app文件包括:web app的脚本文件和级联样式表文件。
- 根据权利要求5所述的方法,其特征在于,所述在所述网页文档中加载第三服 务器中的web app文件的步骤包括:通过网页文档中的脚本标签<script>中的对应脚本文件的链接,加载第三服务器中的所述脚本文件;通过网页文档中的样式链接标签<link>中的对应级联样式表文件的链接,加载第三服务器所述级联样式表文件。
- 根据权利要求1所述的方法,其特征在于,所述云接口包括:开放结构化数据服务接口,开放搜索服务接口,开放存储服务接口中的一个或者多个。
- 一种web app访问装置,其特征在于,包括:文档及令牌获取模块,用于从第一服务器中获取针对web app的网页文档以及身份验证令牌;web app文件加载模块,用于在所述网页文档中加载第三服务器中的web app文件;云交互模块,用于基于所述身份验证令牌,通过加载后的web app文件调用云服务器的各种云接口与云服务器进行交互。
- 根据权利要求8所述的装置,其特征在于,所述文档及令牌获取模块,包括:网页请求发送模块,用于向第一服务器发送针对web app的网页请求;所述网页请求中包括客户端用户的身份信息;接收模块,用于接收由第一服务器返回的针对web app的网页文档,以及接收第一服务器返回的针对所述客户端用户的身份信息的身份验证令牌;其中所述第一服务器根据客户端的身份信息,获取与所述身份信息对应的身份验证令牌。
- 根据权利要求9所述的装置,其特征在于,在文档及令牌获取模块之前,还包括:在云服务器中包括:身份分配模块,用于在云服务器中的对应第一服务器的主账户内,分配子账户并为所述子账户生成原始令牌;在第一服务器中包括:身份验证令牌生成模块,用于所述第一服务器将客户端用户的身份信息与一子账户一一对应,并基于所述原始令牌生成身份验证令牌。
- 根据权利要求10所述的装置,其特征在于,所述云交互模块,包括:接口调用请求发送模块,用于通过加载后的web app文件向云服务器发起接口调用请求;所述接口调用请求包括身份验证令牌;身份验证令牌验证模块,用于验证所述身份验证令牌是否正确;允许调用模块,用于如果所述身份验证验证令牌正确,则允许所述接口调用请求调 用相应云接口进行交互。
- 根据权利要求8至11中任一项所述的装置,其特征在于,所述web app文件包括:web app的脚本文件和级联样式表文件。
- 根据权利要求12所述的装置,其特征在于,所述web app文件加载模块包括:脚本文件加载模块,用于通过网页文档中的脚本标签<script>中的对应脚本文件的链接,加载第三服务器中的所述脚本文件;级联样式表加载模块,用于通过网页文档中的样式链接标签<link>中的对应级联样式表文件的链接,加载第三服务器所述级联样式表文件。
- 根据权利要求8所述的装置,其特征在于,所述云接口包括:开放结构化数据服务接口,开放搜索服务接口,开放存储服务接口中的一个或者多个。
- 一种web app访问系统,其特征在于,包括:客户端、第一服务器、第三服务器、云服务器;所述客户端包括:文档及令牌获取模块,用于从第一服务器中获取针对web app的网页文档以及身份验证令牌;web app文件加载模块,用于在所述网页文档中加载第三服务器中的web app文件;云交互模块,用于基于所述身份验证令牌,通过加载后的web app文件调用云服务器的各种云接口与云服务器进行交互。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510595357.3A CN106549907B (zh) | 2015-09-17 | 2015-09-17 | 一种web app访问方法、装置和系统 |
| CN201510595357.3 | 2015-09-17 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2017045563A1 true WO2017045563A1 (zh) | 2017-03-23 |
Family
ID=58288137
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2016/098388 Ceased WO2017045563A1 (zh) | 2015-09-17 | 2016-09-08 | 一种web app访问方法、装置和系统 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN106549907B (zh) |
| WO (1) | WO2017045563A1 (zh) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108322461A (zh) * | 2018-01-31 | 2018-07-24 | 百度在线网络技术(北京)有限公司 | 应用程序自动登录的方法、系统、装置、设备和介质 |
| CN110929183A (zh) * | 2018-08-31 | 2020-03-27 | 阿里巴巴集团控股有限公司 | 一种数据处理方法、装置和机器可读介质 |
| CN111159615A (zh) * | 2019-12-31 | 2020-05-15 | 北大方正集团有限公司 | 网页处理方法和装置 |
| CN111314454A (zh) * | 2020-02-12 | 2020-06-19 | 深圳市信锐网科技术有限公司 | 应用的访问方法、装置、电子设备及存储介质 |
| CN112492017A (zh) * | 2020-11-24 | 2021-03-12 | 航天信息股份有限公司 | 一种基于token认证的websocket连接方法及系统 |
| CN115577200A (zh) * | 2022-09-28 | 2023-01-06 | 北京百度网讯科技有限公司 | 加载页面的方法、装置、设备以及存储介质 |
| CN116028921A (zh) * | 2023-01-03 | 2023-04-28 | 重庆长安汽车股份有限公司 | 一种用户权限控制方法、装置、电子设备及存储介质 |
| CN116932951A (zh) * | 2022-04-08 | 2023-10-24 | 北京沃东天骏信息技术有限公司 | 页面的生成方法、系统、客户端以及服务端 |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107678820B (zh) * | 2017-09-29 | 2021-08-24 | 北京金山安全软件有限公司 | 网页处理方法、装置、服务器、终端设备和介质 |
| CN108170574B (zh) * | 2017-12-25 | 2021-04-20 | 深圳Tcl新技术有限公司 | 一种网址信息处理方法及装置 |
| CN108616499B (zh) * | 2018-03-02 | 2021-01-26 | 努比亚技术有限公司 | 一种应用程序的鉴权方法、终端和计算机可读存储介质 |
| CN111309399A (zh) * | 2020-02-26 | 2020-06-19 | 北京思特奇信息技术股份有限公司 | 一种启用易问原生客户端的方法、系统、介质及设备 |
| CN111581628B (zh) * | 2020-05-13 | 2023-04-28 | 广州市百果园信息技术有限公司 | 令牌获取方法、装置、设备及存储介质 |
| CN113377853A (zh) * | 2021-06-19 | 2021-09-10 | 吉萨特自动化技术(上海)有限公司 | 一种车间移动信息分析平台及方法 |
| CN114257441B (zh) * | 2021-12-17 | 2023-12-15 | 北京字跳网络技术有限公司 | 一种基于云文档组件的数据处理方法及装置 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110154187A1 (en) * | 2009-12-21 | 2011-06-23 | Domainer Inc. | Methods, software and devices for providing server hosted web applications |
| CN102239680A (zh) * | 2011-03-09 | 2011-11-09 | 华为技术有限公司 | Web应用托管方法及装置 |
| CN104348777A (zh) * | 2013-07-24 | 2015-02-11 | 腾讯科技(深圳)有限公司 | 一种移动终端对第三方服务器的访问控制方法及系统 |
| CN104395884A (zh) * | 2012-03-09 | 2015-03-04 | 谷歌公司 | 用于网页应用程序和浏览器扩展的数据存储层级 |
| CN104468592A (zh) * | 2014-12-12 | 2015-03-25 | 北京百度网讯科技有限公司 | 登录方法和登录系统 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6973483B2 (en) * | 2000-09-30 | 2005-12-06 | Microsoft Corporation | System and method for using dynamic web components to automatically customize web pages |
| CN101132413B (zh) * | 2007-09-18 | 2010-10-06 | 中兴通讯股份有限公司 | 基于Web应用的ActiveX组件的复用方法 |
| CN101924740A (zh) * | 2009-06-10 | 2010-12-22 | 纬创资通股份有限公司 | 通过网页提供服务的方法及其系统 |
| CN101599015B (zh) * | 2009-07-07 | 2013-07-03 | 阿里巴巴集团控股有限公司 | 一种组件解析的方法和系统 |
| CN102420873B (zh) * | 2011-12-06 | 2014-06-11 | 肇庆全商联盟信息科技有限公司 | 复合网络全新云应用平台 |
-
2015
- 2015-09-17 CN CN201510595357.3A patent/CN106549907B/zh active Active
-
2016
- 2016-09-08 WO PCT/CN2016/098388 patent/WO2017045563A1/zh not_active Ceased
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110154187A1 (en) * | 2009-12-21 | 2011-06-23 | Domainer Inc. | Methods, software and devices for providing server hosted web applications |
| CN102239680A (zh) * | 2011-03-09 | 2011-11-09 | 华为技术有限公司 | Web应用托管方法及装置 |
| CN104395884A (zh) * | 2012-03-09 | 2015-03-04 | 谷歌公司 | 用于网页应用程序和浏览器扩展的数据存储层级 |
| CN104348777A (zh) * | 2013-07-24 | 2015-02-11 | 腾讯科技(深圳)有限公司 | 一种移动终端对第三方服务器的访问控制方法及系统 |
| CN104468592A (zh) * | 2014-12-12 | 2015-03-25 | 北京百度网讯科技有限公司 | 登录方法和登录系统 |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108322461A (zh) * | 2018-01-31 | 2018-07-24 | 百度在线网络技术(北京)有限公司 | 应用程序自动登录的方法、系统、装置、设备和介质 |
| CN108322461B (zh) * | 2018-01-31 | 2020-10-27 | 百度在线网络技术(北京)有限公司 | 应用程序自动登录的方法、系统、装置、设备和介质 |
| CN110929183A (zh) * | 2018-08-31 | 2020-03-27 | 阿里巴巴集团控股有限公司 | 一种数据处理方法、装置和机器可读介质 |
| CN110929183B (zh) * | 2018-08-31 | 2024-04-09 | 斑马智行网络(香港)有限公司 | 一种数据处理方法、装置和机器可读介质 |
| CN111159615A (zh) * | 2019-12-31 | 2020-05-15 | 北大方正集团有限公司 | 网页处理方法和装置 |
| CN111159615B (zh) * | 2019-12-31 | 2024-01-02 | 新方正控股发展有限责任公司 | 网页处理方法和装置 |
| CN111314454A (zh) * | 2020-02-12 | 2020-06-19 | 深圳市信锐网科技术有限公司 | 应用的访问方法、装置、电子设备及存储介质 |
| CN112492017A (zh) * | 2020-11-24 | 2021-03-12 | 航天信息股份有限公司 | 一种基于token认证的websocket连接方法及系统 |
| CN116932951A (zh) * | 2022-04-08 | 2023-10-24 | 北京沃东天骏信息技术有限公司 | 页面的生成方法、系统、客户端以及服务端 |
| CN115577200A (zh) * | 2022-09-28 | 2023-01-06 | 北京百度网讯科技有限公司 | 加载页面的方法、装置、设备以及存储介质 |
| CN115577200B (zh) * | 2022-09-28 | 2024-04-23 | 北京百度网讯科技有限公司 | 加载页面的方法、装置、设备以及存储介质 |
| CN116028921A (zh) * | 2023-01-03 | 2023-04-28 | 重庆长安汽车股份有限公司 | 一种用户权限控制方法、装置、电子设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN106549907B (zh) | 2019-10-11 |
| CN106549907A (zh) | 2017-03-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106549907B (zh) | 一种web app访问方法、装置和系统 | |
| Subramanian et al. | Hands-On RESTful API Design Patterns and Best Practices: Design, develop, and deploy highly adaptable, scalable, and secure RESTful web APIs | |
| US10621329B2 (en) | Mobile application, resource management advice | |
| US8966572B2 (en) | Dynamic identity context propagation | |
| US9648043B2 (en) | Services within reverse proxy servers | |
| US20190317757A1 (en) | Deployment of infrastructure in pipelines | |
| JP5998284B2 (ja) | エンタプライズシステムへのアプリケーションの動的登録 | |
| US8341239B2 (en) | Method and system for providing runtime vulnerability defense for cross domain interactions | |
| AU2015256293B2 (en) | Facilitating single sign-on to software applications | |
| US10348713B2 (en) | Pluggable authentication for enterprise web application | |
| US20160359861A1 (en) | Accessing an application through application clients and web browsers | |
| US20150012616A1 (en) | Saving Third Party Content to a Content Management System | |
| CN107690792A (zh) | 未经管理的移动设备的单点登录 | |
| CN104283875A (zh) | 云盘权限管理方法 | |
| US10333979B1 (en) | Multi-tenant network data validation service | |
| CN106104546B (zh) | 提供多级密码和网络钓鱼保护 | |
| CN107315948B (zh) | 数据调用方法及装置 | |
| CN107239475B (zh) | 一种调用文件方法及装置 | |
| CN103905477B (zh) | 一种处理http请求的方法及服务器 | |
| US20230128002A1 (en) | Policy enforcement and visibility by open apis | |
| Gurturk | Building Serverless Architectures | |
| AU2018390863A1 (en) | Computer system and method for extracting dynamic content from websites | |
| Schill | CERN-Solid code investigation | |
| Freeman | Authenticating API Clients | |
| Gumus et al. | ASP. NET Core 2 Fundamentals: Build cross-platform apps and dynamic web services with this server-side web application framework |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 16845677 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 16845677 Country of ref document: EP Kind code of ref document: A1 |
