CN114443173B - Subroutine loading processing method and device - Google Patents
Subroutine loading processing method and device Download PDFInfo
- Publication number
- CN114443173B CN114443173B CN202210128063.XA CN202210128063A CN114443173B CN 114443173 B CN114443173 B CN 114443173B CN 202210128063 A CN202210128063 A CN 202210128063A CN 114443173 B CN114443173 B CN 114443173B
- Authority
- CN
- China
- Prior art keywords
- token
- subroutine
- access token
- access
- provider
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000011068 loading method Methods 0.000 title claims abstract description 42
- 238000003672 processing method Methods 0.000 title claims description 23
- 238000000034 method Methods 0.000 claims abstract description 47
- 238000012545 processing Methods 0.000 claims abstract description 39
- 238000012360 testing method Methods 0.000 claims description 19
- 239000012634 fragment Substances 0.000 claims description 3
- 238000010586 diagram Methods 0.000 description 18
- 230000008569 process Effects 0.000 description 18
- 238000012795 verification Methods 0.000 description 15
- 230000006870 function Effects 0.000 description 11
- 230000006872 improvement Effects 0.000 description 8
- 238000004590 computer program Methods 0.000 description 7
- 238000005516 engineering process Methods 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 150000003839 salts Chemical class 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000009792 diffusion process Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 229920001296 polysiloxane Polymers 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000010979 ruby Substances 0.000 description 1
- 229910001750 ruby Inorganic materials 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/101—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities
- G06F21/1014—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities to tokens
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Multimedia (AREA)
- Technology Law (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The embodiment of the specification provides a method and a device for loading and processing a subroutine, wherein the method for loading and processing the subroutine comprises the following steps: acquiring an access token input by a device provider submitted by a Demo application installed by a terminal device; the access token is generated based on an access request submitted by the device provider for a target subroutine; if the access token is stored in the preset storage space, reading the token metadata associated with the access token; updating the access right configuration of the access token and reading the subroutine identification contained in the token metadata; and issuing the subprogram identification to the Demo application so as to load the target subprogram on the Demo application based on the subprogram identification.
Description
Technical Field
The present document relates to the field of data processing technologies, and in particular, to a method and an apparatus for loading and processing a subroutine.
Background
With the development of internet technology and the popularization of mobile terminals, more and more services start to extend to online scenes, application platform software capable of carrying a plurality of application subroutines appears, and the situation that a user installs different types of application programs on the mobile terminal is avoided, and the application subroutines carried in the application platform software are used for realizing service handling, and meanwhile, the application subroutines can fully utilize sufficient user flow of the application platform software, so that assistance is provided for service promotion of the application subroutines.
Disclosure of Invention
One or more embodiments of the present specification provide a subroutine loading processing method. The subroutine loading processing method comprises the following steps: acquiring an access token input by a device provider submitted by a Demo application installed by a terminal device; the access token is generated based on an access request submitted by the device provider for a target subroutine. And if the access token is stored in the preset storage space, reading the token metadata associated with the access token. And updating the access authority configuration of the access token and reading the subroutine identification contained in the token metadata. And issuing the subprogram identification to the Demo application so as to load the target subprogram on the Demo application based on the subprogram identification.
One or more embodiments of the present specification provide a subroutine loading processing apparatus including: the token acquisition module is configured to acquire an access token input by a device provider submitted by a Demo application installed by the terminal device; the access token is generated based on an access request submitted by the device provider for a target subroutine. And if the access token is stored in the preset storage space, operating a metadata reading module, wherein the metadata reading module is configured to read the token metadata associated with the access token. And the identification reading module is configured to update the access right configuration of the access token and read the subroutine identification contained in the token metadata. And the identification issuing module is configured to issue the subprogram identification to the Demo application so as to load the target subprogram on the Demo application based on the subprogram identification.
One or more embodiments of the present specification provide a subroutine loading processing apparatus including: a processor; and a memory configured to store computer-executable instructions that, when executed, cause the processor to: acquiring an access token input by a device provider submitted by a Demo application installed by a terminal device; the access token is generated based on an access request submitted by the device provider for a target subroutine. And if the access token is stored in the preset storage space, reading the token metadata associated with the access token. And updating the access authority configuration of the access token and reading the subroutine identification contained in the token metadata. And issuing the subprogram identification to the Demo application so as to load the target subprogram on the Demo application based on the subprogram identification.
One or more embodiments of the present specification provide a storage medium storing computer-executable instructions that, when executed by a processor, implement the following: acquiring an access token input by a device provider submitted by a Demo application installed by a terminal device; the access token is generated based on an access request submitted by the device provider for a target subroutine. And if the access token is stored in the preset storage space, reading the token metadata associated with the access token. And updating the access authority configuration of the access token and reading the subroutine identification contained in the token metadata. And issuing the subprogram identification to the Demo application so as to load the target subprogram on the Demo application based on the subprogram identification.
Drawings
For a clearer description of one or more embodiments of the present description or of the solutions of the prior art, the drawings that are needed in the description of the embodiments or of the prior art will be briefly described below, it being obvious that the drawings in the description that follow are only some of the embodiments described in the present description, from which other drawings can be obtained, without inventive faculty, for a person skilled in the art;
FIG. 1 is a process flow diagram of a subroutine loading process method provided in one or more embodiments of the present disclosure;
FIG. 2 is a schematic diagram of a test access scenario applied to a subroutine provided in one or more embodiments of the present disclosure;
FIG. 3 is a schematic diagram of an access token generation process provided by one or more embodiments of the present disclosure;
FIG. 4 is a process flow diagram of a method for loading a subroutine in a subroutine access scenario according to one or more embodiments of the present disclosure;
FIG. 5 is a schematic diagram of a subroutine loading processing apparatus according to one or more embodiments of the present disclosure;
fig. 6 is a schematic structural diagram of a subroutine loading processing apparatus according to one or more embodiments of the present disclosure.
Detailed Description
In order to enable a person skilled in the art to better understand the technical solutions in one or more embodiments of the present specification, the technical solutions in one or more embodiments of the present specification will be clearly and completely described below with reference to the drawings in one or more embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one or more embodiments of the present disclosure without inventive effort, are intended to be within the scope of the present disclosure.
The embodiment of a subroutine loading processing method provided in the present specification:
Referring to fig. 1, a process flow diagram of a subroutine loading processing method provided in this embodiment is shown, referring to fig. 2, a schematic diagram applied to a subroutine test access scenario provided in this embodiment is shown, referring to fig. 3, a process schematic diagram of generating an access token provided in this embodiment is shown, and referring to fig. 4, a process flow diagram of a subroutine loading processing method applied to a subroutine access scenario provided in this embodiment is shown.
Referring to fig. 1, the method for processing loading a subroutine provided in the present embodiment specifically includes steps S102 to S108.
Step S102, access tokens input by device providers submitted by a Demo application installed by a terminal device are acquired.
According to the sub-program loading processing method, the Demo application is installed on the terminal equipment of the equipment provider, so that the equipment provider can input an access token of a target sub-program to be tested through the Demo application, after the access token submitted by the Demo application is effectively verified and passed, a sub-program identification of the target sub-program contained in the token metadata associated with the stored access token is issued to the Demo application, the target sub-program is loaded on the Demo application, and the equipment provider can test the target sub-program operated by the Demo application, and therefore the Demo application is provided for the equipment provider, the equipment provider can test a plurality of sub-programs through the Demo application, the experience efficiency of the equipment provider on the sub-program is improved, and the perception degree of the experience sub-program of the equipment provider is improved.
The terminal device in this embodiment includes at least one of the following: the intelligent mobile phone comprises a car terminal, a car external terminal device, an intelligent sound box, an unmanned vending machine, an autonomous radio, an interactive advertisement screen, POS equipment, intelligent household appliances such as an intelligent television and an intelligent refrigerator. The equipment provider comprises a producer, a seller and/or a service operation and maintenance party of the terminal equipment. The dem application refers to an operation framework or an operation engine provided for terminal equipment, and by installing the dem application in the terminal equipment, the dem application can realize the access of a subroutine in the terminal equipment, and specifically comprises the operation of the subroutine for providing corresponding services in the terminal equipment. Optionally, the Demo application is an access container of the target subroutine; the Demo application is used for running the target subprogram, and is configured with an access entry of the target subprogram.
The target sub-program refers to a program package or an application component which is mounted on or loaded by an application platform (or an application program), and the target sub-program has the capability of independently providing self-closed-loop services, such as a sub-program running in the application program to provide vehicle related services or self-closed-loop capabilities of point-to-point services.
In a specific implementation, the device provider inputs the access token through the Demo application to access the target subroutine, and in an alternative implementation provided in this embodiment, the access token is generated by adopting the following manner:
constructing the token metadata of the equipment provider for the target subprogram based on the provider identification of the equipment provider, the subprogram identification and a preset token condition;
And encrypting the token metadata according to an encryption algorithm to obtain the access token.
In order to ensure the validity of the access token, the generation of the access token is restrained through the preset token condition, the generation of the access token is prevented from being diffused in a certain time, the preset token condition is controlled by the equipment platform, and the verification is carried out when the equipment provider uses the access token to access the target subprogram, so that the abuse of the access token is avoided; specifically, the generated access token does not need to generate a new access token under the condition that the generated access token is in a preset token condition, wherein the preset token condition comprises the usable times and/or the expiration time; based on this, in an alternative implementation manner provided in this embodiment, before the token metadata is created, the following operations are further performed:
inquiring whether a valid access token exists in a token record table in a valid time interval or not based on the provider identification and the subprogram identification;
If yes, determining the effective access token as the access token;
If not, creating the token metadata of the equipment provider for the target subprogram based on the provider identification of the equipment provider, the subprogram identification and a preset token condition; and encrypting the token metadata according to an encryption algorithm to obtain the access token.
Optionally, the provider identifier is obtained after the device provider performs a login operation; the subroutine mark is obtained after searching the search information in the search request submitted by the equipment provider.
Specifically, in the process of generating the access token, firstly acquiring a provider identifier carried in login operation of the equipment provider, then acquiring a subprogram identifier of a target subprogram obtained after searching search information in a search request submitted by the equipment provider, and then inquiring whether an effective access token associated with the equipment provider and the subprogram identifier exists in a token record table or not, and if so, returning the effective access token to the equipment provider; if the access token does not exist, firstly, creating token metadata of the equipment provider for accessing the target subprogram based on the provider identification, the subprogram identification and the preset token condition, then encrypting the token metadata according to an encryption algorithm to obtain the access token, and finally returning the obtained access token to the equipment provider.
For example, a token generation request submitted by a device provider after logging in and searching is obtained, a provider ID (Identity document, an identity number) and a subprogram ID carried in the token generation request are read, an access token created for the provider ID and the subprogram ID within 24 hours is queried in a maintained token record table according to the provider ID and the subprogram ID, and if the access token exists, the access token is sent to the device provider; if not, creating token metadata for accessing the target subprogram corresponding to the subprogram ID according to the provider ID, the subprogram ID, the usable times and the effective time to obtain 'provider ID+subprogram ID+m (usable times) +xx hour xx score', then carrying out encryption processing through MD5 (Message-Digest Algorithm) based on the token metadata and salt, and generating an access token for the equipment provider to access the subprogram corresponding to the subprogram ID; wherein, xx-hour xx points are determined according to creation time and effective time; the xx hour xx score may also be 24 hours and count down according to 24 hours.
It should be noted that, the above processing procedure for the access token may be executed by a device platform executing the subroutine loading processing method provided in this embodiment, and may also be completed by cooperation of an open platform and a device platform, where the device platform includes a platform for managing the subroutine, including generating the access token and verifying the access token; an open platform is a platform that interacts with a device provider and a device platform.
If the process of generating the access token is completed by cooperation of the open platform and the equipment platform, the open platform acquires the provider identifier carried in the login operation of the equipment provider, and acquires the subroutine identifier after searching the search information in the search request submitted by the equipment provider; the open platform sends the provider identification and the subprogram identification to the equipment platform, and the equipment platform inquires whether a valid access token which is in a valid time interval and is associated with the provider identification and the subprogram identification exists in the token record table; if so, returning the effective access token to the open platform, and returning the effective access token to the equipment provider by the open platform so that the equipment provider accesses the target subprogram through the Demo application based on the effective access token; if the target sub program does not exist, the device creation device provider encrypts the token metadata of the target sub program based on the device side identifier, the sub program identifier and the preset token condition, obtains an access token, and returns the access token to the open platform so that the open platform sends the access token to the device provider.
It should be further noted that, the device provider may download the dem application through the open platform and install the dem application on the terminal device, and input the access token through the dem application to complete the test of the target subroutine. And if the open platform does not exist, downloading from the equipment platform.
After generating the access token, in order to prevent the device provider from generating the access token multiple times in a short time, the generated access token and the token metadata are stored, and in an alternative implementation manner provided in this embodiment, the generated token metadata and the access token are stored in the following manner:
creating a key value pair by taking the access token as a primary key and taking the token metadata as a key value, and storing the key value pair in the preset storage space;
establishing an association relationship among the provider identification of the equipment provider, the subroutine identification and the access token;
And storing the association relation in a token record table and marking the effective time.
Specifically, after the access token is generated, the access token is used as a primary key, the token metadata is used as a key value, the access token is stored in an effective storage space with timing and/or frequency detection, and the association relation of the provider identifier, the subroutine identifier and the access token is established, stored in a token record table, and subjected to effective time identification, so that whether the access token in an effective time interval exists is inquired in the token record table when a subsequent token generation request is performed.
For example, after the access token is generated, a key value pair of < access token, provider id+subroutine id+m+xx time xx > is created, the key value pair is stored in a cache, meanwhile, an association relationship of the provider ID, subroutine ID and access token is established, the association relationship is written in a token record table in the form of "provider id+subroutine id+access token", and the association relationship is effectively time-stamped.
It should be noted that, in the process of constructing the token metadata, other parameters may also be included, which is not limited in this embodiment.
Step S104, if the access token is stored in the preset storage space, reading the token metadata associated with the access token.
Optionally, the access token is stored in the preset storage space in the effective time; the preset storage space comprises a cache. And storing the access tokens which are in the effective time range and are not used for 0 in the effective use times in the preset storage space.
In the specific implementation, monitoring time and times for a key value pair formed by a stored access token and token metadata in a preset storage space, and optionally deleting the access token from the preset storage space if the effective time is exceeded; or if the effective times in the access right configuration are updated to be zero, deleting the access token from the preset storage space; wherein, the access tokens stored in the preset storage space are clocked and counted by using a timer and a counter.
For example, a key pair constructed by an access token and token metadata is stored in a buffer, the effective time is 24 hours, the effective use number is m, the buffer counts down by a timer for 24 hours, the buffer counts m times by a counter, and when the timer time is 0 or the counter number is 0, the buffer deletes the stored key pair.
After an access token input by a device provider is obtained, inquiring whether a key value pair taking the access token as a main key exists in a preset storage control; if the verification failure exists, the device provider is indicated that the target subprogram cannot be accessed by using the access token, and a verification failure reminder is returned to the device provider; if the access token exists, the access token is determined to be stored in the preset storage space, and the token metadata associated with the access token is read, namely, the key value in the key value pair taking the access token as the main key is read.
In addition, if the preset storage space does not have the timing or counting function, after the access token submitted by the equipment provider is obtained, inquiring whether the effective use times of the access token are more than 0; if not, judging that the access token is invalid, and returning a verification failure prompt to the equipment provider; the verification failure reminding comprises verification failure reasons; if yes, checking whether the access token exceeds the effective time interval; if yes, returning a verification failure prompt to the equipment provider, wherein the verification failure prompt comprises a verification failure reason; if not, reading the token metadata associated with the access token.
And step S106, updating the access right configuration of the access token and reading the subroutine identification contained in the token metadata.
The access right configuration comprises a storage condition configuration of the access token in a preset storage space, such as the residual use times.
In particular, in order to avoid misuse of the access token during the validity period, the access permission configuration of the access token is updated after the token metadata associated with the access token is read, that is, the remaining usage times (counters) of the access token stored in the preset storage space are updated. To ensure efficient management of access tokens.
And after updating the access right configuration, reading the subroutine identification contained in the token metadata.
In addition, in this embodiment, the access right configuration of the access token is updated, and the number of times of edibility in the token metadata may be updated. Along the above example, m in "provider id+subroutine id+m (number of times of usable) +xx hour xx minute" is updated to obtain token metadata "provider id+subroutine id+m-1+xx hour xx minute" associated with an access token.
Step S108, issuing the sub-program identifier to the Demo application, so as to load the target sub-program in the Demo application based on the sub-program identifier.
Optionally, the Demo application is an access container of the target subroutine; and after receiving the subprogram identification, the Demo application determines a code segment of the target subprogram, and loads the target subprogram based on the code segment so as to enable the equipment provider to perform access test on the target subprogram.
In the implementation, the sub-program identification is issued to the Demo application, so that the Demo application loads the code segment corresponding to the sub-program identification, the Demo application runs the target sub-program, and the equipment provider tests the target sub-program.
In this embodiment, idempotent verification is performed on access tokens submitted by the same device provider to the target subprogram in a short time, the same access token is returned to the device provider based on a token generation request of the device provider in an effective time interval, and the device provider is allowed to use the same access token to access the target subprogram in the effective time interval, so that the same device provider is prevented from repeatedly applying for a plurality of access tokens, and further token diffusion is caused.
When the method is implemented, the equipment provider tests the target subprogram and puts the target subprogram into the equipment to-be-shipped equipment sold to the equipment user after the test is passed; optionally, after the test is passed, the target subroutine installs and configures the release application corresponding to the Demo application to the equipment to be shipped; the publishing application runs the subroutines in the subroutine pool; the target subroutine is written to the subroutine pool after the test passes.
In order to ensure that the device provider effectively manages the subroutines to be configured by the factory device, an optional implementation manner provided in this embodiment is that:
determining a subscription scene selected by the equipment provider for the equipment to be shipped;
Returning a subroutine list associated with the subscription scene to the equipment provider;
associating the target subroutine selected by the device provider in the subroutine list to the subscription scenario;
pushing the code segments of the target subroutine to the subroutine pool.
Specifically, the device provider selects a subscription scene for the device to be shipped, then selects a subprogram in the subscription scene put in the device to be shipped in a subprogram list corresponding to the subscription scene, and pushes code fragments of the target subprogram to the subprogram pool under the condition that the device provider selects the target subprogram.
The application of the subroutine loading processing method provided in this embodiment to the subroutine test access scenario is taken as an example, and the subroutine loading processing method provided in this embodiment is further described, and the subroutine loading processing method of the subroutine test access scenario is further described with reference to fig. 2.
Before testing the sub-program, the device manufacturer obtains an access token;
the process of obtaining the access token specifically comprises the following steps:
(1) The equipment manufacturer logs in an open platform and searches a target subprogram;
(2) The open platform sends the logged manufacturer identification and the subroutine identification obtained after searching to the equipment platform, and the equipment platform generates an access token.
After the device platform generates the access token, the device platform returns to the open platform, and the open platform sends the access token to the device manufacturer.
Before the equipment manufacturer tests through the terminal equipment, the Demo application is downloaded through the open platform and installed on the terminal equipment, after the equipment manufacturer inputs the access token through the Demo application, the equipment platform acquires the access token input by the equipment manufacturer and verifies the access token, and returns the subprogram identification of the target subprogram contained in the token metadata associated with the access token to the Demo application under the condition that the verification is passed, so that the Demo application loads the corresponding code fragment and opens the target subprogram.
The following description of the access token generation process provided in this embodiment refers to fig. 3, and specifically includes steps S302 to S314.
In step S302, a token generation request carrying a provider identifier and a subroutine identifier submitted by a device provider is obtained.
Step S304, inquiring the access token in the effective time interval based on the provider identification and the subprogram identification;
If yes, the access token is returned to the equipment provider idempotent;
if not, go to step S306 to step S314.
Step S306, constructing token metadata based on the provider identification, the subroutine identification, the preset valid time condition and the preset valid times.
And step S308, carrying out encryption processing through a message digest algorithm according to the token metadata and the encryption salt value to obtain an access token.
In step S310, the access token is taken as a primary key, the token metadata is taken as a key value to construct a key value pair, and the key value pair is stored in the cache.
Wherein the cache counts and counts key-value pairs.
In step S312, an association relationship of the provider identifier, the subroutine identifier, and the access token is established and stored in the token record table.
Step S314, the access token is returned to the device provider.
The application of the sub-program loading processing method provided in the present embodiment to the sub-program access scene is taken as an example, and the sub-program loading processing method provided in the present embodiment is further described below, referring to fig. 4, and the sub-program loading processing method applied to the sub-program access scene specifically includes steps S402 to S414.
Step S402, obtaining an access token input by a device provider submitted by a Demo application installed by a terminal device.
Step S404, checking whether the access token stored in the cache is in a valid time interval;
If yes, go to step S406;
If not, sending a verification failure prompt to the equipment terminal.
Step S406, checking whether the effective use times of the access tokens stored in the cache is 0;
If yes, sending a verification failure prompt to the equipment terminal;
If not, go to step S408 to step S414.
In step S408, the token metadata associated with the access token stored in the cache is read.
Step S410, updating the effective use times of the access token in the cache.
In step S412, the subroutine identifier contained in the token metadata is read.
In step S414, the subroutine identifier is issued to the Demo application, so that the corresponding target subroutine is loaded in the Demo application.
In summary, in the method for loading and processing a subroutine provided in this embodiment, in the first aspect, the open platform obtains a provider identifier of a device provider logging in the open platform, and after obtaining a subroutine identifier obtained after searching search information by the device provider, sends a token request to the device platform based on the provider identifier and the subroutine identifier;
According to the second aspect, the equipment platform inquires whether an access token which is associated with the provider identifier and the subprogram identifier exists in a token record table or not based on the token request, and if the access token exists in the effective time interval, the access token is sent to the open platform, and the ceremony open platform returns to the equipment provider at idempotent; if the access token does not exist, firstly constructing token metadata based on the provider identification, the subroutine identification and the preset token condition, and then encrypting the token metadata by utilizing an encryption algorithm to obtain the access token; storing key value pairs constructed by the access token and the token metadata in a cache with counting and timing functions for effective verification; in addition, the association relation among the provider identifier, the subprogram identifier and the access token is stored in a token record table, the association relation in the token record is effectively time-stamped according to time conditions in preset token conditions, so that when a subsequent device provider makes a token request for a target subprogram, the query is performed, and finally the generated access token is returned to the device provider through an open platform;
In a third aspect, a device provider downloads a Demo application through an open platform and installs the Demo application on a terminal device so as to perform test access of a sub-target sub-program through the Demo application, the open platform inputs a returned access token through the Demo application, the open platform sends the access token to the device platform, the device platform inquires whether a key value pair corresponding to the access token exists in a cache after receiving the access token, and if the key value pair does not exist, the open platform sends a verification failure prompt to the device provider; if the access token exists, the effective use times of the key value pair stored in the cache are updated, the token metadata (key value) in the key value pair are read, and the subroutine identification in the token metadata is issued to the Demo application through the open platform, so that the target subroutine is loaded in the Demo application, the effective time and the effective times of the access token are set, the repeated application of the access token by the equipment provider is avoided, the abuse of the access token is avoided, and the safe use of the access token is ensured.
An embodiment of a subroutine loading processing apparatus provided in the present specification is as follows:
in the above-described embodiments, a subroutine loading processing method is provided, and a subroutine loading processing apparatus is provided correspondingly, which will be described below with reference to the accompanying drawings.
Referring to fig. 5, a schematic diagram of a subroutine loading processing apparatus according to the present embodiment is shown.
Since the apparatus embodiments correspond to the method embodiments, the description is relatively simple, and the relevant portions should be referred to the corresponding descriptions of the method embodiments provided above. The device embodiments described below are merely illustrative.
The present embodiment provides a subroutine loading processing apparatus, including:
A token acquisition module 502 configured to acquire an access token input by a device provider submitted by a Demo application installed by a terminal device; the access token is generated based on an access request submitted by the device provider for a target subroutine;
if the access token is stored in the preset storage space, a metadata reading module 504 is operated, and the metadata reading module 504 is configured to read the token metadata associated with the access token;
An identifier reading module 506, configured to update the access right configuration of the access token, and read a subroutine identifier contained in the token metadata;
An identifier issuing module 508 configured to issue the sub-program identifier to the Demo application to load the target sub-program at the Demo application based on the sub-program identifier.
An embodiment of a subroutine loading processing apparatus provided in the present specification is as follows:
In response to the above description of a subroutine loading processing method, one or more embodiments of the present disclosure further provide a subroutine loading processing apparatus for executing the above-provided subroutine loading processing method, and fig. 6 is a schematic structural diagram of a subroutine loading processing apparatus according to one or more embodiments of the present disclosure, based on the same technical concept.
The subroutine loading processing apparatus provided in this embodiment includes:
As shown in fig. 6, the subroutine loading processing apparatus may have a relatively large difference due to different configurations or performances, and may include one or more processors 601 and a memory 602, and one or more storage applications or data may be stored in the memory 602. Wherein the memory 602 may be transient storage or persistent storage. The application programs stored in the memory 602 may include one or more modules (not shown) each of which may include a series of computer executable instructions in the subroutine load processing device. Still further, the processor 601 may be arranged to communicate with the memory 602, executing a series of computer executable instructions in the memory 602 on a subroutine loading processing device. The subroutine loading processing apparatus may further include one or more power supplies 603, one or more wired or wireless network interfaces 604, one or more input/output interfaces 605, one or more keyboards 606, and the like.
In a particular embodiment, a subroutine load processing apparatus includes a memory, and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions in the subroutine load processing apparatus, and being configured to be executed by the one or more processors, the one or more programs including computer-executable instructions for:
Acquiring an access token input by a device provider submitted by a Demo application installed by a terminal device; the access token is generated based on an access request submitted by the device provider for a target subroutine;
if the access token is stored in the preset storage space, reading the token metadata associated with the access token;
Updating the access right configuration of the access token and reading the subroutine identification contained in the token metadata;
And issuing the subprogram identification to the Demo application so as to load the target subprogram on the Demo application based on the subprogram identification.
An embodiment of a storage medium provided in the present specification is as follows:
corresponding to a subroutine loading processing method described above, one or more embodiments of the present specification further provide a storage medium based on the same technical idea.
The storage medium provided in this embodiment is configured to store computer executable instructions that, when executed by a processor, implement the following flow:
Acquiring an access token input by a device provider submitted by a Demo application installed by a terminal device; the access token is generated based on an access request submitted by the device provider for a target subroutine;
if the access token is stored in the preset storage space, reading the token metadata associated with the access token;
Updating the access right configuration of the access token and reading the subroutine identification contained in the token metadata;
And issuing the subprogram identification to the Demo application so as to load the target subprogram on the Demo application based on the subprogram identification.
It should be noted that, in the present specification, the embodiment about the storage medium and the embodiment about the subroutine loading processing method in the present specification are based on the same inventive concept, so that the specific implementation of this embodiment may refer to the implementation of the corresponding method, and the repetition is not repeated.
The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
In the 30 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable GATE ARRAY, FPGA)) is an integrated circuit whose logic functions are determined by user programming of the device. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented with "logic compiler (logic compiler)" software, which is similar to the software compiler used in program development and writing, and the original code before being compiled is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but HDL is not just one, but a plurality of kinds, such as ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language), and VHDL (very-high-SPEED INTEGRATED Circuit Hardware Description Language) and verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.
The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application SPECIFIC INTEGRATED Circuits (ASICs), programmable logic controllers, and embedded microcontrollers, examples of controllers include, but are not limited to, the following microcontrollers: ARC625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
For convenience of description, the above devices are described as being functionally divided into various units, respectively. Of course, the functions of each unit may be implemented in the same piece or pieces of software and/or hardware when implementing the embodiments of the present specification.
One skilled in the relevant art will recognize that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
The present description is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the specification. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.
One or more embodiments of the present specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments.
The foregoing description is by way of example only and is not intended to limit the present disclosure. Various modifications and changes may occur to those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. that fall within the spirit and principles of the present document are intended to be included within the scope of the claims of the present document.
Claims (9)
1. A method of sub-program load handling, comprising:
Acquiring an access token input by a device provider submitted by a Demo application installed by a terminal device; the access token is generated based on an access request submitted by the device provider for a target subroutine; the Demo application is an access container of the target subroutine; the access token is generated by adopting the following modes: based on a provider identifier obtained after the equipment provider performs login operation and a subroutine identifier obtained after searching search information in a search request submitted by the equipment provider, inquiring whether an effective access token exists in an effective time interval in a token record table; if yes, determining the effective access token as the access token; if not, based on the provider identification of the equipment provider, the subprogram identification and a preset token condition, constructing the token metadata of the equipment provider aiming at the target subprogram, and carrying out encryption processing on the token metadata according to an encryption algorithm to obtain the access token;
if the access token is stored in the preset storage space, reading the token metadata associated with the access token;
updating the access right configuration of the access token and reading the subroutine identification contained in the token metadata;
And issuing the subprogram identification to the Demo application so as to load the target subprogram on the Demo application based on the subprogram identification.
2. The sub program loading processing method according to claim 1, wherein the Demo application determines a code segment of the target sub program after receiving the sub program identification, and loads the target sub program based on the code segment, so that the device provider performs access test on the target sub program.
3. The subroutine loading method according to claim 1, said encrypting said token metadata according to an encryption algorithm, after said step of obtaining said access token is performed, further comprising:
creating a key value pair by taking the access token as a primary key and taking the token metadata as a key value, and storing the key value pair in the preset storage space;
establishing an association relationship among the provider identification of the equipment provider, the subroutine identification and the access token;
And storing the association relation in a token record table and marking the effective time.
4. The subroutine loading processing method according to claim 1, said access token being stored in said preset storage space for a valid time; the preset storage space comprises a cache;
if the effective time is exceeded, deleting the access token from the preset storage space;
and/or the number of the groups of groups,
And if the effective times in the access right configuration are updated to be zero, deleting the access token from the preset storage space.
5. The subroutine load processing method according to claim 2, said Demo application being for running said target subroutine, said Demo application being configured with an access portal of said target subroutine;
After the target subprogram passes the test, the release application corresponding to the Demo application is installed and configured to the equipment to be shipped; the release application is used for running the subprograms in the subprogram pool; the target subroutine is written to the subroutine pool after the test passes.
6. The subroutine load handling method according to claim 5, said target subroutine being written to said subroutine pool by:
determining a subscription scene selected by the equipment provider for the equipment to be shipped;
Returning a subroutine list associated with the subscription scene to the equipment provider;
associating the target subroutine selected by the device provider in the subroutine list to the subscription scenario;
And pushing the code fragments of the target subprogram to the subprogram pool through a data link.
7. A subroutine loading processing apparatus comprising:
The token acquisition module is configured to acquire an access token input by a device provider submitted by a Demo application installed by the terminal device; the access token is generated based on an access request submitted by the device provider for a target subroutine; the Demo application is an access container of the target subroutine; the access token is generated by adopting the following modes: based on a provider identifier obtained after the equipment provider performs login operation and a subroutine identifier obtained after searching search information in a search request submitted by the equipment provider, inquiring whether an effective access token exists in an effective time interval in a token record table; if yes, determining the effective access token as the access token; if not, based on the provider identification of the equipment provider, the subprogram identification and a preset token condition, constructing the token metadata of the equipment provider aiming at the target subprogram, and carrying out encryption processing on the token metadata according to an encryption algorithm to obtain the access token;
If the access token is stored in the preset storage space, a metadata reading module is operated, and the metadata reading module is configured to read the token metadata associated with the access token;
The identification reading module is configured to update the access right configuration of the access token and read the subroutine identification contained in the token metadata;
and the identification issuing module is configured to issue the subprogram identification to the Demo application so as to load the target subprogram on the Demo application based on the subprogram identification.
8. A subroutine loading processing apparatus comprising:
A processor; and
A memory configured to store computer-executable instructions that, when executed, cause the processor to:
Acquiring an access token input by a device provider submitted by a Demo application installed by a terminal device; the access token is generated based on an access request submitted by the device provider for a target subroutine; the Demo application is an access container of the target subroutine; the access token is generated by adopting the following modes: based on a provider identifier obtained after the equipment provider performs login operation and a subroutine identifier obtained after searching search information in a search request submitted by the equipment provider, inquiring whether an effective access token exists in an effective time interval in a token record table; if yes, determining the effective access token as the access token; if not, based on the provider identification of the equipment provider, the subprogram identification and a preset token condition, constructing the token metadata of the equipment provider aiming at the target subprogram, and carrying out encryption processing on the token metadata according to an encryption algorithm to obtain the access token;
if the access token is stored in the preset storage space, reading the token metadata associated with the access token;
updating the access right configuration of the access token and reading the subroutine identification contained in the token metadata;
And issuing the subprogram identification to the Demo application so as to load the target subprogram on the Demo application based on the subprogram identification.
9. A storage medium storing computer-executable instructions that when executed by a processor implement the following:
Acquiring an access token input by a device provider submitted by a Demo application installed by a terminal device; the access token is generated based on an access request submitted by the device provider for a target subroutine; the Demo application is an access container of the target subroutine; the access token is generated by adopting the following modes: based on a provider identifier obtained after the equipment provider performs login operation and a subroutine identifier obtained after searching search information in a search request submitted by the equipment provider, inquiring whether an effective access token exists in an effective time interval in a token record table; if yes, determining the effective access token as the access token; if not, based on the provider identification of the equipment provider, the subprogram identification and a preset token condition, constructing the token metadata of the equipment provider aiming at the target subprogram, and carrying out encryption processing on the token metadata according to an encryption algorithm to obtain the access token;
if the access token is stored in the preset storage space, reading the token metadata associated with the access token;
updating the access right configuration of the access token and reading the subroutine identification contained in the token metadata;
And issuing the subprogram identification to the Demo application so as to load the target subprogram on the Demo application based on the subprogram identification.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210128063.XA CN114443173B (en) | 2022-02-11 | 2022-02-11 | Subroutine loading processing method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210128063.XA CN114443173B (en) | 2022-02-11 | 2022-02-11 | Subroutine loading processing method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114443173A CN114443173A (en) | 2022-05-06 |
| CN114443173B true CN114443173B (en) | 2024-04-19 |
Family
ID=81371270
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210128063.XA Active CN114443173B (en) | 2022-02-11 | 2022-02-11 | Subroutine loading processing method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114443173B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6633981B1 (en) * | 1999-06-18 | 2003-10-14 | Intel Corporation | Electronic system and method for controlling access through user authentication |
| CN113282833A (en) * | 2021-06-15 | 2021-08-20 | 支付宝(杭州)信息技术有限公司 | Ticket processing method and device |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7650600B2 (en) * | 2005-06-20 | 2010-01-19 | Microsoft Corporation | Unique identifier resolution interfaces for lightweight runtime identity |
| US9268873B2 (en) * | 2006-08-04 | 2016-02-23 | Yahoo! Inc. | Landing page identification, tagging and host matching for a mobile application |
| US11494484B2 (en) * | 2016-10-24 | 2022-11-08 | Nubeva, Inc. | Leveraging instrumentation capabilities to enable monitoring services |
| US10554641B2 (en) * | 2017-02-27 | 2020-02-04 | International Business Machines Corporation | Second factor authorization via a hardware token device |
| US11050560B2 (en) * | 2019-09-27 | 2021-06-29 | International Business Machines Corporation | Secure reusable access tokens |
-
2022
- 2022-02-11 CN CN202210128063.XA patent/CN114443173B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6633981B1 (en) * | 1999-06-18 | 2003-10-14 | Intel Corporation | Electronic system and method for controlling access through user authentication |
| CN113282833A (en) * | 2021-06-15 | 2021-08-20 | 支付宝(杭州)信息技术有限公司 | Ticket processing method and device |
Non-Patent Citations (1)
| Title |
|---|
| 对等式令牌测控网络的设计与实现;虞耀君;王晓红;张幼明;;微计算机信息;20070823(第23期);51-53页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114443173A (en) | 2022-05-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103049692B (en) | A kind of application installation method, device and equipment | |
| CN113014568B (en) | Account login method, equipment and server | |
| CN111651734B (en) | Installation management method, device, equipment and system for applet | |
| CN112200585B (en) | Service processing method, device, equipment and system | |
| WO2023151439A1 (en) | Account login processing | |
| CN114745133B (en) | Method and device for identifying equipment uniqueness | |
| CN111400681A (en) | Data permission processing method, device and equipment | |
| CN111753291B (en) | Application container creating method, device and equipment | |
| CN114546639B (en) | Service call processing method and device | |
| CN110059476B (en) | Application access method, device and equipment | |
| CN111338655A (en) | Installation package distribution method and system | |
| CN114443173B (en) | Subroutine loading processing method and device | |
| WO2023216872A1 (en) | Event processing method and apparatus applied to iot device | |
| CN114500300B (en) | Service registration processing method and device | |
| WO2023151440A1 (en) | Program update processing | |
| CN111796864A (en) | Data verification method and device | |
| CN111259430A (en) | Data processing method and device, electronic equipment and computer storage medium | |
| CN113672784B (en) | Vehicle information processing method, device and system based on block chain | |
| CN112100610B (en) | Processing method, device and equipment for login and user login related services | |
| CN113497805B (en) | Registration processing method, device, equipment and system | |
| CN114546524B (en) | Application authority processing method and device | |
| CN111581612B (en) | Login state data processing method, device, equipment and system of applet application | |
| CN111954172A (en) | Information sending method and device | |
| CN112861187A (en) | Data processing method and device based on block chain | |
| CN117520185A (en) | Program update test method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |