CN113569219A

CN113569219A - Live broadcast embedded program authorization method, device, equipment and storage medium

Info

Publication number: CN113569219A
Application number: CN202110888161.9A
Authority: CN
Inventors: 吴全贵
Original assignee: Guangzhou Fanxing Huyu IT Co Ltd
Current assignee: Guangzhou Fanxing Huyu IT Co Ltd
Priority date: 2021-08-03
Filing date: 2021-08-03
Publication date: 2021-10-29

Abstract

The application discloses a live broadcast embedded program authorization method, a live broadcast embedded program authorization device, live broadcast embedded program authorization equipment and a storage medium, and belongs to the technical field of networks. In the embodiment of the application, the authorization service of the live broadcast embedded program is provided for the live broadcast application, and when the account of the live broadcast application starts the live broadcast embedded program in the live broadcast application, the authorization request can be sent to request generation of an authorization token of the account for the live broadcast embedded program so as to complete authorization of the account for the live broadcast embedded program, so that the account can obtain data service of the live broadcast embedded program subsequently. The authorization token provides the authority of the account for the live broadcast embedded program instead of the authority of the account for the live broadcast application, the authorization of the live broadcast embedded program is independent of the authorization of the live broadcast application, fine-grained authorization is achieved, the account is managed better, the fact that the live broadcast embedded program obtains relevant information of a user without authorization is avoided, privacy disclosure is caused, and data security is improved better.

Description

Live broadcast embedded program authorization method, device, equipment and storage medium

Technical Field

The present application relates to the field of network technologies, and in particular, to a live broadcast embedded program authorization method, apparatus, device, and storage medium.

Background

With the development of network technology, live broadcasting becomes a popular content distribution mode. The anchor can register an account number on the live broadcast application and start the live broadcast. In the live broadcast process, the live broadcast platform can be provided with some live broadcast embedded programs, and the live broadcast embedded programs are downloaded and used by the main broadcast account number so as to activate the atmosphere of a live broadcast room. For example, the live embedded program may be a mini-game embedded program.

The live broadcast embedded program is based on live broadcast application, namely, a background server of the live broadcast application can provide data service for live broadcast application during live broadcast, the live broadcast embedded program can be installed in the live broadcast application, the live broadcast embedded program can be started in the live broadcast process, and then some operations and the like are executed in the live broadcast embedded program. The live embedded program is started and run by the live application and is provided in the live application when the live application runs.

The account of the live application can install a live embedded program in the live application and start the live embedded program in the live application. However, when the live broadcast embedded program is started, the live broadcast embedded program may acquire account information of the account, so as to provide data services required by the service, that is, the problem of authorization of the live broadcast embedded program by the account is involved.

Disclosure of Invention

The embodiment of the application provides a live broadcast embedded program authorization method, a live broadcast embedded program authorization device, live broadcast embedded program authorization equipment and a storage medium, and data security is improved. The technical scheme is as follows:

in one aspect, a live embedded program authorization method is provided, and the method includes:

receiving a starting request of an account of a live broadcast application to a live broadcast embedded program, wherein the starting request carries an identifier of the live broadcast embedded program;

responding to the starting request, and sending an authorization request to the account based on the identification of the live broadcast embedded program and the account information of the account;

in response to receiving authorization confirmation information sent by the account in response to the authorization request, generating an authorization token of the account for the live broadcast embedded program based on the identification of the live broadcast embedded program and the account information of the account;

and sending the authorization token to the account.

In some embodiments, the sending an authorization request to the account based on the identity of the live embedded program and the account information of the account includes:

acquiring information of the live broadcast embedded program based on the identification of the live broadcast embedded program;

acquiring account information of the account;

generating an authorization request of the account for the live broadcast embedded program based on the information of the live broadcast embedded program and the account information of the account;

and sending the authorization request to the account.

In some embodiments, the method further comprises:

receiving a service interface calling request of an account of a live broadcast application to the live broadcast embedded program, wherein the service interface calling request carries an authorization token of the account to the live broadcast embedded program and an interface identifier for requesting calling;

verifying the account number for the authorization token of the live broadcast embedded program;

and responding to the account number to pass the verification of the authorization token of the live broadcast embedded program, and calling an interface corresponding to the interface identifier.

In some embodiments, the verifying the account number against the authorization token of the live embedded program includes:

verifying that the account number is valid for an authorization token of the live broadcast embedded program;

the responding to the account number to pass the verification of the authorization token of the live broadcast embedded program, and calling the interface corresponding to the interface identifier, including:

and responding to the account number to be valid for the authorization token of the live broadcast embedded program, and executing the step of calling the interface corresponding to the interface identifier.

In some embodiments, the method further comprises at least one of:

responding to the account number that the authorization token of the live broadcast embedded program is invalid, and sending an expiration prompt of the authorization token to the account number;

and responding to the account being invalid to the authorization token of the live broadcast embedded program, and sending an authorization request to the account based on the identification of the live broadcast embedded program and the account information of the account.

In some embodiments, after generating the authorization token of the account for the live embedded program based on the identification of the live embedded program and the account information of the account, the method further includes:

caching authorization information of the account for the live broadcast embedded program, wherein the authorization information comprises an authorization token of the account for the live broadcast embedded program and a validity period of the authorization token;

the verifying whether the account number is valid for the authorization token of the live broadcast embedded program includes:

acquiring authorization information of the account for the live broadcast embedded program;

determining whether the authorization token of the account for the live broadcast embedded program in the authorization information is consistent with the authorization token carried by the service interface calling request;

determining whether a system time is within the validity period.

In some embodiments, the invoking an interface corresponding to the interface identifier in response to the account number passing the verification of the authorization token of the live embedded program includes:

responding to the account number to pass the verification of the authorization token of the live broadcast embedded program, and acquiring the calling authority information of the interface corresponding to the interface identifier;

responding to the calling authority information to indicate that the calling of the interface needs authorization, and sending an interface authorization request to the account based on the interface identification and the account information of the account, wherein the interface authorization request is used for requesting the account to authorize the calling of the interface;

and executing the step of calling the interface corresponding to the interface identifier in response to receiving the authorization confirmation information of the account on the interface.

In some embodiments, in response to receiving the authorization confirmation information of the account for the interface, the step of invoking the interface corresponding to the interface identifier is performed, and includes:

in response to receiving the authorization confirmation information of the account on the interface, generating and sending an authorization token of the account on the interface to the account;

and executing the step of calling the interface corresponding to the interface identifier based on the authorization token of the account for the interface.

In some embodiments, the method is applied to a live embedded program platform, the live embedded program being provided by the live embedded program platform; the live embedded program platform supports any developer account to create and release live embedded programs.

responding to the starting operation of an account of live broadcast application on any live broadcast embedded program, and sending a starting request to a server, wherein the starting request carries an identifier of the live broadcast embedded program;

receiving an authorization request sent by the server in response to the starting request, wherein the authorization request carries the identification of the live broadcast embedded program and the account information of the account;

responding to an authorization confirmation operation of the authorization request, and sending authorization confirmation information to the server;

and receiving an authorization token sent by the server, wherein the authorization token is generated based on account information of the account and the identification of the live broadcast embedded program.

In one aspect, a live embedded program authorization apparatus is provided, the apparatus including:

the system comprises a receiving module, a judging module and a processing module, wherein the receiving module is used for receiving a starting request of an account of a live broadcast application to a live broadcast embedded program, and the starting request carries an identifier of the live broadcast embedded program;

a sending module, configured to send, in response to the start request, an authorization request to the account based on the identifier of the live broadcast embedded program and the account information of the account;

the generation module is used for responding to the received authorization confirmation information sent by the account responding to the authorization request, and generating an authorization token of the account for the live broadcast embedded program based on the identification of the live broadcast embedded program and the account information of the account;

the sending module is further configured to send the authorization token to the account.

In some embodiments, the sending module is configured to:

acquiring account information of the account;

and sending the authorization request to the account.

In some embodiments, the receiving module is further configured to receive a service interface call request of a live broadcast application account to the live broadcast embedded program, where the service interface call request carries an authorization token of the live broadcast embedded program and an interface identifier requested to be called;

the device further comprises:

the verification module is used for verifying the account number to the authorization token of the live broadcast embedded program;

and the calling module is used for responding to the passing of the account number to the verification of the authorization token of the live broadcast embedded program and calling the interface corresponding to the interface identifier.

In some embodiments, the verification module is configured to verify that the account number is valid for an authorization token of the live embedded program;

and the calling module is used for responding to the account number being valid for the authorization token of the live broadcast embedded program and executing the step of calling the interface corresponding to the interface identifier.

In some embodiments, the sending module is further configured to perform at least one of:

In some embodiments, the apparatus further comprises:

the caching module is used for caching authorization information of the account on the live broadcast embedded program, wherein the authorization information comprises an authorization token of the account on the live broadcast embedded program and a validity period of the authorization token;

the check module is used for:

determining whether a system time is within the validity period.

In some embodiments, the calling module is to:

In some embodiments, the apparatus is applied to a live embedded program platform, the live embedded program being provided by the live embedded program platform; the live embedded program platform supports any developer account to create and release live embedded programs.

the system comprises a sending module, a receiving module and a processing module, wherein the sending module is used for responding to the starting operation of an account of live broadcast application on any live broadcast embedded program and sending a starting request to a server, and the starting request carries an identifier of the live broadcast embedded program;

a receiving module, configured to receive an authorization request sent by the server in response to the start request, where the authorization request carries an identifier of the live broadcast embedded program and account information of the account;

the sending module is further configured to send authorization confirmation information to the server in response to an authorization confirmation operation on the authorization request;

the receiving module is further configured to receive an authorization token sent by the server, where the authorization token is generated based on the account information of the account and the identifier of the live broadcast embedded program.

In one aspect, an electronic device is provided that includes one or more processors and one or more memories, where at least one computer program is stored in the one or more memories, and loaded and executed by the one or more processors to implement the above-described live embedded program authorization method.

In one aspect, a computer-readable storage medium is provided, in which at least one computer program is stored, and the at least one computer program is loaded and executed by a processor to implement the above-mentioned live embedded program authorization method.

In one aspect, a computer program product or computer program is provided that includes one or more program codes stored in a computer-readable storage medium. One or more processors of the electronic device read the one or more program codes from the computer-readable storage medium, and execute the one or more program codes, so that the above-described live-embedded program authorization method is implemented.

In the embodiment of the application, the authorization service of the live broadcast embedded program is provided for the live broadcast application, and when the account of the live broadcast application starts the live broadcast embedded program in the live broadcast application, the authorization request can be sent to request generation of an authorization token of the account for the live broadcast embedded program so as to complete authorization of the account for the live broadcast embedded program, so that the account can obtain data service of the live broadcast embedded program subsequently. The authorization token provides the authority of the account for the live broadcast embedded program instead of the authority of the account for the live broadcast application, the authorization of the live broadcast embedded program is independent of the authorization of the live broadcast application, fine-grained authorization is achieved, the account is managed better, the fact that the live broadcast embedded program obtains relevant information of a user without authorization is avoided, privacy disclosure is caused, and data security is improved better.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on the drawings without creative efforts.

Fig. 1 is a schematic structural diagram of a live broadcast system provided in an embodiment of the present application;

fig. 2 is a flowchart of a live embedded program authorization method according to an embodiment of the present application;

fig. 3 is a flowchart of a live embedded program authorization method according to an embodiment of the present application;

fig. 4 is a flowchart of a live embedded program authorization method according to an embodiment of the present application;

fig. 5 is a flowchart of a live embedded program authorization method according to an embodiment of the present application;

fig. 6 is a flowchart of a live embedded program authorization method according to an embodiment of the present application;

fig. 7 is a flowchart of a live embedded program authorization method according to an embodiment of the present application;

fig. 8 is a flowchart of a live embedded program authorization method according to an embodiment of the present application;

fig. 9 is a flowchart of a live embedded program authorization method according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a live embedded program device according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of a live embedded program device according to an embodiment of the present application;

fig. 12 is a schematic structural diagram of an electronic device provided in an embodiment of the present application;

fig. 13 is a schematic structural diagram of a terminal according to an embodiment of the present application;

fig. 14 is a schematic structural diagram of a server according to an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

The terms "first," "second," and the like in this application are used for distinguishing between similar items and items that have substantially the same function or similar functionality, and it should be understood that "first," "second," and "nth" do not have any logical or temporal dependency or limitation on the number or order of execution. It will be further understood that, although the following description uses the terms first, second, etc. to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first image is referred to as a second image, and similarly, a second image is referred to as a first image, without departing from the scope of the various described examples. The first image and the second image are both images, and in some cases, separate and distinct images.

The term "at least one" is used herein to mean one or more, and the term "plurality" is used herein to mean two or more, e.g., a plurality of packets means two or more packets.

It is to be understood that the terminology used in the description of the various described examples herein is for the purpose of describing particular examples only and is not intended to be limiting. As used in the description of the various described examples and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. The term "and/or" is an associative relationship that describes an associated object, meaning that there are three relationships, e.g., A and/or B, meaning: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" in the present application generally indicates that the former and latter related objects are in an "or" relationship.

It should also be understood that, in the embodiments of the present application, the size of the serial number of each process does not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

It should also be understood that determining B from a does not mean determining B from a alone, but also from a and/or other information.

It will be further understood that the terms "Comprises," "Comprising," "inCludes" and/or "inCluding," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It is also understood that the term "if" may be interpreted to mean "when" ("where" or "upon") or "in response to a determination" or "in response to a detection". Similarly, the phrase "if it is determined." or "if [ a stated condition or event ] is detected" may be interpreted to mean "upon determining.. or" in response to determining. "or" upon detecting [ a stated condition or event ] or "in response to detecting [ a stated condition or event ]" depending on the context.

The following describes an embodiment of the present application.

Fig. 1 is a schematic structural diagram of a live broadcast system provided in an embodiment of the present application. As shown in fig. 1 (a), the live system includes a terminal 101, a backend server 102 for live application, and a live embedded program platform 103. The terminal 101 is respectively connected with a background server 102 of the live broadcast application and a live broadcast embedded program platform 103 through a network.

As shown in fig. 1 (b), the live system includes a terminal 101 and a background server 102 of a live application. The terminal 101 is connected with a background server 102 of the live application through a network. Wherein, a live embedded program platform 103 is installed on the background server 102 of the live application. That is, the background server 102 of the live application can provide live service in the live application for the terminal 101, and can also provide related data service of the live embedded program in the live application for the terminal 101 through the installed live embedded program platform.

The terminal 101 is at least one of a smart phone, a game console, a desktop computer, a tablet computer, an electronic book reader, an MP3(Moving Picture Experts Group Audio Layer III, motion Picture Experts compression standard Audio Layer 3) player, an MP4(Moving Picture Experts Group Audio Layer IV, motion Picture Experts compression standard Audio Layer 4) player, and a laptop. The terminal 101 is installed and operated with an application program supporting live broadcasting, for example, the application program is a live broadcasting application.

The background server 102 and the live embedded program platform 103 of the live application respectively comprise at least one of a server, a plurality of servers, a cloud computing platform and a virtualization center. The background server 102 and the live embedded program platform 103 of the live application are respectively used for providing background services for the live application and the live embedded program depending on the live application. Optionally, the background server 102 and the live embedded program platform 103 of the live application undertake primary processing, and the terminal 101 undertakes secondary processing; or, the background server 102 and the live embedded program platform 103 of the live application undertake the secondary processing work, and the terminal 101 undertakes the primary processing work; or, the background server 102 and the live embedded program platform 103 of the live application or the terminal 101 respectively undertake processing work independently. Or, a distributed computing architecture is adopted between the background server 102 and the live embedded program platform 103 of the live application and the terminal 101 for performing collaborative computing.

Optionally, the backend server 102 and the live embedded program platform 103 of the live application respectively include at least one server 1021 and a database 1022, where the database 1022 is used to store data, and in this embodiment of the present application, a configuration file of a live service or a live embedded program is stored in the database 1022, and provides a data service for the at least one server 1021.

Those skilled in the art will appreciate that there may be more or fewer terminals 101 and servers 1021. For example, there is only one terminal 101 or one server 1021, or tens or hundreds of the terminals 101 and the servers 1021, or more, and the number of the terminals or the servers and the device types are not limited in the embodiments of the present application.

Fig. 2 is a flowchart of a live embedded program authorization method provided in an embodiment of the present application, and referring to fig. 2, the method includes the following steps.

201. The server receives a starting request of an account of the live broadcast application to the live broadcast embedded program, wherein the starting request carries an identifier of the live broadcast embedded program.

A live embedded program is a program that relies on live applications. The live broadcast embedded program can be provided in the live broadcast application, and when the live broadcast application runs, if the live broadcast embedded program in the live broadcast application is started, the live broadcast embedded program can be started in the live broadcast application, corresponding operation is executed in the live broadcast embedded program, and the like.

Optionally, the embedded program is an applet, the applet is a program that runs by relying on another application client, and the live embedded program is a live applet. Applets refer to applications that run in a container, and most refer to runnable front-end programs provided by third-party developers. Some released live broadcast applets can be provided in the live broadcast application, the anchor can download and install the live broadcast applets, the live broadcast applets can be started in the live broadcast application, and the live broadcast applets can be accessed under the condition that the live broadcast application does not need to be quitted.

The applet is used to provide live related functionality, such as a game applet that enriches the live content. As another example, a wishlist applet for improving the interaction between a host and a viewer.

For example, a number of game applets may be provided within the live application, and the anchor may initiate a game applet during the live process and operate within a page of the game applet to live the game play process.

The identification of the live broadcast embedded program is used for uniquely identifying the live broadcast embedded program, and the server can know which live broadcast embedded program the account number needs to be started.

The identity of the live embedded program can include a variety of forms, for example, the identity of the live embedded program is the name of the live embedded program. For another example, the live broadcast embedded programs may be numbered, and the number of each live broadcast embedded program may be used as the identifier of the live broadcast embedded program. As another example, the identification of the live embedded program may be a download address of the live embedded program. The embodiment of the application does not limit which data is specifically adopted for the identification of the live broadcast embedded program.

Optionally, the start request may also carry an identifier of an account, so that after receiving the start request, the server may also know which account to start the live broadcast embedded program.

The identification of the account number can include a variety of forms, for example, the identification of the account number is the name of the account number (also referred to as a nickname). For another example, the account numbers of the live applications may be numbered, and the number of each account may be used as an identifier of the account, which may also be referred to as an ID (identification number) of the account. For another example, the identifier of the account may be user information associated with the account, such as a contact address associated with the account. The embodiment of the application does not limit which data is specifically adopted for the identification of the account.

The starting request is sent when the account number responds to the starting operation of the live broadcast embedded program, and when the account number of the live broadcast application starts any live broadcast embedded program in the live broadcast application, the terminal where the account number of the live broadcast application is located can send the starting request to the server to request the server to provide the related service of the live broadcast embedded program.

Optionally, the server may be the live embedded program platform, that is, the account of the live application may send a start request to the live embedded program platform to request a service related to the live embedded program provided by the live embedded program platform.

202. And the server responds to the starting request, and sends an authorization request to the account number based on the identification of the live broadcast embedded program and the account number information of the account number.

After receiving the start request, the server may provide a service for the account of the live application in response to the start request. In this embodiment of the present application, the live broadcast embedded program needs to be authorized by an account, that is, when accessing the live broadcast embedded program, the live broadcast embedded program needs to be authorized by the account, and after the authorization, the account can access the live broadcast embedded program. If the account is not authorized for the live broadcast embedding program, the live broadcast embedding program cannot acquire the account information of the account, and further cannot provide corresponding data service for the account.

The account information refers to information required for describing the account authorization. For example, the account information of the account may include an identifier of the account, an account level of the account, and the like, and the account information may also include other information, which is not listed here, and is not limited in this embodiment of the application.

The server responds to the starting request, extracts the identification of the live broadcast embedded program from the starting request, and can determine which live broadcast embedded program is authorized by the current account number based on the identification of the live broadcast embedded program.

The server responds to the starting request, and can also acquire account information of the account so as to determine which account is required to authorize the live embedded program currently.

After acquiring the identifier of the live broadcast embedded program and the account information of the account, the server may determine whether to authorize the account for the live broadcast embedded program to the account of the live broadcast application, so that the server may send an authorization request to the account of the live broadcast application.

Optionally, the authorization request may include an identifier of the live broadcast embedded program and account information of the account, so that after receiving the authorization request, the account of the live broadcast application may display the information of the live broadcast embedded program and the account information of the account when displaying the authorization request, so that the account can make sure who both parties of authorization are authorized respectively, and the accuracy of authorization is ensured.

203. And the server responds to the received authorization confirmation information sent by the account in response to the authorization request, and generates an authorization token of the account for the live broadcast embedded program based on the identification of the live broadcast embedded program and the account information of the account.

After receiving the authorization request, the account of the live broadcast application can perform authorization confirmation on the authorization request, and when the authorization confirmation is performed, the account of the live broadcast application can send authorization confirmation information to the server, that is, the account is determined to authorize the live broadcast embedded program. Accordingly, the server may receive the authorization confirmation information sent by the account in response to the authorization request, and may then generate an authorization token for the account, where the authorization token is used to indicate that the account is authorized for the live embedded program.

The authorization token is generated based on the identification of the live broadcast embedded program and the account information of the account, and then both authorization parties represented by the authorization token are the account and the live broadcast embedded program.

204. The server sends the authorization token to the account.

After the server generates the authorization token, the authorization token can be sent to the terminal where the account is located, so that the account can carry the authorization token when subsequently requesting the data service of the live broadcast embedded program, and thus, the corresponding data service can be successfully acquired.

In the embodiment of the application, the authorization service of the live broadcast embedded program is provided for the live broadcast application, and when the account of the live broadcast application starts the live broadcast embedded program in the live broadcast application, the authorization request can be sent to request generation of an authorization token of the account for the live broadcast embedded program so as to complete authorization of the account for the live broadcast embedded program, so that the account can obtain data service of the live broadcast embedded program subsequently. The authorization token provides the authority of the account for the live broadcast embedded program instead of the authority of the account for the live broadcast application, the authorization of the live broadcast embedded program is independent of the authorization of the live broadcast application, fine-grained authorization is achieved, the authorization of the account is managed better, the situation that privacy leakage is caused because the live broadcast embedded program obtains relevant information of a user without authorization is avoided, and data security is improved better.

Fig. 3 is a flowchart of a live embedded program authorization method provided in an embodiment of the present application, and referring to fig. 3, the method includes the following steps.

301. The terminal responds to the starting operation of the account of the live broadcast application on any live broadcast embedded program and sends a starting request to the server, wherein the starting request carries the identification of the live broadcast embedded program.

The live embedded program platform (referred to as a server herein) may provide a plurality of live embedded programs for the live application, and when an account of the live application wants to use the live embedded program, an installation request may be sent to the live embedded program platform, so that the live embedded program platform provides a package of the live embedded program for the live embedded program platform. After installation, the account may be used to start the live embedded program in the live application. Optionally, the live embedded program may also be directly provided in a live application, and the account may be directly started without installation when the account wants to use the live embedded program.

The starting operation may be a clicking operation of the account on the live embedded program, and the starting operation may also be other operations, for example, a long-time pressing operation, which is not limited in this embodiment of the present application.

The terminal detects the start operation and can send a start request to request a data service from a server providing a service related to the live embedded program. The start request carries the identification of the live broadcast embedded program, so that the server can definitely know which data service of the live broadcast embedded program the terminal wants to request through the identification of the live broadcast embedded program.

302. And the terminal receives an authorization request sent by the server in response to the starting request, wherein the authorization request carries the identification of the live broadcast embedded program and the account information of the account.

After receiving the start request sent by the terminal, the server needs to further determine whether to authorize the account to the data service of the live embedded program, so that the server sends an authorization request to the terminal to determine whether the account authorizes the live embedded program. Accordingly, the terminal receives the authorization request.

303. The terminal responds to the authorization confirmation operation of the authorization request and sends authorization confirmation information to the server.

After receiving the authorization request, the terminal may display the content of the authorization request in a display page. If the account confirms the authorization, an authorization confirmation operation may be performed. After detecting the authorization confirmation operation, the terminal may send authorization confirmation information to the server in response to the authorization confirmation operation.

The authorization confirmation information is used for indicating that the account number confirms that the live broadcast embedded program is authorized.

304. And the terminal receives an authorization token sent by the server, wherein the authorization token is generated based on the account information of the account and the identification of the live broadcast embedded program.

After receiving the authorization confirmation information sent by the terminal, the server knows that the account number determines to authorize the live broadcast embedded program, and can generate an authorization token based on the account number information of the account number and the identifier of the live broadcast embedded program, where the authorization token is used to indicate that the account number authorizes the live broadcast embedded program. After the server generates the authorization token, the server can send the authorization token to the terminal, and the terminal can receive the authorization token. When the account subsequently requests the data service of the live broadcast embedded program, the account can carry the authorization token to be used as an authorization certificate so as to successfully acquire the data service of the live broadcast embedded program.

The above-mentioned embodiments shown in fig. 2 and fig. 3 have described the live embedded program authorization method from the server side and the terminal side, and the following describes the specific flow of the live embedded program authorization method in a two-side interaction manner. Fig. 4 is a flowchart of a live embedded program authorization method provided in an embodiment of the present application, and referring to fig. 4, the method includes the following steps.

401. The terminal responds to the starting operation of the account of the live broadcast application on any live broadcast embedded program and sends a starting request to the server, wherein the starting request carries the identification of the live broadcast embedded program.

A published live embedded program may be provided in the live application for selection by a user. Specifically, a user can click a live broadcast embedded program display control in live broadcast application, the live broadcast embedded program platform can provide a live broadcast embedded program display interface for a terminal where the user is located, and a published live broadcast embedded program is displayed in the live broadcast embedded program display interface. If the user wants to download the live embedded program, the user can select the live embedded program to perform downloading operation.

For example, a small program mall may be provided in a live application, where the small program is provided with published small programs. For example, if a user clicks on an applet mall control in a live application, the live application may display an applet mall interface as shown in fig. 5, in which the published applet is displayed. Each applet is associated with a download control that is displayed as "+ add", i.e., indicating the addition (installation/download) of the applet in the live application.

After the live application is provided with the published live embedded program, the anchor may want to install the live embedded program so that the process of using the live embedded program is live in the live room.

The request for installing the live broadcast embedded program sent by the anchor account may be triggered by an installation operation of the anchor account on the terminal where the anchor account is located. For example, if the anchor clicks the "+ add" control in the area where any applet in fig. 5 is located, the terminal where the anchor is located may send the installation request for the applet to the live embedded program platform.

For the starting and using processes of the live broadcast embedded program, when the anchor account number is live broadcast in the live broadcast room, the anchor account number can start the live broadcast embedded program, and a terminal where the anchor account number is located can respond to the starting operation and can send a starting request to the server so as to obtain background services required when the live broadcast embedded program is started from the server.

402. The server receives a starting request of a terminal where an account of the live broadcast application is located to the live broadcast embedded program.

The server and the terminal are connected through a network, and the terminal can send a starting request to the server through the network connection. The server may then receive the initiation request over the network connection.

403. And the server responds to the starting request, and sends an authorization request to the terminal where the account is located based on the identification of the live broadcast embedded program and the account information of the account.

After receiving the start request, the server may determine whether the account sending the start request authorizes the live broadcast embedded program, and if not, the server may send an authorization request to a terminal where the account is located to request the account to authorize.

In some embodiments, the server may generate an authorization request based on the identity of the live embedded program and account information of the account, and then send the authorization request to the terminal where the account is located. The authorization request comprises the identification of the live broadcast embedded program and the account information of the account, so that the terminal where the account is located knows that the live broadcast embedded program is authorized for the account.

In some embodiments, the authorization request is generated based on information of the live embedded program and account information. Specifically, the server may obtain information of the live broadcast embedded program and account information of the account based on the identifier of the live broadcast embedded program, and then generate an authorization request of the account for the live broadcast embedded program based on the information of the live broadcast embedded program and the account information of the account, so as to send the authorization request to the account.

The information of the live broadcast embedded program may include at least one item of information of a name, a storage address, a size, a type, and the like of the live broadcast embedded program, which is not limited in this embodiment of the application.

The information of the live broadcast embedded program and the account information are acquired in any sequence, that is, the server may acquire the information of the live broadcast embedded program based on the identifier of the live broadcast embedded program and then execute the step of acquiring the account information of the account. The server may also acquire account information of the account, and then acquire information of the live broadcast embedded program based on the identifier of the live broadcast embedded program. The server can also acquire account information of the account and information of the live broadcast embedded program at the same time.

In some embodiments, some live embedded programs require account authorization, and other live embedded programs do not require account authorization. After receiving the start request, the server may determine whether the live broadcast embedded program requires account authorization based on the identifier of the live broadcast embedded program carried by the start request. The server may perform this step 403 in response to the live embedded program requiring account authorization. If the live embedded program does not require account authorization, the server may invoke the interface corresponding to the live embedded program in response to the start request without performing the step 403 and subsequent authorization steps, and send data corresponding to the interface to the account.

Whether the live embedded program requires account authorization may be represented by authorization information of the live embedded program. In some embodiments, the server stores authorization information of the live embedded program, and the authorization information includes an identifier of the live embedded program requiring account authorization. The server may query the authorization information for the identity of the live embedded program and, if queried, may perform step 403. If the identity of the live embedded program is not queried, no authorization is required.

In other embodiments, the authorization information may store an identifier of the live embedded program and indication information of whether the live embedded program needs account authorization. The server may obtain indication information of the live broadcast embedded program from the authorization information based on the identifier of the live broadcast embedded program, and if the indication information indicates that the live broadcast embedded program requires account authorization, the server may perform step 403. If the indication information indicates that the live broadcast embedded program does not need account authorization, authorization is not needed.

404. And the terminal receives an authorization request sent by the server in response to the starting request, wherein the authorization request carries the identification of the live broadcast embedded program and the account information of the account.

After receiving the authorization request sent by the server, the terminal may display the content of the authorization request in a display page, for example, whether to authorize the access right of the account to the live embedded program. The account number can determine whether to authorize or not according to the requirement.

405. The terminal responds to the authorization confirmation operation of the authorization request and sends authorization confirmation information to the server.

If the account determines to be authorized, an authorization confirmation operation can be performed on the terminal uplink. The terminal detects the authorization confirmation operation, and then can send authorization confirmation information to the server.

In the above case of authorization confirmation, the account may also reject authorization, and perform an authorization rejection operation on the terminal. The terminal detects the operation of refusing authorization, and can respond to the operation of refusing authorization to send the information of refusing authorization to the server.

406. And the server receives authorization confirmation information sent by the terminal of the account in response to the authorization request.

In the above step 406, if the terminal sends the authorization confirmation message and the server receives the authorization confirmation message, the server may receive the authorization rejection message if the terminal sends the authorization rejection message.

407. And the server responds to the authorization confirmation information and generates an authorization token of the account for the live broadcast embedded program based on the identification of the live broadcast embedded program and the account information of the account.

After receiving the authorization confirmation information, the server may determine that the account is confirmed to be authorized, and thus may generate an authorization token for the account, where the authorization token is generated based on the identifier of the live broadcast embedded program and the account information of the account, that is, the authorization token may include the identifier of the live broadcast embedded program and the account information of the account to identify that the account has authorized the live broadcast embedded program.

The authorization token is also an authorization credential, and when a subsequent account requests a data service of a live embedded program, the authorization token can be carried, so that the server can know that the account is authorized based on the authorization token, the live embedded program has the authority of acquiring the account information of the account, and the live embedded program can acquire the account information of the account to provide the data service based on the account information. The authorization token may be referred to as an authorization token.

In some embodiments, after the server generates the authorization token of the direct-broadcast embedded program by the account, the authorization token may be cached, and subsequently, when a request that the account carries the authorization token is received, the authorization token carried by the request may be checked based on the cached authorization token.

408. And the server sends the authorization token to the terminal of the account.

409. The terminal receives the authorization token sent by the server.

After the terminal receives the authorization token, based on the authorization token, it can be known that the server has successfully authorized the live broadcast embedded program for the account.

In some embodiments, the terminal may store the authorization token, which may be carried later when requesting the service of the live embedded program.

In some embodiments, the interface of the live embedded program that the request calls is to be account-authorized. That is, the interface may acquire the account information of the account only when the account is authorized, or further provide data services based on the account information of the account. The method specifically comprises the following steps of one to four:

step one, a terminal responds to a service interface calling operation of a live broadcast embedded program by an account of live broadcast application, and sends a service interface calling request to a server, wherein the service interface calling request carries an authorization token of the account to the live broadcast embedded program and an interface identifier for requesting calling.

After the terminal starts the live broadcast embedded program, the account can perform service interface calling operation in the page of the live broadcast embedded program so as to further obtain the data service of the live broadcast embedded program. The terminal can determine a service interface to be called according to the operation of the account number, so as to send a service interface calling request to the server. For example, the service interface calling operation may be logging in an account in a live embedded program, and the terminal may send a service interface calling request to the server to call an interface capable of providing account information.

And step two, the server receives a service interface calling request of the account of the live broadcast application to the live broadcast embedded program.

And step three, the server checks the account number for the authorization token of the live broadcast embedded program.

After receiving the service interface calling request, the server can determine whether the account is authorized for the live broadcast embedded program, and if so, the live broadcast embedded program can successfully call the corresponding interface. If not, the live broadcast embedded program can not call the corresponding interface, and the interface is called again after authorization.

When the authorization token is checked, it is mainly checked whether the authorization token is valid, and if so, the authorization token can be considered to pass the check. If not, the authorization token check may be considered to have failed. When the authorization token is valid, the server may perform step four described below. That is, the server executes the step of calling the interface corresponding to the interface identifier in response to the account being valid for the authorization token of the live broadcast embedded program.

If the authorization token check fails, i.e. the authorization token is invalid, the server may perform at least one of the following steps a and B:

step A: an authorization token expiration prompt is sent to the account. Through the prompt for the expiration of the authorization token, the account can know that the previously generated authorization token has expired, and currently, if the interface still needs to be called, re-authorization is needed.

And B: and sending an authorization request to the account based on the identification of the live broadcast embedded program and the account information of the account. In step B, the server may directly resend the authorization request, so that when the account receives the authorization request, it knows that the previous authorization token is invalid and needs to be authorized again.

In some embodiments, after step 407, the server may cache authorization information of the account for the live embedded program after generating the authorization token, where the authorization information includes the authorization token of the account for the live embedded program and a validity period of the authorization token. Correspondingly, in the third step, when the server checks whether the account number is valid for the authorization token of the live broadcast embedded program, the server may obtain the authorization information of the account number for the live broadcast embedded program, then determine whether the authorization token of the account number for the live broadcast embedded program in the authorization information is consistent with the authorization token carried by the service interface call request, and determine whether the system time is within the valid period.

It can be understood that, in response to that the account in the authorization information is consistent with the authorization token carried in the service interface call request for the authorization token of the live broadcast embedded program and the system time is within the validity period, it may be determined that the authorization token is valid. And in response to that the account number in the authorization information is inconsistent with the authorization token carried by the service interface calling request, or that the system time is out of the validity period, determining that the authorization token is invalid.

The validity of the user authorization is periodic through the setting of the validity period of the authorization token, and if the user logs in again (including switching device login), the user does not need to re-authorize if the authorization token is still within the validity period.

The step of caching the authorization information of the authorization token can sense whether the authorization token is expired in real time, so that whether the authorization token is expired is determined without acquiring the generation time of the authorization token and the like after receiving the authorization token every time, thereby effectively reducing the calculation time and improving the verification efficiency.

In some embodiments, the server may periodically check the authorization information of the authorization token, and in response to expiration of any authorization token, the server may update the valid status of the authorization token, that is, change the valid status of the authorization token from valid to invalid.

And step four, the server responds to the account number to pass the verification of the authorization token of the live broadcast embedded program, and calls an interface corresponding to the interface identifier.

After receiving the service interface calling request, the server can extract the interface identifier requesting to be called from the service interface calling request, and can know which interface to be called is through the interface identifier. When the authorization token passes the verification, the server may call the corresponding interface based on the interface identifier.

In some embodiments, some interfaces provided by the server may also require authorization to provide data services, and whether authorization is required for the interfaces may be represented by the call authority information of the interfaces. In the fourth step, after the server passes the verification of the authorization token, the server may obtain the call permission information of the interface corresponding to the interface identifier, the server may respond to the call permission information to indicate that the call of the interface needs authorization, send an interface authorization request to the account based on the interface identifier and the account information of the account, the interface authorization request being used to request the account to authorize the call of the interface, and then execute the step of calling the interface corresponding to the interface identifier in response to receiving the authorization confirmation information of the account to the interface.

And obtaining that the interface also needs to be authorized by calling the authority information, namely performing an authorization step between the account and the server, so as to successfully call the interface after the account authorizes the interface.

The process of authorizing the interface with the account is similar to that of authorizing the live-cast embedded program with the account, and specifically, the server may generate and send the authorization token of the interface with the account to the account in response to receiving the authorization confirmation information of the interface with the account, and then execute the step of calling the interface corresponding to the interface identifier based on the authorization token of the interface with the account. Subsequently, if the account calls the interface again, the account can carry the authorization token of the interface in the service interface calling request, and then the authorized interface can be directly called without repeated authorization subsequently.

In some embodiments, the authorization of the live broadcast embedded program is based on user authorization, the authorization token for the live broadcast application and the live broadcast embedded program is isolated, and the authorization for different live broadcast embedded programs is also isolated, that is, after one live broadcast embedded program is authorized, if an account needs to access another live broadcast embedded program, the account needs to be authorized again to the other live broadcast embedded program, so as to realize fine-grained authorization management and avoid the occurrence of account information leakage in the using process of the live broadcast embedded program.

In some embodiments, the server is a live embedded program platform, the live embedded program being provided by the live embedded program platform, the live embedded program platform supporting any developer account creation and publishing of the live embedded program. The live embedded program platform also supports the authorization service of the live embedded program.

The following describes an exemplary flow of the authorization method of the live embedded program according to the embodiment shown in fig. 6. As shown in fig. 6, taking a live broadcast embedded program as an applet as an example, a user may click on the applet, and then the applet may check whether to log in an account, if the account is logged in, the applet token (the applet token is an identifier of the applet) may be refreshed by an applet service module in the applet open platform, and if the user does not log in the account, the interface may jump to a user login interface, and after the user logs in the account, the applet token is refreshed. Then the applet service module queries the applet information to obtain authorization information, and generates an authorization token based on the applet information and the authorization information. The authorization information is information provided by the user, that is, the authorization confirmation information.

After the authorization token is generated, the applet service module sends the authorization token to the user side, and when the user side requests a service interface of the applet, the applet security module in the applet open platform can detect login state information, wherein the login state information indicates whether an account is logged in the applet. If not, the operation is ended, namely the service interface cannot be accessed. If so, further confirmation may be made as to whether the interface requires user authorization, and if so, further determination may be made as to whether the user is authorized, and if so, the interface may be accessed. If the user is not authorized, the authorization may be pulled, i.e., an authorization request sent to the user. If the user confirms the authorization, the user can authorize the interface, store the authorization information of the user, and refresh the authorization information of the user, so that the access authority of the interface is rechecked after the authorization is successful, and the interface can be successfully accessed because of the authorization.

For the PC side, the mobile side, and the third party user side, the authorization-based user status may be updated as follows. As shown in fig. 7, the user operates in the applet in the live APP, and when a service interface is needed, the interface security check may be performed by the server, and when the check passes, the user accesstken (authorization token) may be checked. If the user accesstken exists, whether the accesstken belongs to the small program can be further checked. If the user accesstken does not exist, the front end (user side) can be prompted to refresh the accesstken. When the interface is checked safely, if the check is not passed, the interface can be prompted to check specific problems. When checking whether the access Token belongs to the applet, determining whether the access Token is matched with the access Token of the applet, acquiring the Token information of the bound user when the access Token is matched with the access Token of the applet, checking whether the Token information is overdue after the Token information of the bound user is acquired, and pulling up the user to log in or re-authorize if the Token information is overdue. If not, further checking whether the user is authorized, if so, calling the service interface, and further performing subsequent operation of the service interface. If not, the user authorization may be pulled up. If it is determined that the accesstken does not match the accesstken of the applet, the authorization may be prompted to be invalid.

It should be noted that, when the user performs authorization, the user needs to carry original login state data of the user to the server for authorization, the server binds the login state data of the user with an authorization applet, the server generates new accesstken information to the client, subsequent interface requests all adopt new accesstken for requesting, the accesstken has certain timeliness and needs to be refreshed periodically, and the server binds the original login state data through the accesstken and verifies the original login state data in real time.

As shown in fig. 8, taking the user side as the PC side as an example, the PC interface basically does not perform signature verification, but only performs interface current limiting, the server side adds a cookie information, and the cookie is a computer file of information sent to the central server by the network or internet user. The cookie information is bound with the applet, encrypted and stored through AES (Advanced Encryption Standard), mapped to the original cookie information through new cookie information, verified in real time, and refreshed at regular time. The other steps are the same as the flow shown in fig. 7.

As shown in fig. 9, the server binds the user authorization data with the applet to generate a unique accessKey (through a key), the front end carries the secondary parameter to the third-party server, and the third-party server holds the accessKey to interact with the server of the live broadcast application, and pulls part of the information of the user. The other steps are the same as the flow shown in fig. 7.

Fig. 10 is a schematic structural diagram of a live broadcast embedded program authorization apparatus according to an embodiment of the present application, and as shown in fig. 10, the live broadcast embedded program authorization apparatus includes:

a receiving module 1001, configured to receive a start request of a live broadcast embedded program from an account of a live broadcast application, where the start request carries an identifier of the live broadcast embedded program;

a sending module 1002, configured to send, in response to the start request, an authorization request to the account based on the identifier of the live broadcast embedded program and the account information of the account;

a generating module 1003, configured to, in response to receiving authorization confirmation information sent by the account in response to the authorization request, generate an authorization token of the account for the live broadcast embedded program based on the identifier of the live broadcast embedded program and account information of the account;

the sending module 1002 is further configured to send the authorization token to the account.

In some embodiments, the sending module is configured to:

acquiring the information of the live broadcast embedded program based on the identification of the live broadcast embedded program;

acquiring account information of the account;

the authorization request is sent to the account.

In some embodiments, the receiving module is further configured to receive a service interface call request of an account of a live broadcast application to the live broadcast embedded program, where the service interface call request carries an authorization token of the account to the live broadcast embedded program and an interface identifier requested to be called;

the device also includes:

and the calling module is used for responding to the account number to pass the verification of the authorization token of the live broadcast embedded program and calling the interface corresponding to the interface identifier.

In some embodiments, the verification module is configured to verify that the account number is valid for the authorization token of the live embedded program;

the calling module is used for responding to the account number being valid for the authorization token of the live broadcast embedded program, and executing the step of calling the interface corresponding to the interface identifier.

in response to the account being invalid for the authorization token of the live embedded program, sending an authorization token expiration prompt to the account;

and in response to the account being invalid for the authorization token of the live embedded program, sending an authorization request to the account based on the identity of the live embedded program and account information of the account.

In some embodiments, the apparatus further comprises:

the cache module is used for caching authorization information of the account on the live broadcast embedded program, wherein the authorization information comprises an authorization token of the account on the live broadcast embedded program and a valid period of the authorization token;

the check module is used for:

determining whether the account number in the authorization information is consistent with an authorization token carried by the service interface calling request for the authorization token of the live broadcast embedded program;

it is determined whether the system time is within the validity period.

In some embodiments, the calling module is to:

Fig. 11 is a schematic structural diagram of a live broadcast embedded program authorization apparatus according to an embodiment of the present application, and as shown in fig. 11, the live broadcast embedded program authorization apparatus includes:

a sending module 1101, configured to send a start request to a server in response to a start operation of an account of a live broadcast application on any live broadcast embedded program, where the start request carries an identifier of the live broadcast embedded program;

a receiving module 1102, configured to receive an authorization request sent by the server in response to the start request, where the authorization request carries an identifier of the live broadcast embedded program and account information of the account;

the sending module 1101 is further configured to send authorization confirmation information to the server in response to an authorization confirmation operation on the authorization request;

the receiving module 1102 is further configured to receive an authorization token sent by the server, where the authorization token is generated based on the account information of the account and the identifier of the live broadcast embedded program.

Fig. 12 is a schematic structural diagram of an electronic device 1200 according to an embodiment of the present application, where the electronic device 1200 may generate a relatively large difference due to different configurations or performances, and includes one or more processors (CPUs) 1201 and one or more memories 1202, where the memory 1202 stores at least one computer program, and the at least one computer program is the computer program supporting various functions of the live embedded program platform. The at least one computer program is loaded and executed by the processor 1201 to implement the live embedded program authorization method described above. The electronic device further includes other components for implementing the functions of the device, for example, the electronic device further includes components such as a wired or wireless network interface and an input/output interface for inputting and outputting. The embodiments of the present application are not described herein in detail. The electronic device may be a terminal or a server, which is not limited in this embodiment of the present application.

Fig. 13 is a block diagram of a final structure provided in an embodiment of the present application. The terminal 1300 may be a portable mobile terminal such as: a smart phone, a tablet computer, an MP3(Moving Picture Experts Group Audio Layer III, motion video Experts compression standard Audio Layer 3) player, an MP4(Moving Picture Experts Group Audio Layer IV, motion video Experts compression standard Audio Layer 4) player, a notebook computer or a desktop computer. Terminal 1300 may also be referred to by other names such as user equipment, portable terminal, laptop terminal, desktop terminal, etc.

In general, terminal 1300 includes: a processor 1301 and a memory 1302.

Processor 1301 may include one or more processing cores, such as a 4-core processor, an 8-core processor, and the like. The processor 1301 may be implemented in at least one hardware form of a DSP (Digital Signal Processing), an FPGA (Field-Programmable Gate Array), and a PLA (Programmable Logic Array). The processor 1301 may also include a main processor and a coprocessor, where the main processor is a processor for Processing data in an awake state, and is also referred to as a Central Processing Unit (CPU); a coprocessor is a low power processor for processing data in a standby state. In some embodiments, the processor 1301 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing content that the display screen needs to display. In some embodiments, processor 1301 may further include an AI (Artificial Intelligence) processor for processing computational operations related to machine learning.

Memory 1302 may include one or more computer-readable storage media, which may be non-transitory. The memory 1302 may also include high speed random access memory, as well as non-volatile memory, such as one or more magnetic disk storage devices, flash memory storage devices. In some embodiments, a non-transitory computer-readable storage medium in memory 1302 is used to store at least one instruction for execution by processor 1301 to implement the live embedded program authorization method provided by method embodiments herein.

In some embodiments, terminal 1300 may further optionally include: a peripheral interface 1303 and at least one peripheral. Processor 1301, memory 1302, and peripheral interface 1303 may be connected by a bus or signal line. Each peripheral device may be connected to the peripheral device interface 1303 via a bus, signal line, or circuit board. Specifically, the peripheral device includes: at least one of radio frequency circuitry 1304, display screen 1305, camera assembly 1306, audio circuitry 1307, positioning assembly 1308, and power supply 1309.

Peripheral interface 1303 may be used to connect at least one peripheral associated with I/O (Input/Output) to processor 1301 and memory 1302. In some embodiments, processor 1301, memory 1302, and peripheral interface 1303 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 1301, the memory 1302, and the peripheral device interface 1303 may be implemented on a separate chip or circuit board, which is not limited in this embodiment.

The Radio Frequency circuit 1304 is used to receive and transmit RF (Radio Frequency) signals, also called electromagnetic signals. The radio frequency circuitry 1304 communicates with communication networks and other communication devices via electromagnetic signals. The radio frequency circuit 1304 converts an electrical signal into an electromagnetic signal to transmit, or converts a received electromagnetic signal into an electrical signal. Optionally, the radio frequency circuit 1304 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a subscriber identity module card, and so forth. The radio frequency circuitry 1304 may communicate with other terminals via at least one wireless communication protocol. The wireless communication protocols include, but are not limited to: the world wide web, metropolitan area networks, intranets, generations of mobile communication networks (2G, 3G, 4G, and 5G), Wireless local area networks, and/or WiFi (Wireless Fidelity) networks. In some embodiments, the radio frequency circuit 1304 may also include NFC (Near Field Communication) related circuits, which are not limited in this application.

The display screen 1305 is used to display a UI (User Interface). The UI may include graphics, text, icons, video, and any combination thereof. When the display screen 1305 is a touch display screen, the display screen 1305 also has the ability to capture touch signals on or over the surface of the display screen 1305. The touch signal may be input to the processor 1301 as a control signal for processing. At this point, the display 1305 may also be used to provide virtual buttons and/or a virtual keyboard, also referred to as soft buttons and/or a soft keyboard. In some embodiments, display 1305 may be one, disposed on the front panel of terminal 1300; in other embodiments, display 1305 may be at least two, either on different surfaces of terminal 1300 or in a folded design; in other embodiments, display 1305 may be a flexible display disposed on a curved surface or on a folded surface of terminal 1300. Even further, the display 1305 may be arranged in a non-rectangular irregular figure, i.e., a shaped screen. The Display 1305 may be made of LCD (Liquid Crystal Display), OLED (Organic Light-Emitting Diode), or the like.

The camera assembly 1306 is used to capture images or video. Optionally, camera assembly 1306 includes a front camera and a rear camera. Generally, a front camera is disposed at a front panel of the terminal, and a rear camera is disposed at a rear surface of the terminal. In some embodiments, the number of the rear cameras is at least two, and each rear camera is any one of a main camera, a depth-of-field camera, a wide-angle camera and a telephoto camera, so that the main camera and the depth-of-field camera are fused to realize a background blurring function, and the main camera and the wide-angle camera are fused to realize panoramic shooting and VR (Virtual Reality) shooting functions or other fusion shooting functions. In some embodiments, camera assembly 1306 may also include a flash. The flash lamp can be a monochrome temperature flash lamp or a bicolor temperature flash lamp. The double-color-temperature flash lamp is a combination of a warm-light flash lamp and a cold-light flash lamp, and can be used for light compensation at different color temperatures.

The audio circuit 1307 may include a microphone and a speaker. The microphone is used for collecting sound waves of a user and the environment, converting the sound waves into electric signals, and inputting the electric signals to the processor 1301 for processing, or inputting the electric signals to the radio frequency circuit 1304 for realizing voice communication. For stereo capture or noise reduction purposes, multiple microphones may be provided, each at a different location of terminal 1300. The microphone may also be an array microphone or an omni-directional pick-up microphone. The speaker is used to convert electrical signals from the processor 1301 or the radio frequency circuitry 1304 into sound waves. The loudspeaker can be a traditional film loudspeaker or a piezoelectric ceramic loudspeaker. When the speaker is a piezoelectric ceramic speaker, the speaker can be used for purposes such as converting an electric signal into a sound wave audible to a human being, or converting an electric signal into a sound wave inaudible to a human being to measure a distance. In some embodiments, audio circuitry 1307 may also include a headphone jack.

The positioning component 1308 is used for positioning the current geographic position of the terminal 1300 for implementing navigation or LBS (Location Based Service). The Positioning component 1308 can be a Positioning component based on the Global Positioning System (GPS) in the united states, the beidou System in china, or the galileo System in russia.

Power supply 1309 is used to provide power to various components in terminal 1300. The power source 1309 may be alternating current, direct current, disposable or rechargeable. When the power source 1309 comprises a rechargeable battery, the rechargeable battery may be a wired rechargeable battery or a wireless rechargeable battery. The wired rechargeable battery is a battery charged through a wired line, and the wireless rechargeable battery is a battery charged through a wireless coil. The rechargeable battery may also be used to support fast charge technology.

In some embodiments, terminal 1300 also includes one or more sensors 1310. The one or more sensors 1310 include, but are not limited to: acceleration sensor 1311, gyro sensor 1312, pressure sensor 1313, fingerprint sensor 1314, optical sensor 1315, and proximity sensor 1316.

The acceleration sensor 1311 can detect the magnitude of acceleration on three coordinate axes of the coordinate system established with the terminal 1300. For example, the acceleration sensor 1311 may be used to detect components of gravitational acceleration in three coordinate axes. The processor 1301 may control the display screen 1305 to display the user interface in a landscape view or a portrait view according to the gravitational acceleration signal collected by the acceleration sensor 1311. The acceleration sensor 1311 may also be used for acquisition of motion data of a game or a user.

The gyro sensor 1312 may detect the body direction and the rotation angle of the terminal 1300, and the gyro sensor 1312 may cooperate with the acceleration sensor 1311 to acquire a 3D motion of the user with respect to the terminal 1300. Processor 1301, based on the data collected by gyroscope sensor 1312, may perform the following functions: motion sensing (such as changing the UI according to a user's tilting operation), image stabilization at the time of photographing, game control, and inertial navigation.

Pressure sensor 1313 may be disposed on a side bezel of terminal 1300 and/or underlying display 1305. When the pressure sensor 1313 is disposed on the side frame of the terminal 1300, a user's holding signal to the terminal 1300 may be detected, and the processor 1301 performs left-right hand recognition or shortcut operation according to the holding signal acquired by the pressure sensor 1313. When the pressure sensor 1313 is disposed at a lower layer of the display screen 1305, the processor 1301 controls an operability control on the UI interface according to a pressure operation of the user on the display screen 1305. The operability control comprises at least one of a button control, a scroll bar control, an icon control and a menu control.

The fingerprint sensor 1314 is used for collecting the fingerprint of the user, and the processor 1301 identifies the identity of the user according to the fingerprint collected by the fingerprint sensor 1314, or the fingerprint sensor 1314 identifies the identity of the user according to the collected fingerprint. When the identity of the user is identified as a trusted identity, the processor 1301 authorizes the user to perform relevant sensitive operations, including unlocking a screen, viewing encrypted information, downloading software, paying, changing settings, and the like. The fingerprint sensor 1314 may be disposed on the front, back, or side of the terminal 1300. When a physical button or vendor Logo is provided on the terminal 1300, the fingerprint sensor 1314 may be integrated with the physical button or vendor Logo.

The optical sensor 1315 is used to collect the ambient light intensity. In one embodiment, the processor 1301 may control the display brightness of the display screen 1305 according to the ambient light intensity collected by the optical sensor 1315. Specifically, when the ambient light intensity is high, the display brightness of the display screen 1305 is increased; when the ambient light intensity is low, the display brightness of the display screen 1305 is reduced. In another embodiment, the processor 1301 can also dynamically adjust the shooting parameters of the camera assembly 1306 according to the ambient light intensity collected by the optical sensor 1315.

Proximity sensor 1316, also known as a distance sensor, is typically disposed on a front panel of terminal 1300. Proximity sensor 1316 is used to gather the distance between the user and the front face of terminal 1300. In one embodiment, the processor 1301 controls the display 1305 to switch from the bright screen state to the dark screen state when the proximity sensor 1316 detects that the distance between the user and the front face of the terminal 1300 gradually decreases; the display 1305 is controlled by the processor 1301 to switch from the rest state to the bright state when the proximity sensor 1316 detects that the distance between the user and the front face of the terminal 1300 is gradually increasing.

Those skilled in the art will appreciate that the configuration shown in fig. 13 is not intended to be limiting with respect to terminal 1300 and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components may be employed.

The electronic device in the above method embodiment is implemented as a server. For example, fig. 14 is a schematic structural diagram of a server provided in this embodiment of the present application, where the server 1400 may generate relatively large differences due to different configurations or performances, and includes one or more processors (CPUs) 1401 and one or more memories 1402, where the memory 1402 stores at least one computer program, and the at least one computer program is loaded and executed by the processors 1401 to implement the live embedded program authorization method provided in the foregoing method embodiments. Certainly, the server further has a wired or wireless network interface, an input/output interface, and other components to facilitate input and output, and the server further includes other components for implementing the functions of the device, which are not described herein again.

In an exemplary embodiment, a computer-readable storage medium, such as a memory including at least one computer program, the at least one computer program being the computer program supporting the various functions of the live embedded program platform described above, is also provided. The at least one computer program is loaded by a processor of the electronic device and executes a method capable of implementing the live embedded program authorization method. For example, the computer readable storage medium is a Read-Only Memory (ROM), a Random Access Memory (RAM), a Compact Disc Read-Only Memory (CD-ROM), a magnetic tape, a floppy disk, an optical data storage device, and the like.

In an exemplary embodiment, a computer program product or a computer program is also provided, which comprises one or more program codes, which are stored in a computer-readable storage medium. The one or more processors of the electronic device read the one or more program codes from the computer-readable storage medium, the at least one program code being the program code described above that supports the various functionalities of the live embedded program platform. The at least one program code is loaded by a processor of the electronic device and executed to implement the live embedded program authorization method described above.

In some embodiments, the computer program according to the embodiments of the present application may be deployed to be executed on one server or on a plurality of servers located at one site, or may be executed on a plurality of servers distributed at a plurality of sites and interconnected by a communication network, and the plurality of servers distributed at the plurality of sites and interconnected by the communication network may constitute a block chain system.

Those skilled in the art will understand that all or part of the steps for implementing the above embodiments are implemented by hardware, and also implemented by a program for instructing relevant hardware, where the program is stored in a computer-readable storage medium, and the storage medium mentioned above is a read-only memory, a magnetic disk or an optical disk, etc.

The above description is intended only to be an alternative embodiment of the present application, and not to limit the present application, and any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A live embedded program authorization method, the method comprising:

and sending the authorization token to the account.

2. The method of claim 1, wherein sending an authorization request to the account based on the identity of the live embedded program and account information of the account comprises:

acquiring account information of the account;

and sending the authorization request to the account.

3. The method of claim 1, further comprising:

4. The method of claim 3, wherein verifying the account number against the authorization token of the live embedded program comprises:

5. The method of claim 4, further comprising at least one of:

6. The method of claim 4 or 5, wherein after generating the authorization token of the account for the live embedded program based on the identity of the live embedded program and the account information of the account, the method further comprises:

determining whether a system time is within the validity period.

7. The method of claim 3, wherein the invoking of the interface corresponding to the interface identifier in response to the account number verifying the authorization token of the live embedded program comprises:

8. The method according to claim 7, wherein the step of invoking the interface corresponding to the interface identifier is performed in response to receiving the authorization confirmation information of the account for the interface, and includes:

9. The method of any one of claims 1-8, wherein the method is applied to a live embedded program platform, and wherein the live embedded program is provided by the live embedded program platform; the live embedded program platform supports any developer account to create and release live embedded programs.

10. A live embedded program authorization method, the method comprising:

11. A live embedded program authoring apparatus, the apparatus comprising:

12. A live embedded program authoring apparatus, the apparatus comprising:

13. An electronic device, comprising one or more processors and one or more memories having at least one computer program stored therein, the at least one computer program being loaded and executed by the one or more processors to implement the live embedded program authorization method of any one of claims 1 to 10.

14. A computer-readable storage medium, having stored therein at least one computer program which is loaded and executed by a processor to implement the live embedded program authorization method of any one of claim 1 to claim 10.