Single sign-on method and device, and corresponding equipment, medium and product

Abstract

Provided are a single sign-on (SSO) method and device, and corresponding equipment, medium and product. The method comprises: in response to receiving a login request of a user sent by an application program of a first version on a first client device, generating a one-time password for the user, the first client device not having a browser or having a browser that cannot be used for the application program; in response to receiving an access token sent by the application program of a second version on a second client device supporting browser functions, storing the access token; in response to receiving a password acquisition request sent by the application program of the second version, providing the one-time password to the application program of the second version for output; and in response to receiving the one-time password sent by the application program of the first version, sending the stored access token to the application program of the first version. With the scheme of the application, web SSO functions can be used for non-web application programs to implement identity verification and login.

Description

Technical Field

[0001] This invention relates to the field of user authentication and application login technology, and more specifically, to Single Sign-On (SSO) methods and apparatus, and corresponding computer equipment, storage media and program products. Background Technology

[0002] For login to web applications, authentication can be performed using an external user agent (the device's browser). In some cases, such as for non-web applications like WeChat mini-programs, mobile device browsers are not suitable. In other cases, for other non-web applications on mobile devices, although authentication can be performed via a browser, the mobile device's browser may be unusable for various reasons. If the mobile device's browser is unavailable or inaccessible, how to authenticate and log in for non-web applications becomes a problem. Integrating the non-web application with the mobile device's browser is an option for non-web applications that do not support browsers, but this requires additional effort. Summary of the Invention

[0003] The purpose of this invention is to provide an improved single sign-on solution to address the aforementioned problems.

[0004] According to a first aspect of the present invention, a single sign-on method for a service provider is provided, comprising:

[0005] In response to receiving a login request from a user from a first version of the application on a first client device, a one-time password is generated for the user, wherein the first client device does not have a browser, or the browser on the first client device is not usable for the first version of the application;

[0006] In response to receiving an access token sent by the second version of the application on a second client device that supports browser functionality, the access token is stored;

[0007] In response to receiving a password retrieval request from the second version of the application on the second client device, the one-time password is provided to the second version of the application for output;

[0008] In response to receiving the one-time password sent by the first version of the application on the first client device, the stored access token is sent to the first version of the application.

[0009] According to a second aspect of the present invention, a single sign-on device for a service provider is provided, comprising a processor configured to:

[0010] In response to receiving a login request from a user from a first version of the application on a first client device, a one-time password is generated for the user, wherein the first client device does not have a browser, or the browser on the first client device is not usable for the first version of the application;

[0011] In response to receiving an access token sent by the second version of the application on a second client device that supports browser functionality, the access token is stored;

[0012] In response to receiving a password retrieval request from the second version of the application on the second client device, the one-time password is provided to the second version of the application for output;

[0013] In response to receiving the one-time password sent by the first version of the application on the first client device, the stored access token is sent to the first version of the application.

[0014] According to a third aspect of the present invention, a computer device is provided, including a memory and a processor, wherein computer instructions are stored in the memory, and the computer instructions, when executed by the processor, cause a method according to a first aspect of the present invention to be performed.

[0015] According to a fourth aspect of the invention, a non-transitory computer-readable storage medium is provided, on which computer instructions are stored, which, when executed by a processor, cause the method according to a first aspect of the invention to be performed.

[0016] According to a fifth aspect of the present invention, a computer program product is provided, comprising computer instructions that, when executed by a processor, cause a method according to a first aspect of the present invention to be performed.

[0017] Using the solution of this invention, non-web applications can achieve user authentication and login without relying on the browser of the client device, without having to make additional efforts to integrate the non-web application with the device browser and without having to make any changes to the authorization server. Attached Figure Description

[0018] Non-limiting and non-exhaustive embodiments of the invention are described by way of example with reference to the following figures, wherein:

[0019] Figure 1 This illustration schematically demonstrates a prior art method for logging into a non-web application using a browser;

[0020] Figure 2A single sign-on method according to an embodiment of the present invention is illustrated schematically;

[0021] Figure 3 This is a block diagram schematically illustrating a single sign-on device according to an embodiment of the present invention;

[0022] Figure 4 This is a schematic diagram illustrating an example embodiment of the present invention. Detailed Implementation

[0023] To make the above and other features and advantages of the present invention clearer, the invention is further described below in conjunction with the accompanying drawings. The drawings form a part of this application and, together with the embodiments of the invention, serve to illustrate the invention. For clarity and simplicity, detailed descriptions of the known functions and structures of the devices, apparatuses, and / or equipment described herein will be omitted where they might obscure the subject matter of the invention. It should be understood that the specific embodiments given herein are for the purpose of explanation to those skilled in the art and are exemplary only, not restrictive.

[0024] The features described herein may be embodied in different forms and should not be construed as being limited to the embodiments described herein. Rather, the embodiments described herein are provided merely to illustrate some of the many possible ways of implementing the apparatus and / or system described herein, which will become apparent upon understanding the disclosure of this application.

[0025] As used herein, the term “and / or” includes any one of the associated listed items and any combination of any two or more of the associated listed items.

[0026] Although terms such as “first,” “second,” and “third” may be used herein to describe various components, parts, sections, or elements, these components, parts, sections, or elements are not limited by these terms. Rather, these terms are used only to distinguish one component, part, section, or element from another. Therefore, without departing from the teachings of the invention, a first component, part, section, or element referred to herein may also be referred to as a second component, part, section, or element.

[0027] The terminology used herein is for describing various embodiments only and is not intended to limit the scope of this disclosure. Unless the context clearly indicates otherwise, "a," "an," and "the" are intended to also include plural forms. The terms "comprising," "including," and "having" specify the presence of the stated features, operations, components, elements, and / or combinations thereof, but do not exclude the presence or addition of one or more other features, operations, components, elements, and / or combinations thereof.

[0028] In the following description, numerous specific details are set forth to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that these specific details are not required to practice the invention. In other instances, well-known steps or operations have not been described in detail to avoid obscuring the invention.

[0029] Before describing the scheme of this application, let's introduce some concepts.

[0030] OAuth 2.0

[0031] OAuth 2.0 is an open standard for authorization that allows users to authorize third-party applications to access specific information stored by a user on a service provider without having to provide the user's username and password to the third-party application.

[0032] OAuth 2.0 includes several roles: client, user agent, resource owner, authorization server, and resource server.

[0033] Resource owner: An entity that can grant access to protected resources (such as user data); when the resource owner is a person, it can be called an end user.

[0034] Resource server: A server that hosts protected resources (such as user data) and can authorize or deny requests for protected resources based on the access token provided by the client.

[0035] Client: An application that represents the resource owner and is authorized by them to make a request for protected resources; it can be a web application, mobile application, desktop application, etc.

[0036] User agent: This is typically the browser used by the resource owner; the resource owner uses the user agent to enable the client to communicate with the authorization server.

[0037] Authorization server: After successfully verifying the resource owner and obtaining authorization, the authorization server issues an access token (and optional refresh token) to the client; the authorization server and the resource server can be the same server or separate servers; a single authorization server can issue tokens accepted by multiple resource servers.

[0038] The basic workflow of OAuth 2.0 is as follows:

[0039] 1. The client requests (guides) user authorization;

[0040] 2. The user agrees to the authorization, and an authorization code is returned;

[0041] 3. The client requests authorization from the authorization server using the authorization code from step 2;

[0042] 4. The authorization server verifies the authorization code. If the verification is successful, it grants the authorization and returns an access token for resource access.

[0043] 5. The client requests the relevant resources from the resource server using the access token obtained in step 4;

[0044] 6. The resource server verifies the access token. Once verification is successful, it returns the resource requested by the client.

[0045] Single Sign-On

[0046] A company may have more than one application. If each application requires registration and login, the user experience will be poor. A better login experience is one where multiple services under a company only require one registration and one login.

[0047] Single Sign-On (SSO) is a popular solution for enterprise business integration. SSO allows users to access multiple trusted applications, such as all applications under an enterprise, by logging in only once.

[0048] In an SSO system, there is typically a central identity provider (IdP) that all associated service providers (SPs) rely on for user authentication. Service providers generally refer to organizations or individuals that provide information or services to the public through an information network. These services include, but are not limited to, network services, information services, and technical intermediary services.

[0049] There are several ways to implement SSO, among which the most common ones include technologies based on SAML (Security Assertion Markup Language), OAuth 2.0, OpenID Connect, etc.

[0050] 1. OAuth 2.0

[0051] As mentioned above, OAuth 2.0 is an open standard for authorization that allows users to authorize third-party applications to access specific information stored by a user on a service provider without having to provide the user's username and password to the third-party application.

[0052] Implementation steps:

[0053] User accessing the application: The user attempts to access a protected resource.

[0054] Redirect to the authorization server: The application redirects the user to the authorization server to request authorization.

[0055] User authorization: Users log in to the authorization server and authorize applications to access their resources.

[0056] Issuing an access token: The authorization server issues an access token to the application.

[0057] Application requests resources: The application uses an access token to request a protected resource.

[0058] Returning Resources: The resource server returns the requested resources to the application.

[0059] 2. OpenID Connect (OIDC)

[0060] OpenID Connect is built on top of OAuth 2.0 and adds an authentication layer for identity verification.

[0061] Implementation steps:

[0062] User accessing the application: The user attempts to access a protected resource.

[0063] Redirect to Authorization Server: The application redirects the user to the OpenID Connect provider.

[0064] User Login: Users log in to the OpenID Connect provider.

[0065] Issuing ID tokens and access tokens: The provider issues ID tokens (for authentication) and / or access tokens (for accessing resources).

[0066] Application requests resource: The application uses an access token to request a protected resource.

[0067] Returning Resources: The resource server returns the requested resources to the application.

[0068] 3.SAML (Security Assertion Markup Language)

[0069] SAML is an XML-based standard used for exchanging authentication and authorization data over the Internet.

[0070] Implementation steps:

[0071] User accessing the application: The user attempts to access a protected resource.

[0072] Redirect to Identity Provider: The application redirects users to a SAML identity provider.

[0073] User login: Users log in to the identity provider.

[0074] Issuing a SAML response: The identity provider generates a SAML response containing the user's authentication information.

[0075] Application validates SAML response: The application validates the SAML response and uses the information therein to authenticate the user.

[0076] Accessing resources: The user is redirected back to the application and can access protected resources.

[0077] refer to Figure 1This illustration schematically depicts a prior art method for logging into a client application using a browser. The method involves: a user; a user device, a client application, and a web application running in a browser that can run on the user device; a service provider; and an authorization server. The user device can be a mobile device or a desktop device, and the client application can correspondingly be a mobile application or a desktop application, which is a non-web application that authenticates and logs in by means of a web application running in a browser. The method includes the following steps: 1. The user requests to sign in from the client application; 2. The client application sends an authorization request to a web application running in a browser; 3. The web application running in the browser sends the authorization request to an authorization server; 4. The authorization server requests authentication from the web application running in the browser; 5. The user signs in at the web application running in the browser; 6. The web application running in the browser provides user credentials to the authorization server; 7. The authorization server sends an authorization code to the web application running in the browser; 8. The web application running in the browser sends the authorization code to the client application; 9. The client application sends the authorization code to the authorization server; 10. The authorization server sends an access token and an optional refresh token to the client application; 11. The client application sends a request with an access token to the service provider, such as an access request. In response, the service provider may provide the client application with the information and / or service (not shown) requested in the access request.

[0078] Figure 1 The OAuth 2.0 scheme requires the use of a user agent, such as a browser, to complete user authentication and login, which may impose limitations in non-web applications. For example, in an enterprise, there may be a variety of applications, such as web applications, non-web applications, mobile applications, and desktop applications. In some cases, the browser functionality of a user's device may be unavailable for various reasons. In other cases, mobile device browsers may not be suitable. For example, it is currently known that mobile device browsers are not compatible with WeChat Mini Programs, which essentially determines that the OAuth 2.0 scheme is not feasible for WeChat Mini Programs.

[0079] To address the aforementioned issues, this application proposes a single sign-on scheme that enables non-web applications to perform user authentication and login without relying on the browser of the client device they reside on, thus enabling them to utilize web applications.

[0080] refer to Figure 2 This paper illustrates a single sign-on method 200 according to an embodiment of the present invention. The method 200 can be implemented by a service provider and is suitable for single sign-on for non-web applications. The method 200 may include steps S201-S204, and can be implemented by an apparatus according to an embodiment of the present invention (hereinafter referred to as...). Figure 3 (Description) to execute.

[0081] In step S201, at the service provider, in response to receiving a login request from a user from a first version of the application on the first client device, a one-time password (OTP) is generated for the user, wherein the first client device does not have a browser, or the browser on the first client device is unusable for the first version of the application. Here, the first version of the application is associated with the service provider, for example, the service provider provides information and / or services to it in response to a request from the first version of the application. "The browser on the first client device is unusable for the first version of the application" should be understood to encompass various possible situations where the first client device has a browser but its browser cannot be used by the first version of the application, including, but not limited to, the following: the first version of the application itself is not compatible with a browser, resulting in the browser on the first client device being unusable by the first version of the application; the browser on the first client device is unusable by the first version of the application for various other reasons (e.g., network connection problems, browser settings problems, firewall and security software settings, etc.). A one-time password is a password that can only be used once and can be generated in various suitable ways; this application does not limit this. For example, an unpredictable combination of random numbers can be generated as a one-time password at regular intervals (e.g., 60 seconds) according to a specific algorithm. The service provider can generate suitable one-time passwords as needed and based on actual circumstances. The application in the first version can be a non-web application; the login request can be issued by the user via the non-web application running on the first client device. In one embodiment, the first client device is a mobile device. In another embodiment, the first client device is a desktop device. According to the invention, when a user requests to log in to a non-web application on a client device that does not have a browser or whose browser is unusable for the non-web application, the login request is sent to the service provider as a trigger to generate a one-time password for the current user, rather than redirecting to an authorization server.

[0082] In response to a user requesting to log in to a non-web application on a client device where the client device does not have a browser or the browser on the client device is unusable for the non-web application, the non-web application may present the user with a first prompt requesting a one-time password. The first prompt may be presented in various possible forms; this application is not limited in this regard. For example, in one embodiment, the first prompt is presented in text form on the user interface of the non-web application running on the first client device. In addition to the content requesting a one-time password, the first prompt may also include other possible content, such as content related to guiding the user to obtain the one-time password; this application is not limited in this regard. For example, the first prompt may include content requesting login to another version of the corresponding application to obtain a one-time password, and / or content requesting the user to enter a one-time password in the non-web application running on the first client device. In one embodiment, the other version of the corresponding application may be a web application on another platform corresponding to the non-web application running on the first client device.

[0083] In step S202, at the service provider, in response to receiving an access token sent by the second version of the application on a second client device that supports browser functionality, the access token is stored.

[0084] In step S203, at the service provider, in response to receiving a password retrieval request from the second version of the application on the second client device, the one-time password is provided to the second version of the application for output. The output one-time password can then be presented to the user.

[0085] The access token may be provided by an authorization server associated with the service provider to a second version of the application on the second client device. The provision of the access token by the authorization server may be triggered by the user issuing another login request via a second version of the application on a browser-enabled second client device; this can be implemented in various possible ways, and this application is not limited thereto. As an example, see the following section... Figure 4The description of steps 5-12 in the above. In one embodiment, the first client device is a mobile device and the second client device is a desktop device. In another embodiment, the first client device is a desktop device and the second client device is a mobile device. The second version of the application may be a web application. In one embodiment, after presenting the user with a first prompt requesting a one-time password for the first version of the application (which is a non-web application), the user logs in to the corresponding web application running on the second client device via a browser-enabled second client device and issues a password retrieval request. The user logs in to the web application running on the second client device via a browser-enabled second client device, as described above. Figure 1 The described process is similar, with the exception that: a web application running on a browser-enabled second client device sends an authorization code to an authorization server; the authorization server sends an access token and an optional refresh token to the web application running on the browser-enabled second client device; the web application then sends the obtained access token and optional refresh token to the service provider; and the obtained access token and optional refresh token are then stored at the service provider. In one embodiment, the non-web application and the web application are two different versions of the same application for desktop and mobile platforms, respectively. The one-time password can be output and presented to the user in various suitable ways. For example, in one embodiment, the one-time password is presented as text on the user interface of the web application running on the second client device.

[0086] In step S204, at the service provider, in response to receiving the one-time password sent by the first version of the application on the first client device, the stored access token is sent to the first version of the application. This enables login to the first version of the application, allowing the user to log in. In one embodiment, the first version of the application is a non-web application; the one-time password is entered by the user via the non-web application running on the first client device.

[0087] In this regard, upon receiving a one-time password from the first version of the application on the first client device, the service provider can verify the received one-time password and, if the verification is successful, send the stored access token to the first version of the application. In one embodiment, after successful verification of the one-time password, the service provider sends the stored access token and an optional refresh token to a non-web application running on the first client device; thereafter, the user can issue a request with the access token, such as an access request, via the non-web application running on the first client device.

[0088] refer to Figure 3 A single sign-on device 301 according to an embodiment of the present invention is shown. The device 301 may be included within or otherwise made available to a service provider 300. The device 301 may be configured to perform one or more of the operations described above in conjunction with the method of the present invention.

[0089] Figure 4 An example embodiment of the invention is illustrated schematically. Figure 4 In this context, the following are involved: a user; a first user device; a second user device; a service provider; and an authorization server. The first client device lacks browser functionality and is suitable for running non-web applications; the second client device possesses browser functionality and is suitable for running web applications. Below, we will discuss... Figure 4 The steps in the process are described.

[0090] In step 1, the user requests to log in to a non-web application running on the first client device using a username; in step 2, the login request for the username is sent by the non-web application to the service provider; in step 3, the non-web application outputs a first prompt requesting a one-time password to be provided to the user; in step 4, in response to receiving the login request from the non-web application, the service provider generates a one-time password (OTP) for the user with the username; in step 5, the user requests to log in to the corresponding web application running on the second client device, which runs in a browser.

[0091] Figure 4 Steps 6-10 in the text correspond to respectively Figure 1 Steps 3-7 in the previous steps will not be repeated here; regarding Figure 4 Steps 6-10 in the above text can be referred to. Figure 1 The description of steps 3-7 in the text.

[0092] Next, in step 11, the web application running on the second client device sends the authorization code to the authorization server; in step 12, the authorization server sends the access token and an optional refresh token to the web application running on the second client device; in step 13, the web application running on the second client device saves the obtained access token and optional refresh token and sends them to the service provider; in step 14, in response to receiving the access token and optional refresh token sent by the web application running on the second client device, the service provider saves the received access token and optional refresh token and confirms receipt of the access token and optional refresh token to the web application running on the second client device; in step 15, the user logs into the web application running on the second client device; in step 16, the user sends a request to the web application running on the second client device to view the OTP password; in step 17, the user sends a request to the service provider via the web application running on the second client device to obtain the OTP password; in step 18, in response to... Upon receiving a password retrieval request from a web application running on a second client device, the service provider provides the generated one-time password to the web application running on the second client device for output; in step 19, the web application running on the second client device outputs the one-time password for presentation to the user; in step 20, the user enters the one-time password via a non-web application running on the first client device; in step 21, a login request with the one-time password is sent to the service provider; in response to receiving the one-time password from the non-web application running on the first client device, the service provider executes steps 22 and 23, wherein, in step 22, the service provider verifies the one-time password, and in step 23, after successful verification of the one-time password, the service provider sends a saved access token and an optional refresh token to the non-web application running on the first client device; in step 24, the user logs in to the non-web application running on the first client device; in step 25, a request with the access token is sent to the service provider for access.

[0093] exist Figure 4Although the first client device and the second client device are shown as different client devices, this invention is not limited thereto. According to the invention, it is possible for the first client device and the second client device to be the same device. For example, it is possible that a non-web application itself is not compatible with a browser, causing the browser on the client device to be unusable by the non-web application. In this case, the first client device and the second client device can be the same client device, and the non-web application can use a corresponding web application on the same client device to perform authentication and login.

[0094] Those skilled in the art should understand that Figure 3 The schematic diagrams shown are merely exemplary illustrative block diagrams of some elements related to the solutions of the present invention and do not constitute a limitation on the computer device, processor, or computer program embodying the solutions of the present invention. Specific computer devices, processors, or computer programs may include more or fewer components or modules than shown in the figures, or may combine or split certain components or modules, or may have different arrangements of components or modules.

[0095] In one embodiment, a computer device is provided, comprising a memory and a processor. The memory stores computer instructions executable by the processor, which, when executed by the processor, instruct the processor to perform various steps of the method of the present invention. The computer device can be broadly categorized as a server or any other electronic device with the necessary computing and / or processing capabilities. In one embodiment, the computer device may include a processor, memory, network interface, communication interface, etc., connected via a system bus. The processor of the computer device can be used to provide the necessary computing, processing, and / or control capabilities. The memory of the computer device may include a non-volatile storage medium and internal memory. The non-volatile storage medium may store an operating system, computer programs, etc. The internal memory can provide an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface and communication interface of the computer device can be used to connect and communicate with external devices via a network. When the computer program is executed by the processor, it performs various steps of the method of the present invention.

[0096] This invention can be implemented as a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, causes the steps of the method of the invention to be performed. In one embodiment, the computer program is distributed across multiple network-coupled computer devices or processors, such that the computer program is stored, accessed, and executed in a distributed manner by one or more computer devices or processors. A single method step / operation, or two or more method steps / operations, may be executed by a single computer device or processor or by two or more computer devices or processors. One or more method steps / operations may be executed by one or more computer devices or processors, and one or more other method steps / operations may be executed by one or more other computer devices or processors. One or more computer devices or processors may execute a single method step / operation, or execute two or more method steps / operations.

[0097] It will be understood by those skilled in the art that all or part of the operation of the methods of the present invention can be performed by a computer program instructing related hardware, such as a computer device or processor, which may be stored in a non-transitory computer-readable storage medium. When the computer program is executed, it causes the operation of the methods of the present invention to be performed. Depending on the context, any references herein to memory, storage, database, or other media may include non-volatile and / or volatile memory. Examples of non-volatile memory include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, etc. Examples of volatile memory include random access memory (RAM), external cache memory, etc. The technical features described above can be combined arbitrarily.

[0098] The technical features described above can be combined arbitrarily. Although not all possible combinations of these technical features are described, any combination of these technical features should be considered to be covered by this specification, provided that such combination does not contain contradictions.

[0099] Although the invention has been described in conjunction with embodiments, those skilled in the art will understand that the above description and drawings are exemplary and not restrictive, and the invention is not limited to the disclosed embodiments. Various modifications and variations are possible without departing from the spirit of the invention.

Claims

1. A single sign-on method for a service provider, comprising: In response to receiving a login request from a user from a first version of the application on a first client device, a one-time password is generated for the user, wherein the first client device does not have a browser, or the browser on the first client device is not usable for the first version of the application; In response to receiving an access token sent by the second version of the application on a second client device that supports browser functionality, the access token is stored; In response to receiving a password retrieval request from the second version of the application on the second client device, the one-time password is provided to the second version of the application for output; In response to receiving the one-time password sent by the first version of the application on the first client device, the stored access token is sent to the first version of the application.

2. The method according to claim 1, further comprising: In response to receiving an access request including the access token sent by the first version of the application on the first client device, the information and / or services requested by the access request are provided to the first version of the application.

3. The method according to claim 1 or 2, wherein, The first version of the application and the second version of the application are respectively the non-web version and the web version of the application.

4. The method according to claim 3, wherein, The non-web version of the application and the web version of the application are two different versions of the application for mobile platforms and desktop platforms, respectively.

5. A single sign-on device for a service provider, comprising a processor configured to: In response to receiving a login request from a user from a first version of the application on a first client device, a one-time password is generated for the user, wherein the first client device does not have a browser, or the browser on the first client device is not usable for the first version of the application; In response to receiving an access token sent by the second version of the application on a second client device that supports browser functionality, the access token is stored; In response to receiving a password retrieval request from the second version of the application on the second client device, the one-time password is provided to the second version of the application for output; In response to receiving the one-time password sent by the first version of the application on the first client device, the stored access token is sent to the first version of the application.

6. The apparatus according to claim 5, wherein, The processor is configured to: In response to receiving an access request including the access token sent by the first version of the application on the first client device, the information and / or services requested by the access request are provided to the first version of the application.

7. The apparatus according to claim 5 or 6, wherein, The first version of the application and the second version of the application are respectively the non-web version and the web version of the application.

8. The apparatus according to claim 7, wherein, The non-web version of the application and the web version of the application are two different versions of the application for mobile platforms and desktop platforms, respectively.

9. A computer device comprising a memory and a processor, the memory storing computer instructions that, when executed by the processor, cause the method according to any one of claims 1-4 to be performed.

10. A non-transitory computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, cause the method according to any one of claims 1-4 to be performed.

11. A computer program product comprising computer instructions that, when executed by a processor, cause the method according to any one of claims 1-4 to be performed.

Images