Verification method, device, equipment, medium and program product

Abstract

The present disclosure provides a verification method for a verification party, which can be applied to the field of information security technology. The method comprises: in response to a first upload operation of a user on a specific upload portal of a use party, obtaining a user resource uploaded by the user; verifying the user resource according to a verification rule of the specific upload portal, wherein the use party is configured to pre-configure N verification rules corresponding to N upload portals in the verification party one by one, N being an integer greater than or equal to 1; and sending a verification result of the user resource to the use party.

Description

Technical Field

[0001] This disclosure relates to the field of information security, and more specifically, to verification methods, apparatus, equipment, media, and program products. Background Technology

[0002] Some software allows users to select different types of resources such as audio, video, and images for uploading as needed. It can implement attribute checks such as size, length, and width limits for specific file types through configuration files or database settings. These software programs may have multiple upload entry points, each used for uploading different types of resources, or resources of the same type with different attribute limits.

[0003] In the process of realizing the inventive concept disclosed herein, the inventors discovered that different upload entry points have their own verification requirements. Currently, a unified verification configuration is usually set for all upload entry points, which cannot accurately adapt to the verification requirements of each upload entry point, and may result in the upload of disallowed resources. Summary of the Invention

[0004] In view of the above problems, this disclosure provides verification methods, apparatus, devices, media and program products.

[0005] According to a first aspect of this disclosure, a verification method for a verification party is provided, characterized by comprising: in response to a user's first upload operation at a specific upload entry of the verification party, obtaining user resources uploaded by the user; verifying the user resources according to the verification rules of the specific upload entry, wherein the verification party is configured to pre-configure N verification rules corresponding one-to-one for N upload entries in the verification party, where N is an integer greater than or equal to 1; and sending the verification result of the user resources to the verification party.

[0006] According to embodiments of this disclosure, the step of obtaining the user resources in response to a first upload operation by a user at a specific upload entry of the user includes: displaying an upload page to the user in response to receiving a verification call request from the user, wherein the user is configured to issue the verification call request in response to the first upload operation; and obtaining the user resources in response to a second upload operation by the user on the upload page.

[0007] According to embodiments of this disclosure, the upload page displayed to the user has a mapping relationship with the verification rules of the specific upload entry. Before displaying the upload page to the user, the method further includes: receiving a rule configuration request from the user for any of the upload entries, the rule configuration request including the verification rules of the corresponding upload entry; in response to the rule configuration request, generating an upload page applicable to the corresponding upload entry, and storing the mapping relationship between each upload page and the verification rules of its corresponding upload entry.

[0008] According to embodiments of this disclosure, the rule configuration request further includes the user's authentication information. Before receiving the user's rule configuration request for any of the upload entry points, the method further includes: receiving the user's token call request; generating a first token value for the user in response to the token call request; and sending the first token value to the user, wherein the user is configured to obtain the authentication information based on the first token value.

[0009] According to an embodiment of this disclosure, generating an upload page suitable for the corresponding upload entry in response to the rule configuration request includes: obtaining the user's authentication information from the rule configuration request, the authentication information including the user's identifier and a first signature obtained based on the identifier, the first token value, and the verification rules of the corresponding upload entry; verifying the authentication information; and, if the verification passes, generating an upload page suitable for the corresponding upload entry and storing the mapping relationship between each upload page and the authentication information of its corresponding upload entry.

[0010] According to embodiments of this disclosure, the verification rules for the specific upload entry include M verification conditions corresponding one-to-one with M resource types, where M is an integer greater than or equal to 1; verifying the user resources according to the verification rules for the specific upload entry includes: verifying the user resources at the front end according to the M verification conditions; and / or, verifying the user resources at the back end according to the M verification conditions.

[0011] According to an embodiment of this disclosure, verifying the user resource at the front end based on the M verification conditions includes: determining the user resource type and resource attribute value at the front end; and verifying the resource attribute value at the front end based on the verification conditions corresponding to the user resource type.

[0012] According to an embodiment of this disclosure, before verifying the user resource on the backend according to the verification rules of the specific upload entry, the method further includes: instructing the frontend to send a backend verification request to the backend, the backend verification request including the user resource type and resource attribute value, the user's identity identifier, the verification rules of the specific upload entry, and a second signature, wherein the second signature is obtained by the frontend encrypting the user resource type and resource attribute value, the user's identity identifier, and the verification rules of the specific upload entry according to a first encryption algorithm; executing the first encryption algorithm on the backend to encrypt the user resource type and resource attribute value, the user's identity identifier, and the verification rules of the specific upload entry to obtain an encryption result; verifying the second signature according to the encryption result, wherein the verifier is configured to verify the user resource on the backend according to the verification rules of the specific upload entry if the second signature verification passes.

[0013] According to an embodiment of this disclosure, verifying the user resource in the backend according to the verification rules of the specific upload entry includes: determining the user resource type and resource attribute value in the backend; and verifying the resource attribute value in the backend according to the verification conditions corresponding to the user resource type.

[0014] According to embodiments of this disclosure, the step of returning the verification result of the user resource to the user is as follows: if the verification result is a failure, an event message indicating a verification failure is returned to the user; if the verification result is a success, the user resource is uploaded to the user, and an event message indicating a successful verification is returned.

[0015] According to an embodiment of this disclosure, the verification party is configured to communicate with S users, where S is an integer greater than or equal to 1; the step of obtaining the user resources uploaded by the user in response to a first upload operation by the user at a specific upload entry of the user includes: obtaining the user resources in response to a first upload operation by the user at any one of the S users at a specific upload entry.

[0016] Another aspect of this disclosure provides a verification method for a user, comprising: in response to a user's first upload operation at a specific upload entry, sending a verification call request to a verification party, wherein the verification party is configured to perform a method as described above for verifying user resources uploaded by the user; and receiving a verification result of the user resources sent by the verification party.

[0017] Another aspect of this disclosure provides a verification device for a verification party, comprising: a resource acquisition module, configured to acquire user resources uploaded by the user in response to a first upload operation by a user at a specific upload entry of the user party; a resource verification module, configured to verify the user resources according to the verification rules of the specific upload entry, wherein the user party is configured to pre-configure N verification rules for N upload entries corresponding one-to-one, where N is an integer greater than or equal to 1; and a verification result module, configured to send the verification result of the user resources to the user party.

[0018] Another aspect of this disclosure provides a verification device for a user, comprising: a request sending module, configured to send a verification call request to a verification party in response to a user's first upload operation at a specific upload entry, the verification party being configured to execute a method as described above to verify the user resources uploaded by the user; and a result receiving module, configured to receive the verification result of the user resources sent by the verification party.

[0019] Another aspect of this disclosure provides an electronic device, including: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors perform the method as described above.

[0020] Another aspect of this disclosure provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, causes the processor to perform the method described above.

[0021] Another aspect of this disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the method described above.

[0022] The above one or more embodiments have the following beneficial effects: The resource verification function is abstracted from the user's local storage, allowing a verification party to perform the verification. The verification party obtains user-uploaded resources and performs resource verification according to the verification rules corresponding to each upload entry pre-configured by the user, then sends the verification results to the user. This allows users to adjust the verification rules of existing upload entries as needed, and also allows them to independently add new resource upload entries and verification rules, improving the user's ability to flexibly configure verification rules for each upload entry. Attached Figure Description

[0023] The foregoing contents, as well as other objects, features, and advantages of this disclosure, will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0024] Figure 1This illustration schematically depicts an application scenario of a verification method for a user or verifier according to embodiments of the present disclosure.

[0025] Figure 2 The diagram schematically illustrates a flowchart of a verification method for a verification party according to an embodiment of the present disclosure;

[0026] Figure 3 The diagram illustrates a flowchart of obtaining user resources according to an embodiment of the present disclosure.

[0027] Figure 4 A flowchart illustrating rule configuration according to an embodiment of this disclosure is shown schematically;

[0028] Figure 5 A flowchart illustrating the generation of an upload page according to an embodiment of the present disclosure is shown schematically;

[0029] Figure 6 This illustration schematically shows a flowchart of front-end verification of user resources according to an embodiment of the present disclosure;

[0030] Figure 7 This illustration schematically shows a flowchart of backend verification of user resources according to an embodiment of the present disclosure;

[0031] Figure 8 A flowchart illustrating a verification method for a user according to an embodiment of this disclosure is shown schematically.

[0032] Figure 9 A flowchart illustrating a verification method based on the interaction between the user and the verifier according to an embodiment of the present disclosure is shown schematically.

[0033] Figure 10 This schematically illustrates a structural block diagram of a verification apparatus for a verification party according to an embodiment of the present disclosure;

[0034] Figure 11 This schematically illustrates a structural block diagram of a verification device for a user according to an embodiment of the present disclosure;

[0035] Figure 12 A block diagram schematically illustrates an electronic device suitable for implementing a verification method for a verification party or user, according to an embodiment of the present disclosure. Detailed Implementation

[0036] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0037] In the technical solution of this invention, the user information (including but not limited to user resources, user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation upload portals for users to choose to authorize or refuse.

[0038] In scenarios involving automated decision-making using personal information, the methods, devices, and systems provided in this invention offer users corresponding entry points for choosing to agree to or reject the automated decision-making results. If the user chooses to reject, the process proceeds to the expert decision-making stage. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making a decision. Here, "expert decision-making" refers to the activity of making decisions by personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0039] In related technologies, software providing upload entry points can use upload components to implement resource upload functionality. Upload components can provide verification functions. Existing upload components support users selecting different types of resources such as audio, video, and images for upload as needed. They can also be configured uniformly across various upload entry points via configuration files or database configurations, meaning all upload entry points can be configured with the same verification rules to implement verification of attribute limits such as size, length, and width for specific file types. For example, configuration files can restrict image resources to a minimum upload size of 1MB and a maximum of 5MB.

[0040] However, the user's own system may support various resource upload entry points. For example, the upload entry point may be set according to different scenarios. Scenario A requires restricting image uploads to horizontal format (640px wide and 360px high), while scenario B requires restricting image uploads to vertical format (268px wide and 310px high). Furthermore, the upload entry point of the user's own system may be frequently adjusted. If attribute validation values ​​for different resource types in different scenarios are still set through configuration, it is not conducive to the user's self-expansion and also increases the maintenance cost of the upload component.

[0041] This disclosure provides several embodiments that offer verification methods for both the user and the verification party, abstracting the resource verification function from the user's local storage and allowing the verification party to perform the verification. The verification party obtains user-uploaded resources and performs resource verification according to the verification rules pre-configured by the user for each upload entry, then sends the verification results to the user. This allows users to adjust the verification rules for existing upload entries as needed, and also enables them to add new resource upload entries and verification rules, improving their ability to flexibly configure verification rules for each upload entry.

[0042] Figure 1 The illustration schematically depicts an application scenario of a verification method for a user or verifier according to embodiments of the present disclosure. It should be noted that... Figure 1 The examples shown are merely examples to illustrate the application of the embodiments of this disclosure, in order to help those skilled in the art understand the technical content of this disclosure. However, they do not mean that the embodiments of this disclosure cannot be used in other devices, systems, environments, or scenarios.

[0043] like Figure 1 As shown, application scenario 100 according to this embodiment may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as a medium for providing a communication link between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0044] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0045] Terminal devices 101, 102, and 103 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers. Users can upload resources using the clients or browsers provided by terminal devices 101, 102, and 103.

[0046] Server 105 can be a server providing various services, such as a backend management server supporting websites browsed by users using terminal devices 101, 102, and 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices. For example, server 105 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud computing, network services, and middleware services.

[0047] It should be noted that the verification method for the verification party or user provided in the embodiments of this disclosure can generally be executed by at least one of the terminal device or the server. Accordingly, the verification device for the verification party or user provided in the embodiments of this disclosure can generally be provided in at least one of the terminal device or the server.

[0048] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0049] The following will be based on Figure 1 The described scene, through Figures 2-9 The verification method of the present disclosure embodiments will be described in detail.

[0050] Figure 2 The diagram schematically shows a flowchart of a verification method for a verification party according to an embodiment of the present disclosure.

[0051] like Figure 2 As shown, this embodiment includes:

[0052] In operation S210, in response to the user's first upload operation at the user's specific upload entry, the user resources uploaded by the user are obtained.

[0053] In some embodiments, the verifier is configured to communicate with S users, where S is an integer greater than or equal to 1. Operation S210 can retrieve user resources in response to a user's first upload operation at any specific upload entry among the S users.

[0054] User resources include any form of data uploaded by users to the user platform. For example, users may upload images, audio, video, documents, spreadsheets, or other types of files as user resources. Specific upload entry points include specific parts of the user platform's website or application, such as buttons, input fields, etc. For example, on social media websites, a specific upload entry point might be a user's profile page where they can upload photos.

[0055] For example, the verifier can listen for click events at any of N upload entry points. Upon detecting the event, it sends a message to the user, including instructions on how to upload to a specific address. Another example is that the verifier can obtain user resources sent by the user, which are stored in a temporary database and then stored in the corresponding storage space by the user after successful verification. Yet another example is that the verifier can receive verification call requests from the user, as illustrated below. Figure 2 Further description.

[0056] In operation S220, user resources are verified according to the verification rules of a specific upload entry. The user is configured to pre-configure N verification rules for each of the N upload entries, where N is an integer greater than or equal to 1. Any one of the N upload entries can be a specific upload entry.

[0057] Validation rules include rules applicable to upload entry points, used to verify whether user resources meet specific conditions or attributes. For example, for an upload entry point that allows users to upload image files, the validation rules might require the file to be in a certain supported file format, such as .jpg or .png, and the file size to not exceed a specific limit. Validation can also be performed on file content, specific instructions, viruses, etc. N upload entry points refer to a user potentially having multiple upload entry points for users to upload their resources. Each upload entry point can have specific validation rules. For example, a file-sharing service might have one upload entry point accepting .doc files and another accepting .pdf files, each with its own specific validation rules. Any two upload entry points can have different validation rules, and each validation rule is set to suit the validation requirements of the upload entry point.

[0058] In operation S230, the verification result of the user resource is sent to the user.

[0059] The verification result includes a success or failure result after verifying the user resource, and will notify the user whether the user resource meets the application's verification rules. For example, the verification process may confirm that the image file is a valid .jpg file and that its size is within the allowed range.

[0060] Assuming the mobile banking app is the user, its identity authentication page provides two upload options: an ID card upload portal and a verification video upload portal. When the user clicks the upload button for the ID card, the verifier obtains an image of the user's ID card. The verification rules for this ID card upload portal are that it's an image and the file size must be less than 2MB. Similarly, when the user clicks the upload button for the verification video, the verifier obtains a liveness verification video of the user. The verification rules for this video upload portal are that it's a video and the file size must be less than 20MB. Once the verifier confirms that either the ID card image or the liveness verification video meets the verification rules, it sends the verification result to the user. Based on the verification result, the mobile banking app can choose to accept or reject the uploaded file.

[0061] According to embodiments of this disclosure, the resource verification function is abstracted from the user's local storage and performed by a verification party. The verification party obtains user-uploaded resources and performs resource verification according to the verification rules pre-configured by the user for each upload entry, then sends the verification results to the user. This allows users to adjust the verification rules for existing upload entries as needed, and also allows them to independently add new resource upload entries and verification rules, improving the user's ability to flexibly configure verification rules for each upload entry.

[0062] Figure 3 The diagram illustrates a flowchart of obtaining user resources according to an embodiment of the present disclosure.

[0063] like Figure 3 As shown, in operation S210, in response to the user's first upload operation at the user's specific upload entry, obtaining user resources includes:

[0064] In operation S310, in response to receiving a verification call request from the user, the upload page is displayed to the user, wherein the user is configured to issue a verification call request in response to the first upload operation.

[0065] The verification request is a request sent by the user after receiving the user's upload operation. It redirects the user to the upload page and displays the page to the user. The upload page allows users to upload their own resources. On this page, users may see options such as selecting a file and entering a filename.

[0066] In some embodiments, the verification request may be used solely to invoke the upload page. In other embodiments, for example, if the request includes information about the type of resource the user wishes to upload, the verifier may adjust the display of the upload page based on that information, displaying upload guidelines or options suitable for the specific resource type.

[0067] In operation S320, in response to the user's second upload operation on the upload page, user resources are retrieved.

[0068] The second upload operation includes actions performed by the user on the upload page, such as clicking the upload button to upload a file.

[0069] According to embodiments of this disclosure, user resources are not uploaded to the user before verification; instead, they are obtained directly by the verification party via the upload page. This saves the user's space and avoids the negative impact of being denied the right to upload resources.

[0070] Figure 4 A flowchart illustrating rule configuration according to an embodiment of this disclosure is shown schematically.

[0071] The upload page displayed to the user has a mapping relationship with the verification rules of a specific upload entry. Before displaying the upload page to the user, such as... Figure 4 As shown, this embodiment includes:

[0072] When operating S410, a rule configuration request is received from the user for any upload entry. The rule configuration request includes the verification rules for the corresponding upload entry.

[0073] The rule configuration request is used to set or change validation rules for the upload entry point. For any entry point, the validation provider allows users to send rule configuration requests adapted to that entry point. Allowing users to customize validation rules better meets their needs.

[0074] In operation S420, in response to the rule configuration request, an upload page suitable for the corresponding upload entry is generated, and the mapping relationship between each upload page and the verification rule of its corresponding upload entry is stored.

[0075] Upon receiving a rule configuration request, the validation party generates an upload page suitable for the corresponding entry point. Each entry point has an upload page that conforms to its validation rules. In some embodiments, at least two entry points may have the same validation rules, in which case these entry points can share the same page. Storing the mapping relationship allows users to know which validation rule should be applied when accessing the upload page at a specific upload entry point.

[0076] According to embodiments of this disclosure, a corresponding upload page is generated for each entry point, and the mapping relationship between this page and the verification rules of its corresponding entry point is stored. When verifying user resources, the upload page can be accurately displayed and the corresponding verification rules can be referenced, so as to better manage the verification rules of each entry point and provide targeted verification services.

[0077] In some embodiments, the rule configuration request also includes the user's authentication information. Before receiving the user's rule configuration request for any upload entry, the request further includes: receiving the user's token invocation request; generating a first token value for the user in response to the token invocation request; sending the first token value to the user, who is then configured to obtain authentication information based on the first token value.

[0078] For example, in the OAuth (Open Authorization, an authorization mechanism) protocol, the user first sends a request to the authenticator, requesting an access token. This request is called a token request. After receiving the token request, the authenticator generates an access token specific to the user and returns it; this is the first token value.

[0079] In some embodiments, one token corresponds to one entry point, which allows for better management of permissions for each entry point. In other embodiments, only one token may be needed, which can be used to configure multiple entry points, thus simplifying the management process.

[0080] According to embodiments of this disclosure, a token mechanism is used to verify the identity of the user, preventing unauthorized access and malicious configuration, and accurately identifying and receiving each user's rule configuration request.

[0081] Figure 5 A flowchart illustrating the generation of an upload page according to an embodiment of the present disclosure is shown schematically.

[0082] like Figure 5 As shown, in response to the rule configuration request, the upload page generated for the corresponding upload entry includes:

[0083] When operating S510, the user's authentication information is obtained from the rule configuration request. The authentication information includes the user's identifier and the first signature obtained based on the identifier, the first token value, and the verification rules of the corresponding upload entry.

[0084] The user's identifier is used to represent the user's identity, such as the user ID. The first signature is a unique identifier obtained based on the user's identifier, the first token value, and the corresponding entry verification rules, and can be generated using hashing or other encryption algorithms.

[0085] When operating the S520, verify the authentication information.

[0086] The verifier can execute the same encryption algorithm as the user, obtain the encryption result based on the user's identifier, the first token value, and the verification rules of the corresponding entry, and compare it with the first signature.

[0087] When operating S530, if verification passes, an upload page suitable for the corresponding upload entry is generated, and the mapping relationship between each upload page and its corresponding upload entry's authentication information is stored. If verification fails, service will be refused. For example, the upload page may include an identifier used to identify the corresponding upload entry, such as a hash value.

[0088] According to embodiments of this disclosure, by verifying authentication information, any unauthorized access attempts can be effectively prevented. An upload page suitable for a specific entry point can be generated based on the user's identity, achieving accurate configuration of verification rules.

[0089] In other embodiments, each upload entry can use a unified upload page, whereby the user encapsulates the verification rules corresponding to a specific upload entry in the verification call request.

[0090] In some embodiments, the verification rules for a specific upload entry point include M verification conditions corresponding one-to-one with M resource types, where M is an integer greater than or equal to 1, and each verification condition includes one or more verification values. Verifying user resources according to the verification rules for the specific upload entry point includes: verifying user resources on the front end based on the M verification conditions; and / or, verifying user resources on the back end based on the M verification conditions.

[0091] The M validation conditions include resource limit values, also known as checksums, that correspond one-to-one with M resource types. These are used for front-end or back-end user resource validation. Front-end validation refers to validation performed on the user interface (browser or client application, etc.). Back-end validation refers to validation performed on the server side.

[0092] When user resources are validated only on the front end, preliminary validation can be performed before the user submits the resources to the back end. If the resources do not meet the requirements, immediate feedback can be provided, avoiding invalid uploads, improving user experience, saving backend resources, and saving time on uploading non-compliant resources. When user resources are validated only on the back end, the resources required for front-end validation can be saved. When front-end validation passes and then the resources are sent to the back end for further validation, it can prevent the front-end instructions from being tampered with, causing unauthorized resources to pass validation. This dual front-end and back-end validation can better ensure that user-submitted resources are free of viruses and malicious code.

[0093] In some embodiments, for the same resource that a user submits frequently, a resource digest (e.g., a SHA-1 hash value) can be calculated after the first submission. When the user submits the same resource again, it is only necessary to calculate and compare the resource digest to determine whether the resources are the same, thus avoiding the verification process.

[0094] Figure 6The flowchart illustrating the front-end verification of user resources according to an embodiment of the present disclosure is shown schematically.

[0095] like Figure 6 As shown, this embodiment includes:

[0096] When operating S610, the user resource type and resource attribute value are determined on the front end.

[0097] The resource type can be determined based on the resource file's metadata and content characteristics, such as file extensions and header information. For example, an image file might have extensions like .jpg or .png, while an audio file might have extensions like .mp3 or .wav. This information can be used to determine the file type during upload. Then, based on the file type, corresponding attribute values ​​are obtained, such as image resolution and video duration. The same resource may have multiple validation conditions; for example, images can be validated based on size, pixels, and other dimensions, followed by a comprehensive judgment.

[0098] When operating the S620, the front end verifies the resource attribute values ​​based on the verification conditions corresponding to the user's resource type.

[0099] Checksums include limits used to verify whether a resource meets certain constraints. For example, a checksum might represent a range of file types or sizes. Resource attribute values ​​include characteristic parameters of the user resource, such as type and size.

[0100] For example, when a user uploads a file through a specific upload portal, the frontend first analyzes the file's type and attributes (e.g., it's an image file and its size is 2MB). Then, it compares this information with the validation criteria of the specific upload portal. If only image files smaller than 1MB are accepted, the user's file will fail to upload, thus ensuring server stability. If the resource attribute value fails validation, the frontend will provide a notification to the user. This notification could be a pop-up, text message, or icon, and might include the reason why the file could not be uploaded and the specific reason for the failure, such as "file too large" or "file format does not meet requirements."

[0101] According to embodiments of this disclosure, by performing resource verification at the front end, resources that do not meet the requirements can be detected and blocked in advance before user resources are uploaded to the server, thereby reducing the burden on the backend server, saving backend resources, and saving time for uploading resources that do not meet the requirements.

[0102] In some embodiments, before verifying user resources on the backend, based on the verification rules of a specific upload entry, the method further includes:

[0103] The front-end sends a back-end verification request to the back-end. The back-end verification request includes the user resource type and resource attribute value, the user's identity identifier, the verification rules for a specific upload entry, and a second signature. The second signature is obtained by the front-end encrypting the user resource type and resource attribute value, the user's identity identifier, and the verification rules for a specific upload entry according to the first encryption algorithm.

[0104] The first encryption algorithm is executed on the backend to encrypt the user resource type and resource attribute value, the user's identity identifier, and the verification rules of the specific upload entry, thus obtaining the encryption result.

[0105] The second signature is verified based on the encryption result. The verifier is configured to verify the user resource on the backend according to the verification rules of a specific upload entry if the second signature verification passes.

[0106] The first encryption algorithm includes encryption algorithms agreed upon by both the front-end and back-end to encrypt user resource information to obtain a signature, such as MD5 and SHA-1. The encryption result includes a signature value obtained by the back-end after encrypting certain data (including user resource information, user identity, and one or more verification rules for a specific entry point) by executing the first encryption algorithm. The first signature is compared with the encryption result calculated by the back-end; if they are the same, it proves the consistency and integrity of the data.

[0107] For example, when the verification party receives an audio file uploaded by a user, it first verifies basic attributes such as the audio file type and size on the front end. Simultaneously, it generates a signature based on the user and audio file information using an encryption algorithm. The front end then sends a verification request to the back end containing user file information (such as type and attribute values), user identifier, verification rules, and the signature. The back end first executes the same encryption algorithm to encrypt the same data, obtaining the encrypted result. It then compares the encrypted result with the signature in the request. If they match, it means the data has not been tampered with during transmission, and only then does the backend perform file verification according to the verification rules. If the signature verification fails, the backend considers the request illegal or tampered with and rejects it. For example, it returns an error code or error message to inform the front end or user that the request failed and explains the reason for the failure.

[0108] According to the embodiments of this disclosure, a signature is generated by encryption at the front end, and the same encryption process is performed at the back end to generate an encryption result. The two are compared, and if they match, it means that the information has not been tampered with during transmission, and the consistency and integrity of the data in the whole process are guaranteed.

[0109] Figure 7 A flowchart illustrating the backend verification of user resources according to an embodiment of this disclosure is shown.

[0110] like Figure 7 As shown, this embodiment includes:

[0111] When operating S710, the user resource type and resource attribute value are determined in the backend.

[0112] When operating the S720, the backend verifies the resource attribute values ​​based on the validation conditions corresponding to the user's resource type.

[0113] For example, a user uploads a PDF document through a specific upload portal. The backend parses the document's header information to determine if the resource is a PDF, and then reads information such as the document's page count and file size as resource attribute values. Based on one or more validation conditions for the specific upload portal, such as a file size not exceeding 10MB and a length not exceeding 100 pages, the backend compares the obtained resource attribute values—namely, file size and file length—with the set validation values ​​to see if the PDF document meets the requirements.

[0114] According to embodiments of this disclosure, user-uploaded resources can be verified on the backend to ensure they meet requirements. Furthermore, verifying the type and attribute values ​​of user resources guarantees their correctness and validity. This effectively prevents forgery and malicious attacks, increasing reliability and security.

[0115] In some embodiments, the verification result of the user resource is returned to the user: if the verification result is unsuccessful, a verification failure event is returned to the user; if the verification result is successful, the user resource is uploaded to the user, and a verification success event is returned.

[0116] According to embodiments of this disclosure, the user can listen for event messages in their own system and process the event messages as needed to achieve resource upload verification.

[0117] Figure 8 A flowchart illustrating a verification method for a user according to an embodiment of this disclosure is shown schematically.

[0118] like Figure 8 As shown, this embodiment includes:

[0119] In operation S810, in response to the user's first upload operation at a specific upload entry, a verification call request is sent to the verification party. The verification party is configured to execute an embodiment of the verification method executed by any of the above verification parties to verify the user resources uploaded by the user.

[0120] During operation of S820, the verification result of the user resources sent by the verification party is received.

[0121] According to embodiments of this disclosure, users can customize verification rules for each upload entry point (including existing and new entries) by integrating the verification function of the verification provider, such as setting new or updating rules. This facilitates uploaded resource verification, promotes functional expansion, and improves development efficiency and user experience.

[0122] Figure 9 A flowchart illustrating a verification method based on interaction between the user and the verifier according to an embodiment of the present disclosure is shown.

[0123] like Figure 9 As shown, this embodiment includes:

[0124] First, before configuring the resource upload entry, the user calls the token generation service of the verification party's backend service to realize the user's identity verification. The uploaded parameters include the user's code appID (provided by the verification party) and the user's key appSecret (provided by the verification party). The service verifies whether the parameter values ​​uploaded by the user are consistent with the information preset in the data storage function. If they are consistent, the identity verification is deemed to be successful, and an identity token is generated.

[0125] Next, the user obtains the token value and encapsulates it with the user identifier (appID), user token, resource type (fileType) (data dictionary: 1-image; 2-video; 3-audio), resource limit value (fileLimit), and data signature (sign). This is then sent to the verification party to invoke the backend service function for automatically generating the frontend page. The fileLimit parameter value must be encoded in the format "width limit_length limit_size limit". Different attribute limits can be flexibly configured. An empty attribute limit value indicates no limit for that type; it can be sent as 0. For example, fileLimit = 100_200_0 indicates a length limit of 200px, a width limit of 100px, and no size limit. The sign parameter value is used to prevent parameter hijacking and tampering. It can be based on MD5 or SHA256 algorithms and implemented using preset rules for data signing, such as sign = md5(appID=xxx&fileLimit=xxx&fileType=xxx&token=xxxx).

[0126] Next, the verification service can automatically generate a resource upload front-end page based on a preset template. For example, this service first verifies the token and sign. If the verification passes, the front-end upload function is executed, and the front-end upload page is returned. If the verification fails, a sign verification failure message is sent.

[0127] Next, if the verification fails, the user receives a parsing failure notification, can check the reason, and continue the call. If the verification succeeds, the user integrates the upload page.

[0128] Next, if the user performs the first upload operation through a specific upload entry point on the user's end, they will be redirected to the upload page corresponding to that entry point. Users can use the front-end upload function, that is, select the resource to be uploaded on the upload page and upload it. The upload page may include a resource selection component. The resource selection component allows users to select different types of resources from their local storage (such as folders on a PC's Windows operating system).

[0129] Next, the front-end validation function of the validation party is executed. The upload page can also include a resource display component and an upload operation component. After the front-end validation passes, the resource display component allows users to select and preview the file to be uploaded locally, allowing users to confirm whether the resource is truly ready to be uploaded. If the validation fails, a limit value validation failure notification is sent.

[0130] For example, the front-end validation function is used to verify the size and other attribute limits of uploaded resources. Users select local resource files through the resource selection component. The front-end validation function then parses the resource file to obtain its original size and other attribute values. Simultaneously, it parses the resource limit value (fileLimit) to obtain the limited size and other attribute values. If a certain type of limit value for the resource is greater than 0, a "limit value > original value" check is performed. If the check fails, the uploaded file is deemed to exceed the limit, and a validation failure event message is sent to the user's own system. If the check succeeds, the resource file will be displayed on the upload page. For example, if the user selects image 1, the parsed original width is 100px, the original height is 120px, and the size is 20KB. The user sends a fileLimit parameter value of 80_0_0, meaning the image is only limited to a maximum width of 80px, with no limit on length or size. Since the width limit value 80 < the original value 100, the image is considered to exceed the width limit, and a width validation failure event message must be sent.

[0131] After the user confirms the uploaded resource, the upload component sends a resource limit value verification request to the backend verification function. The parameters sent include the user's identity token, the original resource information `fileInfo`, the resource limit information `fileLimit`, and the signature parameter `sign`. The encoding format of the `fileInfo` and `fileLimit` parameters is like "width_height_size", and the `sign` parameter value can be implemented using preset rules based on algorithms such as MD5 or SHA256, e.g., `sign = md5(fileInfo=xxx&fileLimit=xxx&token=xxxx)`. Since the user cannot directly integrate the frontend upload function, this function is obtained by generating a corresponding page for each entry point. For example, the resource limit value `fileLimit` is encoded in the format "width limit_length limit_size limit", and the `sign` signature method is consistent with the backend service, e.g., `sign = md5(appID=xxx&fileLimit=xxx&fileType=xxx&token=xxxx)`.

[0132] Next, the backend verification function is executed. This backend verification function checks the attribute limits such as the width and height of the uploaded resource. When the user selects a resource to upload via the resource selection component on the upload page, the frontend verification function is executed first. If the frontend verification passes, the resource to be uploaded can be displayed through the echo component on the upload page. After the user previews and confirms that everything is correct, the upload operation component on the upload page sends a backend verification request to the backend verification function. During the execution of the backend verification function, the original resource information `fileInfo`, the resource limit information `fileLimit`, and the signature parameter `sign` are parsed.

[0133] The verification backend recalculates the `sign` value using a signature calculation method consistent with the frontend upload function (e.g., `sign = md5(fileInfo = xxx & fileLimit = xxx & token = xxxx)` and compares the results. If the `sign` values ​​are not equal, it indicates that the parameter has been tampered with, and a `sign` value verification failure event message must be issued. If the `sign` values ​​are the same, the `fileInfo` parameter value is parsed to obtain the original length, width, and size of the resource, and the `fileLimit` parameter value is parsed to obtain the resource limit length, width, and size values. Then, the pre-configured resource limit length, width, and size values ​​`fileMax` are obtained from the data storage function (not mandatory, configured by the user, only as a fallback verification). If the `fileLimit` limit value is greater than 0 and the data storage function limit value `fileMax` is greater than 0, then the original value of `fileInfo` must be less than or equal to both the `fileLimit` limit value and the maximum `fileMax` limit value. If the `fileLimit` limit value is greater than 0 and the maximum `fileMax` limit value is 0 or empty, then the original value of `fileInfo` must be less than or equal to the `fileLimit` limit value.

[0134] If the above limit value validation fails, the function will issue a corresponding attribute limit validation failure event notification. For example, if the resource's original information `fileInfo` value is 80_100_20 (indicating original width, height, and size values ​​of 100px, 80px, and 20KB respectively), the resource limit information `fileLimit` value is 100_120_50 (indicating width, height, and size limits of 120px, 100px, and 50KB respectively), and the maximum limit value configured for data storage is 200_200_0 (indicating a fallback value of 200px for both width and height, and no fallback value set for size), then the width validation must perform a comparison of 80 < 100 && 80 < 200, the length validation must perform a comparison of 100 < 120 && 100 < 200, and the size validation must perform a comparison of 20 < 50. If all the above validation values ​​pass, it indicates that the backend validation of the uploaded resource limit values ​​is successful, and the resource chunk upload service call can continue.

[0135] The data storage function pre-configures the user's identity information (appId) and key information (appSecret) for the uploading user. The user identity token generation service in the backend service can then use this configuration to authenticate the user. The data storage function also provides a fallback value configuration for user resource limits. Users can selectively configure one or more attribute limits as needed. If the user implements a fallback limit configuration in this function, the backend verification function will add a fallback value verification on top of the basic limit verification.

[0136] Then, once the backend verification passes all the restrictions on the uploaded resource, the upload operation component initiates a call to the resource chunk upload service in the backend service function to send the resource chunk content. The resource chunk upload service provides chunked upload of resource content. The upload parameters include the access party's appId, the resource chunk start offset startPoint, the resource chunk content fileItem, and the file type fileType. The service merges and stores each chunk content until the last chunk is written, ultimately generating a complete resource file.

[0137] Finally, the user resources were successfully uploaded to the user.

[0138] According to the verification method provided in this embodiment, which supports efficient integration and flexible verification, the user submits verification rules according to predetermined rules. The verification party then performs automatic front-end and back-end verifications based on the user's provided rules, and the verification results are notified to the user in the form of event messages. If both front-end and back-end verifications pass, the resource can be uploaded normally in chunks. If either the front-end or back-end verification fails, the uploaded resource is determined to not meet the limits. The user then uses event messages sent by the listening device to implement front-end page interaction on their own system, such as prompting the user that the uploaded resource exceeds the size / width / length limits. By integrating the verification party's functionality, the user can easily implement uploaded resource attribute value verification, which facilitates their own functional expansion and improves development efficiency.

[0139] Based on the above verification method, this disclosure also provides a verification device for both the verification party and the user. (This will be combined with...) Figure 10 and Figure 11 Let me explain further.

[0140] Figure 10 A schematic block diagram of a verification apparatus for a verification party according to an embodiment of the present disclosure is shown.

[0141] like Figure 10 The verification device 1000 for the verification party may include a resource acquisition module 1010, a resource verification module 1020 and a verification result module 1030.

[0142] The resource acquisition module 1010 can perform operation S210 to obtain user resources uploaded by the user in response to the user's first upload operation at a specific entry point of the user.

[0143] The resource verification module 1020 can perform operation S220 to verify user resources according to the verification rules of a specific entry point. The user is configured to pre-configure N verification rules for N entry points, one-to-one, where N entry points include a specific entry point and N is an integer greater than or equal to 1.

[0144] The verification result module 1030 can perform operation S230 to send the verification result of the user resource to the user.

[0145] In some embodiments, the resource acquisition module 1010 may perform operations S310 to S320, which will not be described in detail here.

[0146] In some embodiments, the verification device 1000 for the verification party may further include a configuration module, which can perform operations S410 to S420 and operations S510 to S530, which will not be described in detail here.

[0147] In some embodiments, the resource verification module 1020 may perform operations S610 to S620 and operations S710 to S720, which will not be described in detail here.

[0148] Figure 11 A schematic block diagram of a verification device for a user according to an embodiment of the present disclosure is shown.

[0149] like Figure 11 The verification device 1100 for the user may include a request sending module 1110 and a result receiving module 1120.

[0150] The request sending module 1110 can perform operation S810, which is used to send a verification call request to the verification party in response to the user's first upload operation at a specific entry point. The verification party is configured to perform an embodiment of the verification method performed by any of the above verification parties to verify the user resources uploaded by the user.

[0151] The result receiving module 1120 can perform operation S820 to receive the verification result of the user resource sent by the verifier.

[0152] For any parts not mentioned in the apparatus section, please refer to the various embodiments of the above method for understanding. That is, the apparatus section includes modules for performing each step of any of the method embodiments described above. Furthermore, the implementation methods, technical problems solved, functions achieved, and technical effects of each module / unit / subunit in the apparatus section embodiments are the same as or similar to the implementation methods, technical problems solved, functions achieved, and technical effects of the corresponding steps in the method section embodiments, and will not be repeated here.

[0153] According to embodiments of this disclosure, any plurality of modules in verification device 1000 or verification device 1100 may be combined into one module, or any one of these modules may be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules may be combined with at least some of the functions of other modules and implemented in one module.

[0154] According to embodiments of this disclosure, at least one of the verification devices 1000 or 1100 can be at least partially implemented as hardware circuitry, such as a Field Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a System-on-Chip, a System-on-a-Substrate, a System-on-Package, an Application-Specific Integrated Circuit (ASIC), or any other reasonable method of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three methods. Alternatively, at least one of the verification devices 1000 or 1100 can be at least partially implemented as a computer program module, which, when run, can perform corresponding functions.

[0155] Figure 12 A block diagram schematically illustrates an electronic device suitable for implementing a verification method for a verification party or user, according to an embodiment of the present disclosure.

[0156] like Figure 12 As shown, an electronic device 1200 according to an embodiment of the present disclosure includes a processor 1201, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1202 or a program loaded from a storage portion 1208 into a random access memory (RAM) 1203. The processor 1201 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 1201 may also include onboard memory for caching purposes. The processor 1201 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0157] RAM 1203 stores various programs and data required for the operation of electronic device 1200. Processor 1201, ROM 1202, and RAM 1203 are interconnected via bus 1204. Processor 1201 performs various operations of the method flow according to embodiments of the present disclosure by executing programs in ROM 1202 and / or RAM 1203. It should be noted that programs may also be stored in one or more memories other than ROM 1202 and RAM 1203. Processor 1201 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in one or more memories.

[0158] According to embodiments of this disclosure, the electronic device 1200 may further include an input / output (I / O) interface 1205, which is also connected to a bus 1204. The electronic device 1200 may also include one or more of the following components connected to the I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to the I / O interface 1205 as needed. A removable medium 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1210 as needed so that computer programs read from it can be installed into the storage section 1208 as needed.

[0159] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments, or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0160] According to embodiments of this disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this disclosure, the computer-readable storage medium may include ROM 1202 and / or RAM 1203 and / or one or more memories other than ROM 1202 and RAM 1203 described above.

[0161] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this disclosure.

[0162] When the computer program is executed by the processor 1201, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0163] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 1209, and / or installed from the removable medium 1211. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0164] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 1209, and / or installed from the removable medium 1211. When the computer program is executed by the processor 1201, it performs the functions defined in the system of this disclosure embodiment. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0165] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can execute entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0166] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0167] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0168] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this disclosure is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A verification method for a verification party, characterized in that, include: In response to the user's first upload operation through a specific upload portal of the user, the user resources uploaded by the user are obtained; According to the verification rules of the specific upload entry, the user resource is verified, wherein the user is configured to pre-configure N verification rules for each of the N upload entries, where N is an integer greater than or equal to 1; the verification rules of the specific upload entry include M verification conditions corresponding to M resource types, where M is an integer greater than or equal to 1; the verification rules are used to verify whether the user resource meets specific conditions or attributes. Send the verification result of the user resource to the user. The verification of the user resources at the front-end and back-end based on the M verification conditions includes: instructing the front-end to send a back-end verification request to the back-end, the back-end verification request including the user resource type and resource attribute value, the user's identity identifier, the verification rules of the specific upload entry, and a second signature, wherein the second signature is obtained by the front-end encrypting the user resource type and resource attribute value, the user's identity identifier, and the verification rules of the specific upload entry according to a first encryption algorithm; executing the first encryption algorithm at the back-end to encrypt the user resource type and resource attribute value, the user's identity identifier, and the verification rules of the specific upload entry to obtain an encryption result; verifying the second signature based on the encryption result, wherein the verifier is configured to verify the user resources at the back-end according to the verification rules of the specific upload entry if the second signature verification passes.

2. The method according to claim 1, characterized in that, The process of obtaining the user's resources in response to the user's first upload operation through a specific upload portal includes: In response to receiving the verification call request from the user, an upload page is displayed to the user, wherein the user is configured to issue the verification call request in response to the first upload operation; In response to the user's second upload operation on the upload page, the user's resources are obtained.

3. The method according to claim 2, characterized in that, The upload page displayed to the user has a mapping relationship with the verification rules of the specific upload entry. Before displaying the upload page to the user, the method further includes: Receive the user's rule configuration request for any of the upload entry points, the rule configuration request including the verification rules for the corresponding upload entry point; In response to the rule configuration request, an upload page suitable for the corresponding upload entry is generated, and the mapping relationship between each upload page and the verification rules of its corresponding upload entry is stored.

4. The method according to claim 3, characterized in that, The rule configuration request also includes the user's authentication information. Before receiving the user's rule configuration request for any of the upload entry points, the method further includes: Receive the user's token call request; In response to the token call request, a first token value is generated for the user; The first token value is sent to the user, who is configured to obtain the authentication information based on the first token value.

5. The method according to claim 4, characterized in that, The step of generating an upload page suitable for the corresponding upload entry in response to the rule configuration request includes: The authentication information of the user is obtained from the rule configuration request. The authentication information includes the identifier of the user and a first signature obtained based on the identifier, the first token value and the verification rule of the corresponding upload entry. Verify the authentication information; If the verification passes, an upload page suitable for the corresponding upload entry is generated, and the mapping relationship between each upload page and the authentication information of its corresponding upload entry is stored.

6. The method according to claim 1, characterized in that, Based on the M verification conditions, verifying the user resources on the front end includes: The user resource type and resource attribute value are determined at the front end; The front end verifies the resource attribute value according to the verification conditions corresponding to the user resource type.

7. The method according to claim 1, characterized in that, The process of verifying the user resources on the backend includes: The user resource type and resource attribute value are determined in the backend. The backend verifies the resource attribute value based on the verification conditions corresponding to the user resource type.

8. The method according to claim 1, characterized in that, The verification result of the user resource is returned to the user: If the verification result is a failure, return a verification failure event message to the user; If the verification result is successful, the user resource is uploaded to the user and a verification success event message is returned.

9. The method according to claim 1, characterized in that, The verification party is configured to communicate with S users, where S is an integer greater than or equal to 1. The process of responding to a user's first upload operation via a specific upload portal and obtaining the user's uploaded resources includes: In response to the user's first upload operation at any one of the S user's specific upload entry points, the user's resources are obtained.

10. A verification method for a user, characterized in that, include: In response to a user’s first upload operation at a specific upload entry, a verification call request is sent to the verification party, which is configured to execute the method of any one of claims 1 to 9 to verify the user resources uploaded by the user. Receive the verification result of the user resource sent by the verification party.

11. A verification device for a verification party, characterized in that, include: The resource acquisition module is used to acquire the user resources uploaded by the user in response to the user's first upload operation at a specific upload entry of the user. The resource verification module is used to verify the user resource according to the verification rules of the specific upload entry. The user is configured to pre-configure N verification rules for each of the N upload entries, where N is an integer greater than or equal to 1. The verification rules for the specific upload entry include M verification conditions corresponding to M resource types, where M is an integer greater than or equal to 1. The verification rules are used to verify whether the user resource meets specific conditions or attributes. The verification result module is used to send the verification result of the user resource to the user. The verification of the user resources at the front-end and back-end based on the M verification conditions includes: instructing the front-end to send a back-end verification request to the back-end, the back-end verification request including the user resource type and resource attribute value, the user's identity identifier, the verification rules of the specific upload entry, and a second signature, wherein the second signature is obtained by the front-end encrypting the user resource type and resource attribute value, the user's identity identifier, and the verification rules of the specific upload entry according to a first encryption algorithm; executing the first encryption algorithm at the back-end to encrypt the user resource type and resource attribute value, the user's identity identifier, and the verification rules of the specific upload entry to obtain an encryption result; verifying the second signature based on the encryption result, wherein the verifier is configured to verify the user resources at the back-end according to the verification rules of the specific upload entry if the second signature verification passes.

12. A verification device for a user, characterized in that, include: The request sending module is used to send a verification call request to the verification party in response to the user's first upload operation at a specific upload entry. The verification party is configured to execute the method of any one of claims 1 to 9 to verify the user resources uploaded by the user. The result receiving module is used to receive the verification result of the user resource sent by the verification party.

13. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 10.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 10.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 10.

Images