A network bidding cloud service method and system

Abstract

The present invention relates to a network bidding cloud service method and system. The system includes a docking service end, a docking client end, a bidding cloud user service, a business system identity authentication service, a WebSocket server for obtaining the latest dynamic information of the target, a WebSocket client end for obtaining the latest dynamic information of the target by a browser, and an interface for receiving bidding results by a business system; wherein the docking service end includes a filter, a bidding push controller, a quotation processing controller, and a WebSocket server for monitoring and pushing bidding results; the docking client end includes a forwarder and a WebSocket client end for monitoring and receiving bidding results. The solution of the present invention is more convenient for bidders to operate, and enables the business system to obtain bidding results more timely and efficiently.

Description

Technical Field

[0001] The present invention belongs to the technical field of network bidding, and specifically relates to a network bidding cloud service method and system. Background Art

[0002] The online bidding system usually has two product forms: one is the product sales model, that is, the bidding system product is independently deployed on the customer's server to provide bidding capabilities; the other is the cloud service model, which is to rent instead of purchase, so that bidding services can be provided to bidders when the trading institution does not purchase bidding products. Bidding cloud service refers to a cloud platform that provides bidding services. The platform can support docking with the business systems of multiple institutions. It can handle the bidding process of multiple targets under multiple institutions at the same time and feedback the bidding results.

[0003] There are many bidding cloud services available on the market, but the user experience is not user-friendly and convenient. The main problem is the bidder account system.

[0004] A complete transaction will include many links: the entrusting party entrusts the subject to the transaction institution for disposal, the transaction institution discloses the basic information of the subject, transaction rules and registration information online on the website, the interested party browses the transaction institution website to learn about the subject information and registers online, the transaction institution reviews the applicant's materials and qualifications, and the interested party sees that the registration is successful and pays the deposit online or offline. If there is only one applicant, an agreement transfer can be adopted; if there are two or more applicants, competitive negotiation or online bidding can be adopted. After the negotiation or bidding is completed, the payment of the price, the transfer of the price, the payment of service fees, and the delivery of assets must be handled.

[0005] It can be seen that online bidding is usually only an optional link in the complete transaction process, not the center of the entire transaction business. Therefore, the general bidding cloud service will not become a single sign-on provider, because it is difficult to require multiple trading institutions to use the bidding system account system for unified login in business. The current common solution is that the business system and the bidding system each use their own authentication login system. After the business system confirms the qualifications of the intended party and confirms that the online bidding will be organized (the "intended party" identity will become the "bidder"), the bid information and bidder information (identity anonymization, with mobile phone number) are pushed to the bidding cloud service through the interface. After receiving the bidding cloud service, it creates a temporary bidder account and sends the login information to the bidder through SMS or email. Although this can achieve the purpose of allowing bidders to bid normally, it is not easy to use and friendly enough.

[0006] The main problem is that the interested party (bidder) registered, signed up, and paid a guarantee in the business system, but received a text message or email for bidding on another bidding cloud service platform. The username and password have nothing to do with the one registered in the business system. At this time, the interested party (bidder) will not understand or confirm whether the text message is authentic and reliable. In addition, since text messages need to be pushed to bidders, but the delivery rate of text messages or emails cannot be guaranteed, bidders may not receive text messages or emails in time, resulting in missed bidding. In addition, if bidders change their passwords on the transaction agency's website, they may think that the password will be updated synchronously on the bidding cloud platform. In fact, since the account systems are independent of each other, account changes between different systems will not be synchronized with each other. The above problems will cause a lot of inconvenience to bidders, and they may even miss the bidding time.

[0007] In addition, in the current online bidding cloud service sales process, the business system obtains the transaction results by polling. If you want to obtain the bidding results as quickly as possible, you need to increase the polling frequency. However, since the bidding cloud service is a multi-institutional one, and each institution has multiple bids to deal with at the same time, the bidding cloud service will be under great pressure from being polled. This polling is actually very inefficient.

[0008] Secondly, the bidding system also has security requirements. The bidder's bid information should be safely and accurately transmitted to the bidding server. There are many bidding modes, including forward multiple bidding similar to the English auction; timed price reduction bidding similar to the Dutch auction; and sealed bidding. The sealed bidding form requires that data cannot be leaked during the transmission process. All bidding modes require that the bid request cannot be tampered with, and the bidder cannot deny the price already quoted.

[0009] At the same time, the bidding system also has timeliness requirements. For bids of the same price, the bidder who bids earlier will be regarded as a valid bid, while the bidder who bids later will be regarded as an invalid bid. Therefore, the bid delay cannot be too high. Summary of the invention

[0010] The technical problem to be solved by the present invention is to provide a network bidding cloud service method and system, which is convenient for the intended party (bidder) to operate, avoids the trouble caused by the need to log in on other platforms and the inability to receive text messages in time, and enables the business system to obtain bidding results more timely and efficiently. At the same time, it does not reduce the data transmission security of the bidding process, ensuring that the bidding information will not be tampered with.

[0011] According to the technical solution of the present invention, the present invention provides a network bidding cloud service system, including a docking server, a docking client, a bidding cloud user service, a business system identity authentication service, a WebSocket server for obtaining the latest dynamic information of the target, a browser for obtaining the latest dynamic information of the target WebSocket client and a business system receiving bidding result interface; wherein, the docking server includes a filter, a bidding push controller, a quotation processing controller, and a WebSocket server for monitoring and pushing bidding results; the docking client includes a forwarder and a WebSocket client for monitoring and receiving bidding results.

[0012] The present invention also provides a network bidding cloud service method, which is implemented using the network bidding cloud service system of the present invention, and includes system docking implementation phase initialization work, pre-bidding target push process, bidding process quotation processing process and bidding end result feedback process.

[0013] Furthermore, the initialization work of the system docking implementation phase includes the following steps:

[0014] Step S1001, the bidding cloud service pre-allocates a pair of ClientKey, ClientSecret and organization information to the trading organization, which are used to encrypt and decrypt the request body and response body of the HTTP request and receive and send messages through WebSocket;

[0015] Step S1002, the bidding cloud service pre-assigns an institution admin user to the trading institution;

[0016] Step S1003, the bidding cloud service pre-allocates a docking address to the trading institution;

[0017] Step S1005, the front-end website of the institutional business system develops a quotation list page, a quotation site page, and a personal bidding room page, embeds the JavaScript front-end code provided by the bidding cloud platform in these three pages, and adjusts the website front-end menu structure;

[0018] Step S1006, the institution business system identity authentication service configuration adds an authentication client identity for the docking client to use, so that the docking client can also legally access the business system identity authentication service, so that the business system identity authentication service can correctly process the verification login request from the docking client and return the user's login status;

[0019] Step S1007, the institutional business system develops an interface for receiving the target end notification and accepting the target ID; and provides this API address to the docking client;

[0020] Step S1008: In the middleware of the front-end website of the institution's business system, an independent prefix is ​​configured to forward HTTP requests, and an independent prefix is ​​added to forward WebSocket requests. The requests of these two prefixes are set with protocol upgrade and timeout, and forwarded to the HTTP port and WebSocket port of the docking client respectively;

[0021] Step S1009, configure the above ClientKey, ClientSecret and the docking address assigned to the trading institution, the API address for receiving bidding results, and the forwarding prefix URI into the corresponding configuration items of the configuration file of the docking client, and start the docking client.

[0022] Furthermore, the initialization work of the system docking implementation phase also includes, step S1004, the bidding cloud service pre-registers the export IP list of the transaction institution for security authentication of the docking client IP address by the docking server.

[0023] Furthermore, the pre-bidding bid push process includes the following steps:

[0024] Step S21, the business personnel of the institution's business system pushes the targets that have been confirmed to be selected by bidding to the bidding cloud service;

[0025] Step S22: The institutional business system pushes the bidder information and deposit information to the bidding system.

[0026] Further, step S21 includes the following steps:

[0027] Step S2101, the business system calls the push target information address of the docking client through the API address and submits the target data;

[0028] Step S2102, the client forwarder determines that the current request is an HTTP request and uses the HTTP module to process it;

[0029] Step S2103, using the pre-allocated ClientSecret to encrypt all the parameter request bodies carried, and appending the parameter ClientKey = pre-allocated ClientKey;

[0030] Step S2104, the forwarder forwards the processed request to the same URI of the docking server;

[0031] Step S2105, after the server filter intercepts the request, it first checks the ClientKey, and retrieves the ClientSecret, authorized IP address and organization information of the client from the cache or database;

[0032] Step S2106, checking whether the request source IP is from the authorized IP address range;

[0033] Step S2107, using the ClientSecret of the transaction institution to try to decrypt the request body;

[0034] Step S2108: After normal decryption, call the bidding cloud user service to obtain the identity of the admin user of the trading institution;

[0035] Step S2109, create a login user object for the user and put it into the request header;

[0036] Step S2110, routing the decrypted request with the logged-in user object header attached to the bidding push controller;

[0037] Step S2111: The bidding push controller receives the push target information interface request and obtains the login user information from the header;

[0038] Step S2112: The bidding push controller is passed to the PushService layer to process the business logic;

[0039] Step S2113, PushService creates a subject and returns the subject id; the created subject is deemed to be created by the user;

[0040] Step S2114: The response body is captured by the docking server filter, and the response body is encrypted using the ClientSecret of the organization and returned to the service system caller.

[0041] Step S2115: After receiving the response body, the docking client forwarder uses ClientSecret to decrypt the response body and returns it to the business system;

[0042] Step S2116: The business system receives the returned plain text of the target ID and completes the complete target push request.

[0043] Furthermore, the difference between step S22 and step S21 is that the bidding receiving method in PushService also checks whether the bidder has an account in the bidding cloud service. If not, a bidder account is created in the bidding cloud user service. The account cannot log in directly on the bidding cloud service end, and can only access the system and bid through docking. The subsequent response processing flow and target push are the same as step S21.

[0044] Furthermore, the bidding process includes the following steps:

[0045] Step S3001, the bidder completes the login through the business system identity authentication service on the transaction institution website;

[0046] Step S3002: The bidder opens the bidding site page and bids for the target. The JavaScript front-end code is connected to execute the interface for obtaining the target static information. The first part of the interface URI address is the prefix of the docking client forwarder, followed by the corresponding interface address of the bidding cloud service actually called.

[0047] Step S3003, the institution business system middleware forwards the request to the HTTP port of the docking client forwarder according to the independent prefix forwarding configured in the initialization process;

[0048] Step S3004, after receiving the request, the forwarder determines that the current request is an HTTP request and uses the HTTP module to process it;

[0049] Step S3005: If the check is not for the bidding push controller, the business system identity authentication service is called to verify the header information of the request, and the login information of the current login user on the business system side is verified; the business system identity authentication service returns the authentication result, confirming that the bidder is in a normal login state on the business system website, and obtains the user name;

[0050] Step S3006, the forwarder checks the returned result. If it is successful, it will encrypt the request body of all parameters carried by the login user name information and the original quotation request information using the pre-assigned ClientSecret, and add the parameter ClientKey = pre-assigned ClientKey;

[0051] Step S3007, the forwarder forwards the processed request to the same URI of the docking server;

[0052] Step S3008, after the docking server filter intercepts the request, it first checks the ClientKey, and retrieves the ClientSecret, authorized IP address and organization information of the docking client from the cache or database;

[0053] Step S3009, check whether the request source IP is from the authorized IP address range;

[0054] Step S3010, using the ClientSecret of the organization to try to decrypt the request body;

[0055] Step S3011, after normal decryption, retrieve the identity of the user who logged in by calling the bidding cloud user service to obtain the parameter passed;

[0056] Step S3012, create a login user object and put it into the request header;

[0057] Step S3013, routing the restored request to the quotation processing controller;

[0058] Step S3014, the quotation processing controller receives the quotation interface request for the target and obtains the login user information from the login user object in the header;

[0059] Step S3015, assemble the request and pass it to the BidService layer to process the business logic;

[0060] Step S3016, BidService verifies the price information, writes the quotation, and finally returns whether the quotation is successful; the quotation for the target is considered to be created by the user;

[0061] Step S3017: The response body is captured by the docking server filter, and the response body is encrypted using the ClientSecret of the Client and returned to the docking client.

[0062] Step S3018, after receiving the response body, the docking client forwarder uses ClientSecret to decrypt the response body and returns it to the bidder's quotation page;

[0063] In step S3019, the target site page opened by the bidder will establish a WebSocket request.

[0064] Furthermore, the bidding end result feedback process includes the following steps:

[0065] Step S4001: When the bidding service is started, it will be connected to a message queue as a producer, and when any bidding ends, it will send bidding end information to the message queue;

[0066] Step S4002: A queue consumer thread on the docking server is also connected to the message queue and monitors messages in the queue;

[0067] Step S4003: When the bidding of a certain target ends, the docking server receives an end message; sends this message to the WebSocket server for monitoring and pushing bidding results; the WebSocket server for monitoring and pushing bidding results calls the original query target information interface of the bidding service according to the target ID;

[0068] Step S4004, query the subject information interface, and return detailed information of the subject, including the institution to which the subject belongs;

[0069] Step S4005, monitoring and pushing the bidding result WebSocket server to encrypt the end message of this bid using the ClientSecret of this transaction institution;

[0070] Step S4006, pushing the bid result to the WebSocket client of the docking client of the institution to which the target belongs through the WebSocket connection;

[0071] Step S4007, after the WebSocket client receives the message, it decrypts it with ClientSecret, initiates an HTTP request, and sends the message to the business system to receive the bidding result interface;

[0072] Step S4008, after the business system receives the request through the bidding result receiving interface, it will know that the bidding has ended and will call the bidding transaction record obtaining interface again.

[0073] Furthermore, an operation and maintenance upgrade process is also included, which includes at least one of the following steps:

[0074] Step S5001, server performance enhancement, performance isolation, and fault isolation upgrade process:

[0075] When the system capacity is insufficient and needs to be expanded, or when the trading organization purchases a more advanced independent bidding server, the resolution of the docking address can be modified to point to the independent bidding server. The client does not need to modify any configuration or restart.

[0076] Step S5002, adding business function flow:

[0077] When adding business functions, you only need to modify the JavaScript script and call the new docking server interface. The docking client does not need to modify any configuration or restart.

[0078] Step S5003, client connection exception process:

[0079] The docking client and the docking server maintain a WebSocket connection, and report the docking client server status at regular intervals and receive time calibration from the docking server. Even if a security device is passed in the middle, the idle time will not be reached, resulting in a disconnection. If the connection is disconnected, the docking client will try to re-establish the WebSocket connection.

[0080] Compared with the prior art, the beneficial technical effects of the present invention are as follows:

[0081] 1. Bidders complete all operations on the trading agency website system. The entire process uses their own registered trading agency website user, which is more convenient for bidders to operate and avoids the confusion caused by the need to use two accounts of the trading agency and the bidding cloud service. There will also be no account and password synchronization problems.

[0082] 2. The inefficient polling method for obtaining bidding results has been improved, and the server has been actively pushing bidding results, so that the business system can obtain bidding results more timely and efficiently.

[0083] 3. The business system does not open ports to the public network. All requests to access the bidding cloud service are authenticated by the source IP. Even if the ClientKey and ClientSecret are leaked, the server will still reject the forged request, further ensuring security.

[0084] 4. A monitoring function has been added. The client can report the client status to the server in real time. The server can display real-time monitoring information and store records for analysis. BRIEF DESCRIPTION OF THE DRAWINGS

[0085] Figure 1 This is a schematic diagram of the bidding cloud service business process commonly used in the prior art (before the present invention).

[0086] Figure 2 It is a schematic diagram of the pre-bidding bid push process in the network bidding cloud service method according to an embodiment of the present invention.

[0087] Figure 3 and Figure 4 It is a schematic diagram of the quotation processing flow of the bidding process in the network bidding cloud service method according to an embodiment of the present invention.

[0088] Figure 5 It is a block diagram of a network bidding cloud service according to an embodiment of the present invention, to show the location and calling relationship of each component. DETAILED DESCRIPTION

[0089] The present invention provides a network bidding cloud service method and system, the main improvements of which include:

[0090] 1. Bidders complete all operations on the trading institution website system, including registration, application, deposit payment, bidding, transaction processing, etc. The entire process uses the user of the trading institution website registered by themselves, which improves the disadvantage that the bidding process needs to log in to the third-party system using the account of the third-party system. All requests are sent directly to the trading institution, and the end user is unaware of the existence of the bidding cloud service, which is more convenient for bidders to operate;

[0091] Second, the business system does not need to open ports to the public network. All requests to access the bidding cloud service are authenticated by the source IP. Even if the ClientKey and ClientSecret are leaked, the server will still reject the counterfeit request, ensuring security.

[0092] 3. Improved the inefficient way of obtaining bidding results by polling, and changed it to the server actively pushing bidding results, so that the business system can obtain bidding results more timely and efficiently;

[0093] 4. A monitoring function has been added. The client can report the client status to the server in real time. The server can display real-time monitoring information and store records for analysis.

[0094] First see Figure 1 , which is the existing (before the present invention) bidding cloud service business process, which includes:

[0095] 1. (Trading institution) business personnel disclose the project on the business system;

[0096] 2. If the interested party (multiple parties) have not registered before, they need to register as a user of the trading institution business system (skip this step if they have registered before);

[0097] 3. The interested party browses the disclosed project information;

[0098] 4. Interested parties register online on the trading institution’s website;

[0099] 5. Business personnel review the registration information of the intended party;

[0100] 6. After the interested party sees that the registration qualification review has been passed, they can pay the deposit online or offline;

[0101] 7. The business personnel confirms that the deposit has been received;

[0102] 8. The business personnel triggers the push of project information to the bidding cloud service, which becomes a bidding target;

[0103] 9. The business personnel triggers the push of information of multiple interested parties to the bidding cloud service, and become multiple bidders. At this time, the user's identity changes from an interested party to a bidder;

[0104] 10. If the bidder has never used the bidding cloud service, a user will be automatically created (skip this step if you have registered);

[0105] 11. The bidding cloud service automatically sends SMS or email to the bidder’s username, password, and login address;

[0106] 12. The bidder uses the login information to log in to the bidding cloud service;

[0107] 13. The bidders make bids for the target item, and the bidding is finally completed, resulting in a successful transaction;

[0108] 14. The business system polls regularly to obtain the transaction results and transaction parties;

[0109] 15. The business personnel confirm the transaction results and transaction parties in the business system;

[0110] 16. The transaction party shall pay or make up the transaction price online or offline (the deposit can be converted into part of the price);

[0111] The complete process also includes contract signing, price confirmation, asset delivery, etc., which are not related to the present invention and will not be described in detail.

[0112] The main problem with the above existing technical solutions is that the "bidding cloud service user account" and "SMS or email notification" may confuse the interested party (bidder), as well as the inefficient "polling" method for obtaining bidding results. The technical problem to be solved by the present invention is also mainly aimed at this. At the same time, the data transmission security of the bidding process is not reduced, ensuring that the bidding information will not be tampered with.

[0113] The network bidding cloud service system of the present invention mainly includes a docking server (Docking Server), a docking client (Docking Client), a bidding cloud user service (BidUserCenter), a business system identity authentication service (BusinessAuth), a WebSocket server (BidWS Server) for obtaining the latest dynamic information of the bid, a WebSocket client (BidWSClient) for obtaining the latest dynamic information of the bid, and a business system receiving bidding result interface (ReceiveResult API). The location and calling relationship of each component can be found in Figure 5 .

[0114] The docking server is a server program that needs to be installed on the bidding cloud service side for docking, which specifically includes:

[0115] 1. Filter: The filter is the gateway to the docking server. All HTTP requests from the docking client are intercepted. First, verify whether the docking client IP is within the registered client IP range; then use ClientSecret to decrypt the request body; then route the request to the bidding push controller or processing controller according to the URI; finally, encrypt the response body returned by the bidding push controller with ClientSecret and return it to the docking client.

[0116] 2. Bidding push controller (PushController): Use the client information carried in the request to call the bidding cloud identity authentication service (BidAuth) to return the client information, create an operation client object (OpClient) and attach it to the request, and transfer it to the unified PushService layer (push service layer) for processing. The response will pass through the above filter (Filter).

[0117] 3. Bid Controller: Use the user name in the request to call the Bid Cloud Identity Authentication Service (BidAuth) to return the user information, create a login user object (LoginUser) and attach it to the request, and transfer it to the unified BidService layer (quotation service layer) for processing. The response will pass through the above filter. Generally, modern programming uses a layered model. The Controller layer is generally used to receive requests, perform simple non-business checks, convert data, and other operations; the Service layer handles specific business checks, business logic organization, and transaction processing.

[0118] 4. WebSocket Server (DockingWS Server) that monitors and pushes bidding results: Starts the WebSocket service, authenticates the handshake requests from the WebSocket clients of multiple docking clients, authenticates the source IP, and decrypts the Org information encrypted with the ClientSecret corresponding to the ClientKey; if the handshake is successful, opens the connection and feeds back the current timestamp of the docking server for docking client time calibration.

[0119] The WebSocket server monitors and pushes bidding results and receives client monitoring information reported by multiple docking clients every few seconds (configurable), including CPU (percentage), system load (one-minute average, five-minute average, and fifteen-minute average), memory (total, used), and disk (total, used). It also feeds back the current timestamp of the server for docking client time calibration.

[0120] The docking server is also connected to the message queue of the bidding service to receive the bidding end message; after receiving the message, it calls the bidding system to query which trading institution the target belongs to, encrypts the end message using the docking client ClientSecret of the institution to which the target belongs, and pushes it to the WebSocket client that monitors and receives bidding results and is located at the docking client of the institution to which the target belongs.

[0121] The docking client is a client program that needs to be installed on the business system side for docking, which specifically includes:

[0122] 1. Forwarder: The forwarder is responsible for forwarding HTTP requests from browsers, WebSocket connection requests, and HTTP requests from business systems.

[0123] In the HTTP request from the browser, the bidder sends the quotation-related request to the docking client forwarder by calling the docking JavaScript front-end code. The forwarder implements the docking of the business system identity authentication service (BusinessAuth), and uses the authentication information carried by the request (which can be a cookie) to obtain the login user name and attach it to the request parameter. The forwarder has no bidding business logic. It attaches the ClientKey in the configuration file to the request parameter, and then encrypts the request body (Request Body) using the ClientSecret in the configuration file, and forwards it to the back-end with the same URI of the secondary domain name (or independent domain name) of the organization. After decrypting the response body (Response Body), it is returned to the browser. This ensures the privacy and integrity of data during transmission.

[0124] Among them, the WebSocket connection request from the browser, when the bidder opens the quotation site or personal bidding room page, a WebSocket connection will be automatically created, and the connection address will also reach the docking client forwarder. When the forwarder finds that it is a WebSocket connection request, it will proxy the request to the WebSocket server (BidWS Server) of the bidding cloud service to obtain the latest dynamic information of the bid. After the BidWS Server authentication is passed, the bidder's browser will directly establish a connection with the BidWS Server. For two-way transmission, ClientSecret is used for encryption before the message is sent, and ClientSecret is used for decryption after receiving it. This ensures the privacy and integrity of the data during the transmission process.

[0125] The target and bidder push request from the business system is also sent to the forwarder. The forwarder appends the ClientKey in the configuration file to the request parameter, encrypts the request body with the ClientSecret in the configuration file, and forwards it to the same URI of the secondary domain name (or independent domain name) of the backend organization. After decrypting the response body, it is returned to the business system caller (target and bidder push request) to ensure the privacy and integrity of the data during the transmission process.

[0126] 2. WebSocket client for monitoring and receiving bidding results (DockingWS Client): The docking client uses the ClientKey and ClientSecret in the configuration file as authentication information to handshake with the WebSocket server for monitoring and receiving bidding results and establish a connection.

[0127] Reports client monitoring information every few seconds (configurable), including CPU (percentage), system load (one-minute average, five-minute average, and fifteen-minute average), memory (total, used), and disk (total, used), and receives the current timestamp of the server for time synchronization of the client.

[0128] After receiving the quotation result message sent by the WebSocket server (DockingWS Server) that monitors and pushes bidding results, it is decrypted using ClientSecret and the target end plaintext message is sent to the ReceiveResult API of the business system that implements the registration.

[0129] The specific aspects of connecting to the JavaScript front end include:

[0130] 1. Page component loading:

[0131] loadPage: / / Load the core components of the quotation area on the quotation site page, including "target name, starting price, current price, price, increment, etc."

[0132] 2. WebSocket connection establishment, maintenance, disconnection retry mechanism:

[0133] ws: / / websocket request address.

[0134] 3. It also includes some js call encapsulation of HTTP requests:

[0135] item: / / Get item and itemRule information

[0136] session: / / Get session information

[0137] bidGet: / / Refresh to get dynamic information

[0138] record: / / Refresh and obtain quotation record

[0139] bidSend: / / quote

[0140] addPrice: / / The highest bidder adds price

[0141] xingquan: / / exercise rights

[0142] buxingquan: / / give up the right to exercise

[0143] myItem: / / My bidding information

[0144] sessions: / / Get the session list

[0145] itemList: / / Get the item list

[0146] bidGets: / / Get the dynamic data list of bids

[0147] maxContent: / / Get bidding announcement data

[0148] apply: / / Bidder registration

[0149] focus: / / Focus on the bidding target

[0150] focusCancel: / / Cancel focus

[0151] focusFlag: / / Get the focus status of the target

[0152] focusList: / / Focus List

[0153] baojiaMyPrice: / / Get a quote Get my quote

[0154] etc.

[0155] The present invention also includes a network bidding cloud service method based on the above system, including system docking implementation phase initialization work, pre-bidding target push process, bidding process quotation processing process and bidding end result feedback process, and operation and maintenance upgrade process when necessary, as follows.

[0156] <Initialization work during the system connection implementation phase>

[0157] Step S1001, the bidding cloud service pre-allocates a pair of ClientKey, ClientSecret and organization information to the transaction organization, which are used to encrypt and decrypt the request body (Request Body) and response body (Response Body) of the HTTP request and receive and send messages through WebSocket.

[0158] Step S1002: The bidding cloud service pre-assigns an institution admin user to the trading institution, and an exemplary name is, for example, "institution_admin".

[0159] Step S1003, the bidding cloud service pre-allocates a docking address (which can be in the form of a second-level domain name, an independent domain name, a specific port number, a specific IP, etc.) to the trading institution in preparation for possible future performance enhancement, performance isolation, and fault isolation.

[0160] Preferably, there is step S1004, where the bidding cloud service pre-registers the Internet exit IP list of the trading institution for the security authentication of the docking client IP address by the docking service end. If the security and network delay requirements are higher, a dedicated line connection can be used.

[0161] Step S1005, the front-end website of the institutional business system needs to develop a quotation list page, a quotation site page, and a personal bidding room page (because it needs to be in the same style as the original business system front-end website), and embed the JavaScript front-end code provided by the bidding cloud platform in these three pages - in this way, you only need to add three front-end pages with unified styles but no logical functions to the original business system, and then adjust the website front-end menu structure to add the bidding function. (Note: Here, the names of the js method names, div tags, and css style sheets in the page must not conflict with the js method names, div tags, and css style sheets used by the JavaScript front-end code.)

[0162] Step S1006, the organization business system identity authentication service (BusinessAuth) configuration adds an authentication client identity for the docking client (Docking Client) to use, that is, the docking client can also legally access the business system identity authentication service (BusinessAuth). That is, the business system identity authentication service can correctly process the verification login request from the docking client (Docking Client) and return the user's login status.

[0163] Step S1007, the institutional business system develops an interface for receiving the notice of the end of the bid, which can only accept the bid ID. This API address is provided to the docking client.

[0164] Step S1008: In the nginx or apache middleware on the front-end website of the organization’s business system, configure an independent prefix to forward HTTP requests, such as / bid, and add an independent prefix to forward WebSocket requests, such as / bid-ws. Set the protocol upgrade and timeout for the requests with these two prefixes, and forward them to the HTTP port and WebSocket port of the docking client respectively (ensure that all requests starting with this prefix are directly forwarded to the docking client).

[0165] Step S1009, configure the above-mentioned ClientKey, ClientSecret and the docking address assigned to the transaction institution (which can be a second-level domain name, an independent domain name, a specific port number, a specific IP, etc.), the API address for receiving bidding results, and the forwarding prefix URI into the corresponding configuration items of the configuration file of the docking client, and start the docking client.

[0166] <Pre-bidding bid push process> (such as Figure 2 (shown)

[0167] Step S21: The business personnel of the institution's business system push the targets that have been confirmed to be selected by bidding to the bidding cloud service. Specifically, it includes:

[0168] Step S2101, the business system calls the "pushing target information" address of the docking client through the API address and submits the target data;

[0169] Step S2102, the client forwarder determines that the current request is an HTTP request and uses the HTTP module to process it;

[0170] Step S2103: Since there is no bidding business logic, the request address and request content are not verified; instead, the request body (Request Body) of all parameters carried is encrypted using the pre-assigned ClientSecret, and the parameter ClientKey = pre-assigned ClientKey is added;

[0171] Step S2104, the forwarder forwards the processed request to the same URI of the docking server;

[0172] Step S2105, after the server filter intercepts the request, it first checks the ClientKey, and retrieves the ClientSecret, authorized IP address and organization information of the client from the cache or database;

[0173] Step S2106, checking whether the request source IP is from the authorized IP address range;

[0174] Step S2107, using the ClientSecret of the organization to try to decrypt the request body;

[0175] Step S2108, after normal decryption, call the bidding cloud user service (BidUserCenter) to obtain the identity of the admin user of the organization;

[0176] Step S2109, create a login user object such as the user "organization_admin" and put it into the request header;

[0177] Step S2110, routing the decrypted request with the logged-in user object header attached to a bidding push controller (PushController);

[0178] Step S2111, the bidding push controller (PushController) receives the "push target information" interface request and obtains the login user information (such as "organization_admin") from the header;

[0179] Step S2112: The bidding push controller is passed to the PushService layer to process the business logic;

[0180] Step S2113, PushService creates a subject and returns the subject id; the created subject is deemed to be created by the user (such as "organization_admin");

[0181] Step S2114: The response body is captured by the docking server filter, and the response body is encrypted using the ClientSecret of the organization and returned to the business system caller.

[0182] Step S2115: After receiving the response body, the docking client forwarder uses ClientSecret to decrypt the response body and returns it to the business system;

[0183] Step S2116: The business system receives the returned plain text of the target ID and completes the complete target push request.

[0184] Step S22: The institutional business system pushes the bidder information and deposit information to the bidding system in substantially the same manner.

[0185] The difference is that the bidding receiving method in PushService also checks whether the bidder has an account in the bidding cloud service. If not, create a bidder account such as "Organization_Username" in the bidding cloud user service (BidUserCenter). Note: This account cannot be logged in directly on the bidding cloud service end, and can only access the system and bid through docking.

[0186] The processing flow of subsequent responses is the same as that of target push, so I will not go into details.

[0187] <Bidding process quotation processing flow> (such as Figure 3 (shown)

[0188] Step S3001, the bidder completes the login on the trading institution website through the business system identity authentication service (BusinessAuth);

[0189] Step S3002: The bidder opens the bidding site page and bids for the target. The JavaScript front-end code is connected to execute the interface for obtaining the target static information. The first part of the interface URI address is the prefix of the docking client forwarder, followed by the corresponding interface address of the bidding cloud service actually called.

[0190] Step S3003, the nginx or apache middleware of the institution's business system forwards the request to the HTTP port of the docking client forwarder according to the independent prefix forwarding configured in the initialization process;

[0191] Step S3004, after receiving the request, the forwarder determines that the current request is an HTTP request and uses the HTTP module to process it;

[0192] Step S3005: If it is not a bidding push controller (PushController), it is necessary to call the business system identity authentication service (BusinessAuth) to verify the header information of the request and the login information of the current login user on the business system side; the business system identity authentication service returns the authentication result, confirming that the bidder is in a normal login state on the business system website, and obtains the user name;

[0193] Step S3006, the forwarder checks the returned result. If it is successful, it will encrypt the request body (Request Body) of all the parameters carried by the login user name information and the original quotation request information using the pre-assigned ClientSecret, and add the parameter ClientKey = pre-assigned ClientKey (this parameter is not encrypted);

[0194] Step S3007, the forwarder forwards the processed request to the same URI of the docking server;

[0195] Step S3008, after the docking server filter intercepts the request, it first checks the ClientKey, and retrieves the ClientSecret, authorized IP address and organization information of the docking client from the cache or database;

[0196] Step S3009, check whether the request source IP is from the authorized IP address range;

[0197] Step S3010, using the ClientSecret of the organization to try to decrypt the request body;

[0198] Step S3011, after normal decryption, retrieve the identity of the user who logged in by calling the bidding cloud user service (BidUserCenter) to obtain the parameter passed;

[0199] Step S3012, create a login user object (LoginUser) (for example, of the user "organization_username") and put it into the request header;

[0200] Step S3013, routing the restored request to the bid processing controller (BidController);

[0201] Step S3014, the bid processing controller (BidController) receives the "bid for the target" interface request and obtains the login user information ("institution_username") from the header login user object (LoginUser);

[0202] Step S3015, assemble the request and pass it to the BidService layer to process the business logic;

[0203] Step S3016, BidService verifies the price information, writes the quotation, and finally returns whether the quotation is successful; the quotation for the target is considered to be created by the user ("Organization_Username"); (This is the same as directly using the bidding cloud service to make a quotation, sharing the same BidService code, and all logics are the same);

[0204] Step S3017: The response body is captured by the docking server filter, and the response body is encrypted using the ClientSecret of the Client and returned to the docking client.

[0205] Step S3018: After receiving the response body, the docking client forwarder decrypts the response body using ClientSecret and returns the quotation page to the bidder.

[0206] Step S3019: The bidder opens the target site page and establishes a WebSocket request. In this link, the present invention only adds the WebSocket proxy design of the client forwarder and the same encryption and decryption logic as above. The rest of the design is the same as the original design of obtaining the target status and price changes. The specific steps are as follows: Figure 4 shown.

[0207] <Bidding end result feedback process>

[0208] Step S4001: When the bidding service is started, it will be connected to a message queue as a producer, and when any bidding ends, it will send bidding end information to the message queue;

[0209] Step S4002: A queue consumer thread on the docking server is also connected to the message queue and monitors messages in the queue;

[0210] Step S4003, when the bidding of a certain target ends, the docking server receives the end message; sends this message to the WebSocket server (DockingWS Server) for monitoring and pushing bidding results; the WebSocket server for monitoring and pushing bidding results calls the original query target information interface of the bidding service according to the target ID.

[0211] Step S4004, query the target information interface, and return detailed information of the target, including the institution to which the target belongs.

[0212] Step S4005, monitor and push the bidding result. The WebSocket server sends the end message of this bid and encrypts it using the ClientSecret of this organization.

[0213] Step S4006, push the bid result to the docking client of the institution to which the target belongs through the WebSocket connection and receive the bid result WebSocket client (DockingWS Client).

[0214] Step S4007, monitoring and receiving bidding results After receiving the message, the WebSocket client uses ClientSecret to decrypt it, initiates an HTTP request, and sends the decrypted message to the business system receiving bidding result interface (ReceiveResult API).

[0215] Step S4008, after receiving the request, the business system receives the bidding result interface, and then knows that the bid has ended, and calls the bid transaction record acquisition interface again. Here, the request is also called to the forwarder of the docking client, through an encrypted call to the server, which is the same as the method used in the pre-bidding bid push process, except that the interface is different, so it will not be repeated.

[0216] <Operation and Maintenance Upgrade Process>

[0217] For example, at least one of the following steps may be performed as required.

[0218] Step S5001, server performance enhancement, performance isolation, and fault isolation upgrade process.

[0219] Since an independent docking address (such as a second-level domain name, independent domain name, specific port number, specific IP, etc.) is opened for each trading organization during the initialization phase, when the system capacity is insufficient and needs to be expanded, or when the trading organization purchases a more advanced independent bidding server, the resolution of the docking address can be modified to point to the independent bidding server. If the docking address is in the form of an independent domain name or a second-level domain name, the client does not need to modify any configuration or restart, only the resolution needs to take effect. If the docking address is in the form of a port or IP, the docking client also needs to modify the configuration and restart.

[0220] Step S5002, adding business function flow.

[0221] Since the docking client does not have any business logic, all HTTP and WebSocket requests are forwarded to the docking server, which only encrypts the request and decrypts the response. Therefore, when adding business functions, you only need to modify the JavaScript script and call the new docking server interface. The docking client does not need to modify any configuration or restart.

[0222] Step S5003, abnormal connection process of the docking client.

[0223] Since the docking client and the docking server maintain a WebSocket connection, and report the docking client server status every few seconds and receive the docking server time calibration, even if it passes through security devices such as firewalls, it will not reach idle time and cause disconnection. Even if the connection is disconnected, the docking client still has a reconnection mechanism to try to re-establish the WebSocket connection.

[0224] In addition, it should be noted that:

[0225] 1. The use of the docking address is for performance upgrade or isolation reservation, which is not a necessary condition of the present invention.

[0226] 2. Pre-registering the export IP list of the organization is a more secure way to authenticate the client request, but is not a necessary condition of the present invention.

[0227] 3. Specific encryption and decryption methods are not limited to symmetric encryption, asymmetric encryption, digital signatures, etc.

[0228] 4. The request format used is not limited. It can be a form, json or xml data, or a file.

[0229] 5. The business system can push information by first pushing the activity, then pushing the target, and then pushing the bidders; or it can push all the relevant information of the target at one time through one request.

[0230] 6. "Organization_admin" and "Organization_username" are example naming conventions.

[0231] 7. Figure 5 In the process, the docking client and the original business system and the business system identity authentication service can be on the same server or on different servers. If they are not on the same server, the WebSocket client that monitors and receives bidding results will not be able to obtain the server monitoring data of the business system. The docking server and the bidding cloud service, bidding cloud user service, and bidding cloud bidding result push service can also be on the same server or on different servers.

Claims

1. A network bidding cloud service method, characterized in that: The online bidding cloud service system is adopted for implementation. The online bidding cloud service system includes a docking server, a docking client, a bidding cloud user service, a business system identity authentication service, a WebSocket server for obtaining the latest dynamic information of the target, a WebSocket client for obtaining the latest dynamic information of the target by the browser, and an interface for receiving bidding results by the business system; among which, the docking server includes a filter, a bidding push controller, a quotation processing controller, and a WebSocket server for monitoring and pushing bidding results; the docking client includes a forwarder and a WebSocket client for monitoring and receiving bidding results; The online bidding cloud service method includes the initialization work of the system docking implementation phase, the pre-bidding bid push process, the bidding process quotation processing process and the bidding end result feedback process; among them, the initialization work of the system docking implementation phase includes the following steps: Step S1001, the bidding cloud service pre-allocates a pair of ClientKey, ClientSecret and organization information to the trading organization, which are used to encrypt and decrypt the request body and response body of the HTTP request and receive and send messages through WebSocket; Step S1002, the bidding cloud service pre-assigns an institution admin user to the trading institution; Step S1003, the bidding cloud service pre-allocates a docking address to the trading institution; Step S1005, the front-end website of the institutional business system develops a quotation list page, a quotation site page, and a personal bidding room page, embeds the JavaScript front-end code provided by the bidding cloud platform in these three pages, and adjusts the website front-end menu structure; Step S1006, the institution business system identity authentication service configuration adds an authentication client identity for the docking client to use, so that the docking client can also legally access the business system identity authentication service, so that the business system identity authentication service can correctly process the verification login request from the docking client and return the user's login status; Step S1007, the institutional business system develops an interface for receiving the target end notification and accepting the target ID; and provides this API address to the docking client; Step S1008: In the middleware of the front-end website of the institution's business system, an independent prefix is ​​configured to forward HTTP requests, and an independent prefix is ​​added to forward WebSocket requests. The requests of these two prefixes are set with protocol upgrade and timeout, and forwarded to the HTTP port and WebSocket port of the docking client respectively; Step S1009, configure the above ClientKey, ClientSecret and the docking address assigned to the trading institution, the API address for receiving bidding results, and the forwarding prefix URI into the corresponding configuration items of the configuration file of the docking client, and start the docking client.

2. The network bidding cloud service method according to claim 1, characterized in that: Initialization work during the system docking implementation phase is still Including step S1004, the bidding cloud service pre-registers the export IP list of the transaction institution for security authentication of the IP address of the docking client by the docking server.

3. The network bidding cloud service method according to claim 1, characterized in that: The pre-bidding bid push process includes the following steps: Step S21, the business personnel of the institution's business system pushes the targets that have been confirmed to be selected by bidding to the bidding cloud service; Step S22: The institutional business system pushes the bidder information and deposit information to the bidding system.

4. The network bidding cloud service method according to claim 3, characterized in that: Step S21 includes the following steps: Step S2101, the business system calls the push target information address of the docking client through the API address and submits the target data; Step S2102, the client forwarder determines that the current request is an HTTP request and uses the HTTP module to process it; Step S2103, using the pre-assigned ClientSecret to encrypt all the parameter request bodies carried, and appending the parameter ClientKey=pre-assigned ClientKey; Step S2104, the forwarder forwards the processed request to the same URI of the docking server; Step S2105, after the server filter intercepts the request, it first checks the ClientKey, and retrieves the ClientSecret, authorized IP address and organization information of the client from the cache or database; Step S2106, checking whether the request source IP is from the authorized IP address range; Step S2107, using the ClientSecret of the transaction institution to try to decrypt the request body; Step S2108: After normal decryption, call the bidding cloud user service to obtain the identity of the admin user of the trading institution; Step S2109, create a login user object for the user and put it into the request header; Step S2110, routing the decrypted request with the logged-in user object header attached to the bidding push controller; Step S2111: The bidding push controller receives the push target information interface request and obtains the login user information from the header; Step S2112: The bidding push controller is passed to the PushService layer to process the business logic; Step S2113, PushService creates a subject and returns the subject id; the created subject is deemed to be created by the user; Step S2114: The response body is captured by the docking server filter, and the response body is encrypted using the ClientSecret of the organization and returned to the service system caller. Step S2115: After receiving the response body, the docking client forwarder uses ClientSecret to decrypt the response body and returns it to the business system; Step S2116: The business system receives the returned plain text of the target ID and completes the complete target push request.

5. The network bidding cloud service method according to claim 4, characterized in that: The difference between step S22 and step S21 is that the bidding receiving method in PushService also checks whether the bidder has an account in the bidding cloud service. If not, a bidder account is created in the bidding cloud user service. The account cannot log in directly on the bidding cloud service and can only access the system and bid through docking. The subsequent response processing flow and target push are the same as step S21.

6. The network bidding cloud service method according to claim 1, characterized in that: The bidding process includes the following steps: Step S3001, the bidder completes the login through the business system identity authentication service on the transaction institution website; Step S3002: The bidder opens the bidding site page and bids for the target. The JavaScript front-end code is connected to execute the interface for obtaining the target static information. The first part of the interface URI address is the prefix of the docking client forwarder, followed by the corresponding interface address of the bidding cloud service actually called. Step S3003, the institution business system middleware forwards the request to the HTTP port of the docking client forwarder according to the independent prefix forwarding configured in the initialization process; Step S3004, after receiving the request, the forwarder determines that the current request is an HTTP request and uses the HTTP module to process it; Step S3005: If the controller is not a bidding push controller, the business system identity authentication service is called to verify the header information of the request, and the login information of the current login user on the business system side is verified; The business system identity authentication service returns the authentication result, confirming that the bidder is logged in normally on the business system website, and obtains the user name; Step S3006, the forwarder checks the returned result. If it is successful, it will encrypt the request body of all parameters carried by the login user name information and the original quotation request information using the pre-assigned ClientSecret, and add the parameter ClientKey = pre-assigned ClientKey; Step S3007, the forwarder forwards the processed request to the same URI of the docking server; Step S3008, after the docking server filter intercepts the request, it first checks the ClientKey, and retrieves the ClientSecret, authorized IP address and organization information of the docking client from the cache or database; Step S3009, check whether the request source IP is from the authorized IP address range; Step S3010, using the ClientSecret of the organization to try to decrypt the request body; Step S3011, after normal decryption, retrieve the identity of the user who logged in by calling the bidding cloud user service to obtain the parameter passed; Step S3012, create a login user object and put it into the request header; Step S3013, routing the restored request to the quotation processing controller; Step S3014, the quotation processing controller receives the quotation interface request for the target and obtains the login user information from the login user object in the header; Step S3015, assemble the request and pass it to the BidService layer to process the business logic; Step S3016, BidService verifies the price information, writes the quotation, and finally returns whether the quotation is successful; The bid for the subject item is deemed to be created by the user; Step S3017: The response body is captured by the docking server filter, and the response body is encrypted using the ClientSecret of the Client and returned to the docking client. Step S3018, after receiving the response body, the docking client forwarder uses ClientSecret to decrypt the response body and returns it to the bidder's quotation page; In step S3019, the target site page opened by the bidder will establish a WebSocket request.

7. The network bidding cloud service method according to claim 1, characterized in that: The bidding result feedback process includes the following steps: Step S4001: When the bidding service is started, it will be connected to a message queue as a producer, and when any bidding ends, it will send bidding end information to the message queue; Step S4002: A queue consumer thread on the docking server is also connected to the message queue and monitors messages in the queue; Step S4003: When the bidding for a certain item ends, the docking server receives an end message; This message is sent to the WebSocket server for monitoring and pushing bidding results. The WebSocket server for monitoring and pushing bidding results calls the original bidding service information query interface according to the bid ID. Step S4004, query the subject information interface, and return detailed information of the subject, including the institution to which the subject belongs; Step S4005, monitoring and pushing the bidding result WebSocket server to encrypt the end message of this bid using the ClientSecret of this transaction institution; Step S4006, pushing the bid result to the WebSocket client of the docking client of the institution to which the target belongs through the WebSocket connection; Step S4007, after the WebSocket client receives the message, it decrypts it with ClientSecret, initiates an HTTP request, and sends the message to the business system to receive the bidding result interface; Step S4008, after the business system receives the request through the bidding result receiving interface, it will know that the bidding has ended and will call the bidding transaction record obtaining interface again.

8. The network bidding cloud service method according to claim 1, characterized in that: It also includes an operation and maintenance upgrade process, which includes at least one of the following steps: Step S5001, server performance enhancement, performance isolation, and fault isolation upgrade process: When the system capacity is insufficient and needs to be expanded, or when the trading organization purchases a more advanced independent bidding server, the resolution of the docking address is modified to point to the independent bidding server; Step S5002, adding business function flow: When adding business functions, you only need to modify the JavaScript script and call the new docking server interface. The docking client does not need to modify any configuration or restart. Step S5003, client connection exception process: The docking client and the docking server maintain a WebSocket connection, and report the docking client server status at regular intervals and receive the docking server time calibration; Even if there is a safety device in the middle, it will not reach the idle time and cause disconnection; If the connection is lost, the docking client will try to re-establish the WebSocket connection.

Images