CN118138641A - Request processing method and device - Google Patents

Abstract

The application discloses a request processing method and a request processing device, and relates to the technical field of control consoles. One embodiment of the method comprises the following steps: responding to the detection of a first access request of a user to a second platform embedded in the first platform based on the iframe, determining that the user needs to create a shadow account number and a role, and sending request information to an SSO system; in response to receiving a shadow account number and a role sent by an SSO system based on the user account number and the identification of the first platform, mapping authorization of the user account number and the shadow account number is carried out based on the user account number, the shadow account number and the role; performing verification operation based on the user account and the shadow account authorized by mapping, and sending a verification result to the SSO system; and controlling the shadow account to execute the first access request on the second platform in response to receiving the login state credential of the first platform which is successfully issued by the SSO system based on the verification result. This embodiment reduces the load on the individual consoles and improves the maintainability of the consoles.

Description

Request processing method and device

Technical Field

The present application relates to the field of computer technology, specifically to the field of console technology, and in particular to a request processing method and device.

Background technique

A separate console relies on the OpenAPI of the public cloud. Currently, when users purchase and manage public cloud resources in a separate console, the resources are created in a shadow account and the fees are charged to the user's own account. Therefore, the maintenance cost of a separate console is high and the function update is slow.

Summary of the invention

Embodiments of the present application provide a request processing method, apparatus, device, and storage medium.

According to the first aspect, an embodiment of the present application provides a request processing method, the method comprising: in response to detecting a user's first access request to a second platform embedded based on an iframe in a first platform, and determining that the user needs to create a shadow account and a role, sending a request message to an SSO system; in response to receiving a shadow account and a role sent by the SSO system based on the user account and an identifier of the first platform, performing mapping authorization of the user account and the shadow account based on the user account, the shadow account and the role; performing a verification operation based on the mapped authorized user account and the shadow account, and sending the verification result to the SSO system; in response to receiving the login credentials of the first platform issued by the SSO system based on the verification result for successful verification, controlling the shadow account to execute the first access request on the second platform.

According to the second aspect, an embodiment of the present application provides a request processing device, which includes: a sending module, configured to send a request message to the SSO system in response to detecting a user's first access request to a second platform embedded based on an iframe in the first platform, and determining that the user needs to create a shadow account and a role; a receiving module, configured to perform mapping authorization of the user account and the shadow account based on the user account, shadow account and role in response to receiving the shadow account and role sent by the SSO system based on the user account and the identifier of the first platform; a verification module, configured to perform a verification operation based on the mapped authorized user account and shadow account, and send the verification result to the SSO system; an execution module, configured to control the shadow account to execute the first access request on the second platform in response to receiving the login credentials of the first platform issued by the SSO system based on the verification result for successful verification.

According to the third aspect, an embodiment of the present application provides an electronic device, which includes one or more processors; a storage device on which one or more programs are stored, and when the one or more programs are executed by the one or more processors, the one or more processors implement a request processing method as in any embodiment of the first aspect.

According to a fourth aspect, an embodiment of the present application provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements a request processing method as in any embodiment of the first aspect.

The present application sends a request message to the SSO system in response to detecting a user's first access request to the second platform embedded based on an iframe in the first platform, and determining that the user needs to create a shadow account and role; in response to receiving the shadow account and role sent by the SSO system based on the user account and the identifier of the first platform, performs mapping authorization of the user account and the shadow account based on the user account, shadow account and role; performs a verification operation based on the mapped authorized user account and shadow account, and sends the verification result to the SSO system; in response to receiving the login credential of the first platform issued by the SSO system based on the verification result for successful verification, controls the shadow account to execute the first access request on the second platform, thereby realizing nesting and calling between different consoles, reducing the load of a separate console, and improving the maintainability of the console.

It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a diagram of an exemplary system architecture in which the present application may be applied;

FIG2 is a flow chart of an embodiment of a request processing method according to the present application;

FIG3 is a schematic diagram of an application scenario of the request processing method according to the present application;

FIG4 is a flow chart of another embodiment of a request processing method according to the present application;

FIG5 is a schematic diagram of an embodiment of a request processing device according to the present application;

FIG. 6 is a schematic diagram of the structure of a computer system suitable for implementing a server according to an embodiment of the present application.

Detailed ways

The following is a description of exemplary embodiments of the present application in conjunction with the accompanying drawings, including various details of the embodiments of the present application to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present application. Similarly, for the sake of clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

FIG. 1 shows an exemplary system architecture 100 to which an embodiment of the request processing method of the present application can be applied.

As shown in Fig. 1, system architecture 100 may include terminal devices 101, 102, 103, network 104 and server 105. Network 104 is used to provide a medium for communication links between terminal devices 101, 102, 103 and server 105. Network 104 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

The terminal devices 101, 102, 103 interact with the server 105 via the network 104 to receive or send messages, etc. Various application platforms may be installed on the terminal devices 101, 102, 103.

Terminal devices 101, 102, 103 can be hardware or software. When terminal devices 101, 102, 103 are hardware, they can be various electronic devices with display screens, including but not limited to mobile phones and laptops. When terminal devices 101, 102, 103 are software, they can be installed in the electronic devices listed above. They can be implemented as multiple software or software modules (for example, to provide request processing services), or they can be implemented as a single software or software module. No specific limitation is made here.

Server 105 can be a server that provides various services. For example, in response to detecting a user's first access request to a second platform embedded based on an iframe in a first platform, and determining that the user needs to create a shadow account and a role, a request message is sent to the SSO system, and the request message may include the user account and the identifier of the first platform; in response to receiving the shadow account and role sent by the SSO system based on the identifier of the user account and the first platform, mapping authorization of the user account and the shadow account is performed based on the user account, the shadow account and the role; a verification operation is performed based on the mapped authorized user account and the shadow account, and the verification result is sent to the SSO system; in response to receiving the login credentials of the first platform issued by the SSO system based on the verification result for successful verification, the shadow account is controlled to execute the first access request on the second platform.

It should be noted that the server 105 can be hardware or software. When the server 105 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or it can be implemented as a single server. When the server is software, it can be implemented as multiple software or software modules (for example, for providing request processing services), or it can be implemented as a single software or software module. No specific limitation is made here.

It should be noted that the request processing method provided in the embodiments of the present disclosure can be executed by the server 105, or by the terminal devices 101, 102, 103, or by the server 105 and the terminal devices 101, 102, 103 in cooperation with each other. Accordingly, the various parts (such as various units, sub-units, modules, sub-modules) included in the request processing device can be all set in the server 105, or all set in the terminal devices 101, 102, 103, or respectively set in the server 105 and the terminal devices 101, 102, 103.

It should be understood that the number of terminal devices, networks and servers in Figure 1 is only illustrative. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

FIG2 shows a flow chart 200 of an embodiment of a request processing method that can be applied to the present application. In this embodiment, the request processing method includes the following steps:

Step 201, in response to detecting a first access request from a user to a second platform embedded in an iframe in a first platform, and determining that the user needs to create a shadow account and role, a request message is sent to the SSO system.

In this embodiment, the execution entity (such as the server 105 or terminal devices 101, 102, 103 shown in Figure 1) can detect in real time or periodically the user's access request to the second platform embedded based on the iframe in the first platform, and in response to detecting the above-mentioned first access request, further determine whether the user needs to create a shadow account and role, and in response to determining the need, send a request information to the SSO (SingleSignOn) system based on the creation of a user interface, i.e., the createuser interface.

The request information may include a user account and an identifier of the first platform. Here, the identifier of the first platform is a fixed unique identifier pre-issued by the second platform to the first platform, that is, partnerid.

Here, the second platform and the first platform are mutually trusted platforms. The first platform and the second platform can be any platforms, and specifically, the first platform and the second platform can be different consoles.

Among them, iframe is an HTML element used to embed another web page in a web page.

Step 202, in response to receiving the shadow account and role sent by the SSO system based on the user account and the identifier of the first platform, the mapping authorization of the user account and the shadow account is performed based on the user account, the shadow account and the role.

In this embodiment, in response to receiving the shadow account and role sent by the SSO system based on the user account and unique identifier, the execution entity authorizes and binds the user account and the shadow account, and adds a trust relationship to the user account for the role, so as to control the shadow account through the user account and execute access requests on the second platform with the role.

The shadow account is the user's account on the second platform. The user settings and modifications made by the user after logging in with the shadow account are equivalent to the settings and modifications made by the user account.

Here, the role is a virtual account. The shadow account can play the role by calling it, obtain the temporary access key of the role, and solve the temporary authorization problem.

Here, SSO means that in multiple application systems, users only need to log in once to access all mutually trusted application systems. It includes a mechanism that can map this primary login to the login of the same user in other applications.

Step 203: Perform a verification operation based on the mapped authorized user account and shadow account, and send the verification result to the SSO system.

In this embodiment, after the execution subject authorizes the mapping between the user account and the shadow account, the execution subject may perform a verification operation and send the verification result to the SSO system.

Here, the verification operation may specifically include: the execution subject sends an authorization code to the client based on the mapped authorized user account and shadow account, and after receiving the authorization code, the client may send the authorization code and the second platform information to the SSO system. After receiving the authorization code and the second platform information, the SSO system may send a request to verify the authorization code. The execution subject performs verification and refreshes in response to receiving the request to verify the authorization code sent by the SSO system.

Step 204 , in response to receiving the login credentials of the first platform issued by the SSO system based on the verification result that the verification is successful, controlling the shadow account to execute the first access request on the second platform.

In this embodiment, after receiving the verification result, the SSO system can judge the verification result. If the verification result is successful, the login credentials of the first platform will be issued. If the verification result is a failure, the login credentials of the first platform will not be issued, and an error message such as "identity authentication failed" will be output.

After receiving the login credentials of the first platform issued by the SSO system based on the successful verification result, the execution subject can control the shadow account to execute the first access request on the second platform.

In some optional methods, controlling the shadow account to execute the first access request on the second platform includes: controlling the iframe to call a specified SDK to identify the login credentials of the first platform to obtain an identification result; based on the identification result, controlling the shadow account to execute the first access request on the second platform.

In this implementation method, the executing entity can control the iframe to call the specified SDK to identify the login credentials of the first platform, obtain the identification result, that is, convert the login credentials of the second platform into the login credentials of the first platform. Further, the executing entity controls the shadow account to execute the access request on the second platform according to the login credentials of the first platform.

This implementation method controls the iframe to call the specified SDK to identify the login credentials of the first platform to obtain the identification result; based on the identification result, the shadow account is controlled to execute the first access request on the second platform, so that the authorization and operations in the first platform need to be converted before they can take effect on the second platform, thereby realizing resource isolation and improving the effectiveness of control over the second platform.

In some optional embodiments, a prohibition instruction is output during the process of controlling the shadow account to execute the first access request on the second platform.

In this implementation, during the process of controlling the shadow account to execute the first access request on the second platform, a prohibition instruction is output, and the prohibition instruction is used to indicate that the non-iframe is prohibited from parsing the login credentials of the first platform.

This implementation method outputs a prohibition instruction during the process of controlling the shadow account to execute the first access request on the second platform, thereby effectively avoiding the leakage of first platform information during the process of the shadow account executing the first access request on the second platform, and realizing effective isolation of resources.

Continuing to refer to FIG. 3 , FIG. 3 is a timing diagram of an application scenario of the request processing method according to this embodiment.

In the application scenario of FIG3 , the first platform is a public cloud console, the second platform is part of the public cloud product line, and the second platform is embedded in the first platform based on an iframe. The execution subject 301 responds to detecting a first access request from a user to the second platform embedded in the first platform based on an iframe via a client 302, i.e., an access request to the iframe, and determines that the user needs to create a shadow account and role, and sends a request message to the SSO system 303, and the request message may include the user account and the identifier of the first platform; in response to receiving the shadow account and role sent by the SSO system 303 based on the user account and the identifier of the first platform, the mapping authorization of the user account and the shadow account is performed based on the user account, the shadow account and the role; the verification operation is performed based on the mapped authorized user account and the shadow account, which may specifically include: sending an authorization code to the client based on the mapped authorized user account and the shadow account, and after receiving the authorization code, the client may send the authorization code and the information of the second platform to the SSO system. After receiving the authorization code and the information of the second platform, the SSO system may send a request to verify the authorization code. The execution entity responds to receiving a request for verification of the authorization code sent by the SSO system, verifies and refreshes it, and sends the verification result to the SSO system; in response to receiving the login credentials of the first platform issued by the SSO system 303 based on the verification result that the verification is successful, controls the shadow account to execute the first access request on the second platform.

The request processing method disclosed in the present invention, in response to detecting a user's first access request to a second platform embedded based on an iframe in a first platform, and determining that the user needs to create a shadow account and a role, sends a request message to the SSO system, and the request message may include the user account and the identifier of the first platform; in response to receiving the shadow account and role sent by the SSO system based on the identifier of the user account and the first platform, performs mapping authorization of the user account and the shadow account based on the user account, the shadow account and the role; performs a verification operation based on the mapped authorized user account and shadow account, and sends the verification result to the SSO system; in response to receiving the login credential of the first platform issued by the SSO system based on the verification result for successful verification, controls the shadow account to execute the first access request on the second platform, thereby overcoming the problems of heavy load, high maintenance cost and slow function update of a separate console in the prior art, and effectively reducing the maintenance cost of a separate console.

Further reference is made to Fig. 4, which shows a process 400 of another embodiment of the request processing method shown in Fig. 2. In this embodiment, the process 400 of the request processing method may include the following steps:

Step 401, in response to detecting a first access request from a user to a second platform embedded in an iframe in a first platform, and determining that the user needs to create a shadow account and role, a request message is sent to the SSO system.

In this embodiment, the implementation details and technical effects of step 401 can refer to the description of step 201 and will not be repeated here.

Step 402, in response to receiving the shadow account and role sent by the SSO system based on the user account and the identifier of the first platform, the mapping authorization of the user account and the shadow account is performed based on the user account, the shadow account and the role.

In this embodiment, the implementation details and technical effects of step 402 can refer to the description of step 202 and will not be repeated here.

Step 403: Perform a verification operation based on the mapped authorized user account and shadow account, and send the verification result to the SSO system.

In this embodiment, the implementation details and technical effects of step 403 may refer to the description of step 203 and will not be repeated here.

Step 404 , in response to receiving the login credentials of the first platform issued by the SSO system based on the verification result that the verification is successful, controlling the shadow account to execute the first access request on the second platform.

In this embodiment, the implementation details and technical effects of step 403 may refer to the description of step 203 and will not be repeated here.

Step 405 , in response to detecting a second access request from a sub-account under the user account to a second platform with a first role, controlling the shadow account to execute the second access request with a second role.

In this embodiment, the executing entity can call the IAM (Identity and Access Management) interface to create multiple sub-accounts under the user account, that is, the main account, according to the user's request. The sub-accounts can correspond to corporate employees, systems, applications, etc. Each sub-account can manage the resources under the main account within the scope of authority, and the main account will be responsible for unified control and payment.

Since creating a sub-account only means that the main account assigns the corresponding permissions to the sub-account, the sub-account does not obtain the corresponding operation permissions. Usually, the sub-account needs to be authorized with the corresponding role in order to have the corresponding operation permissions.

Here, the sub-account can play the role by calling, obtain the temporary access key of the role, and solve the temporary authorization problem.

The execution entity may detect in real time or periodically a second access request to the second platform from a sub-account under the user account in the first role, and in response to detecting the second access request to the second platform from the sub-account, control the shadow account to execute the second access request in the second role.

Here, the first role and the second role have the same authority scope.

Specifically, the main account is A-admin. The execution subject creates a sub-account A-sub1 under the main account A-admin according to user needs, and calls the IAM: createRole interface to create a user role a-role1. Correspondingly, a role a-role2 is created under the shadow account a-admin, and A-admin is trusted.

In response to detecting a second access request from A-sub1 to the second platform with the role a-role1, the execution subject controls the shadow account a-admin to execute the second access request with the user role a-role2.

Among them, a-role1 and a-role2 have the same corresponding operation permissions.

In some optional embodiments, the method further includes: in response to detecting that a sub-account under the user account authorizes a preset policy, synchronously binding the preset policy to a user role created under the shadow account.

In this implementation, in response to detecting that a sub-account under the main account has authorized a preset policy, the execution entity can call the IAM interface to create a role under the shadow account, grant credit to the shadow account itself, and bind the preset policy to the created user role.

Furthermore, in response to detecting that the sub-account under the user account makes a third access request to the second platform according to the predicted strategy, the execution entity may control the shadow account to execute the third access request with the corresponding role according to the preset strategy.

Here, policy is a language for describing permissions. It supports policy generators, policy templates, and other methods to guide the writing of policy syntax. Under specific conditions, it allows or denies specific accounts specific operation permissions for specific resources and supports permission control for multiple cloud services.

Specifically, when A-admin authorizes Policy1 to A-sub1, the execution subject needs to call the IAM interface to create a user role a-role2 under the shadow account a-admin, grant credit to the shadow account itself, and bind Policy1 to a-role2.

This implementation method responds to detecting the preset policy for sub-account authorization under the user account and synchronously binds the preset policy to the user role created under the shadow account, so that the customer sees the sub-account/role he manages, while the user role actually in the iframe is consistent with the policy, which improves the user experience and reduces maintenance costs.

As can be seen from Figure 4, compared with the embodiment corresponding to Figure 2, the process 400 of the request processing method in this embodiment reflects that in response to detecting that the sub-account under the user account makes a second access request to the second platform with a first role, the shadow account is controlled to execute the second access request with a second role, that is, the authorization of the console sub-account and role is realized, and the sub-account controls the embedded console, thereby improving the maintainability of the console under the sub-account.

Further referring to FIG. 5 , as an implementation of the methods shown in the above figures, the present application provides an embodiment of a request processing device, which corresponds to the method embodiment shown in FIG. 2 , and can be specifically applied to various electronic devices.

As shown in FIG. 5 , the request processing device 500 of this embodiment includes: a sending module 501 , a receiving module 502 , a checking module 503 and an executing module 504 .

Among them, the sending module 501 can be configured to send request information to the SSO system in response to detecting a user's first access request to the second platform embedded based on the iframe in the first platform, and determining that the user needs to create a shadow account and role.

The receiving module 502 may be configured to perform mapping authorization between the user account and the shadow account based on the user account, the shadow account and the role in response to receiving the shadow account and the role sent by the SSO system based on the user account and the identifier of the first platform.

The verification module 503 may be configured to perform a verification operation based on the mapped authorized user account and the shadow account, and send the verification result to the SSO system.

The execution module 504 may be configured to control the shadow account to execute the first access request on the second platform in response to receiving the login credentials of the first platform issued by the SSO system based on the verification result that the verification is successful.

In some optional embodiments of this embodiment, the device also includes a control module configured to control the shadow account to execute the second access request as a second role in response to detecting a second access request to the second platform by a sub-account under the user account as a first role.

In some optional aspects of this embodiment, the device further includes a binding module configured to synchronously bind a preset policy to a user role created under a shadow account in response to detecting that a sub-account under the user account has authorized a preset policy.

In some optional modes of this embodiment, the execution module is further configured to: control the iframe to call the specified SDK to identify the login credentials of the first platform to obtain an identification result; based on the identification result, control the shadow account to execute the first access request on the second platform.

In some optional aspects of this embodiment, the device further includes an output module configured to output a prohibition instruction during the process of controlling the shadow account to execute the first access request on the second platform.

According to an embodiment of the present application, the present application also provides an electronic device and a readable storage medium.

As shown in FIG6 , it is a block diagram of an electronic device according to the request processing method of an embodiment of the present application.

600 is a block diagram of an electronic device according to a request processing method of an embodiment of the present application. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and/or required herein.

As shown in Figure 6, the electronic device includes: one or more processors 601, memory 602, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the electronic device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input/output device (such as a display device coupled to the interface). In other embodiments, if necessary, multiple processors and/or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). In Figure 6, a processor 601 is taken as an example.

The memory 602 is a non-transient computer-readable storage medium provided in the present application. The memory stores instructions executable by at least one processor to enable the at least one processor to perform the request processing method provided in the present application. The non-transient computer-readable storage medium of the present application stores computer instructions, which are used to enable a computer to perform the request processing method provided in the present application.

The memory 602, as a non-transient computer-readable storage medium, can be used to store non-transient software programs, non-transient computer executable programs and modules, such as program instructions/modules corresponding to the request processing method in the embodiment of the present application (for example, the sending module 501, the receiving module 502, the verification module 503 and the execution module 504 shown in FIG. 5). The processor 601 executes various functional applications and data processing of the server by running the non-transient software programs, instructions and modules stored in the memory 602, that is, implements the request processing method in the above method embodiment.

The memory 602 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created by the use of the electronic device requesting processing, etc. In addition, the memory 602 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 602 may optionally include a memory remotely arranged relative to the processor 601, and these remote memories may be connected to the electronic device requesting processing via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

The electronic device of the request processing method may further include: an input device 603 and an output device 604. The processor 601, the memory 602, the input device 603 and the output device 604 may be connected via a bus or other means, and FIG6 takes the bus connection as an example.

The input device 603 can receive input digital or character information, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, an indicator bar, one or more mouse buttons, a track ball, a joystick, and other input devices. The output device 604 may include a display device, an auxiliary lighting device (e.g., an LED), and a tactile feedback device (e.g., a vibration motor). The display device may include, but is not limited to, a liquid crystal display (LCD), a light emitting diode (LED) display, and a plasma display. In some embodiments, the display device may be a touch screen.

Various implementations of the systems and techniques described herein can be realized in digital electronic circuit systems, integrated circuit systems, dedicated ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations may include: being implemented in one or more computer programs that can be executed and/or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for programmable processors and can be implemented using high-level procedural and/or object-oriented programming languages, and/or assembly/machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and/or means (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal for providing machine instructions and/or data to a programmable processor.

To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

The systems and techniques described herein may be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communications network). Examples of communications networks include: a local area network (LAN), a wide area network (WAN), and the Internet.

A computer system may include clients and servers. Clients and servers are generally remote from each other and usually interact through a communication network. The relationship of client and server is generated by computer programs running on respective computers and having a client-server relationship to each other.

According to the technical solution of the embodiment of the present application, the load of the separate console is reduced and the maintainability of the console is improved.

It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in this application can be executed in parallel, sequentially or in different orders, as long as the expected results of the technical solution disclosed in this application can be achieved, and this document is not limited here.

The above specific implementations do not constitute a limitation on the protection scope of this application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of this application should be included in the protection scope of this application.

Claims (12)

1. A method of request processing, the method comprising:

responding to the detection of a first access request of a user to a second platform embedded on the basis of an iframe, determining that the user needs to create a shadow account number and a role, and sending request information to an SSO system, wherein the request information comprises the user account number and an identification of the first platform;

In response to receiving a shadow account number and a role sent by the SSO system based on the user account number and the identification of the first platform, mapping authorization of the user account number and the shadow account number is carried out based on the user account number, the shadow account number and the role;

performing verification operation based on the user account and the shadow account authorized by mapping, and sending a verification result to the SSO system;

and controlling the shadow account to execute the first access request on the second platform in response to receiving the login state credential of the first platform which is successfully issued by the SSO system based on the verification result.

2. The method of claim 1, the method further comprising:

And responding to the detection of a second access request of the sub account under the user account to the second platform by the first role, and controlling the shadow account to execute the second access request by the second role, wherein the authority ranges of the first role and the second role are the same.

3. The method of claim 2, the method further comprising:

and in response to detecting that the sub-account under the user account authorizes the preset strategy, synchronously binding the preset strategy for the user roles created under the shadow account.

4. The method of claim 1, wherein the control shadow account performs a first access request at a second platform, comprising:

controlling the iframe to call a designated SDK to identify a login state credential of the first platform, and obtaining an identification result;

And controlling the shadow account to execute the first access request on the second platform based on the identification result.

5. The method of claim 4, the method further comprising:

and outputting a prohibition instruction in the process of controlling the shadow account to execute the first access request on the second platform, wherein the prohibition instruction is used for prohibiting the non-iframe from analyzing the login state certificate of the first platform.

6. A request processing apparatus, the apparatus comprising:

the sending module is configured to respond to detection of a first access request of a user to a second platform embedded on the basis of an iframe in the first platform, determine that the user needs to create a shadow account and a role, and send request information to an SSO system, wherein the request information comprises the user account and an identification of the first platform;

The receiving module is configured to respond to receiving a shadow account number and a role sent by the SSO system based on the user account number and the identification of the first platform, and perform mapping authorization of the user account number and the shadow account number based on the user account number, the shadow account number and the role;

The verification module is configured to execute verification operation based on the user account and the shadow account authorized by mapping, and send a verification result to the SSO system;

And the execution module is configured to control the shadow account number to execute the first access request on the second platform in response to receiving the login state credential of the first platform which is successfully issued by the SSO system based on the verification result.

7. The apparatus of claim 6, the apparatus further comprising:

and the control module is configured to respond to the detection of a second access request of the sub account under the user account to the second platform in the first role, and control the shadow account to execute the second access request in the second role, wherein the authority ranges corresponding to the first role and the second role are the same.

8. The apparatus of claim 7, the apparatus further comprising:

and the binding module is configured to synchronously bind the preset strategy for the user roles created under the shadow account in response to detecting that the sub-account under the user account authorizes the preset strategy.

9. The apparatus of claim 6, wherein the execution module is further configured to:

controlling the iframe to call a designated SDK to identify a login state credential of the first platform, and obtaining an identification result;

And controlling the shadow account to execute the first access request on the second platform based on the identification result.

10. The apparatus of claim 9, the apparatus further comprising:

And the output module is configured to output a prohibition instruction in the process of controlling the shadow account to execute the first access request on the second platform, wherein the prohibition instruction is used for prohibiting the non-iframe from analyzing the login state credential of the first platform.

11. An electronic device, comprising:

at least one processor; and

A memory communicatively coupled to the at least one processor; wherein,

The memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-5.

12. A non-transitory computer readable storage medium storing computer instructions for causing the computer to perform the method of any one of claims 1-5.