CN111988360A - Session management method in cloud platform, storage medium and electronic device - Google Patents
Session management method in cloud platform, storage medium and electronic device Download PDFInfo
- Publication number
- CN111988360A CN111988360A CN202010692222.XA CN202010692222A CN111988360A CN 111988360 A CN111988360 A CN 111988360A CN 202010692222 A CN202010692222 A CN 202010692222A CN 111988360 A CN111988360 A CN 111988360A
- Authority
- CN
- China
- Prior art keywords
- user
- session
- login
- service
- response
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/62—Establishing a time schedule for servicing the requests
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Cardiology (AREA)
- General Health & Medical Sciences (AREA)
- Computer And Data Communications (AREA)
Abstract
The embodiment of the application discloses a session management method in a cloud platform, a storage medium and an electronic device. The method comprises the following steps: determining users who successfully log in from users who access the micro server, wherein the micro server provides services for the users in a reverse proxy mode through a gateway; and when detecting that the user initiates a service request to the micro server, triggering the micro server to prolong the effective time of the session of the user.
Description
Technical Field
The embodiment of the application relates to the field of information processing, and in particular relates to a session management method in a cloud platform, a storage medium and an electronic device.
Background
With the development of virtualization technology, service deployment on a cloud platform has become a trend, application deployment and value-added service expansion can be rapidly realized by using a large-scale data center and abundant computer hardware resources, but with the increase of user quantity and the pursuit of a lightweight application framework, a micro-service framework gradually changes into the sight of people, can create applications around service field components, and can be independently developed, managed, accelerated and deployed.
Dropwizard is a Java high performance framework for developing RESTful services. When a cloud platform uses Dropwizard to rapidly deploy a micro service framework, a management mechanism for Session of a user is lacked, and the traditional WEB server has the problems of complex configuration, heavy deployment and operation, and the like, so that the lightweight principle of the current micro service framework cannot be effectively met. However, after openness is used as a WEB server, the session of the user cannot be managed when the Dropwizard service is docked.
Disclosure of Invention
In order to solve any one of the above technical problems, embodiments of the present application provide a session management method in a cloud platform, a storage medium, and an electronic apparatus.
To achieve the purpose of the embodiment of the present application, an embodiment of the present application provides a session management method in a cloud platform, including:
determining users who successfully log in from users who access the micro server, wherein the micro server provides services for the users in a reverse proxy mode through a gateway;
and when detecting that the determined user initiates a service request to the micro server, triggering the micro server to prolong the effective time of the session of the user.
A storage medium having a computer program stored therein, wherein the computer program is arranged to perform the method as described above when executed.
An electronic device comprising a memory having a computer program stored therein and a processor arranged to execute the computer program to perform the method as described above.
One of the above technical solutions has the following advantages or beneficial effects:
the method comprises the steps that a user successfully logging in a user accessing a micro server is determined, wherein the micro server gateway provides service for the user in a reverse proxy mode, and when the fact that the determined user initiates a service request to the micro server is detected, the micro server is triggered to prolong the effective time of the session of the user, so that the management of the timeout time of the session between the user and the micro server is achieved, the problem that the user is automatically logged out is avoided, and the service request can be guaranteed to normally respond.
Additional features and advantages of the embodiments of the application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the embodiments of the application. The objectives and other advantages of the embodiments of the application may be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.
Drawings
The accompanying drawings are included to provide a further understanding of the embodiments of the present application and are incorporated in and constitute a part of this specification, illustrate embodiments of the present application and together with the examples of the embodiments of the present application do not constitute a limitation of the embodiments of the present application.
Fig. 1 is a flowchart of a session management method in a cloud platform according to an embodiment of the present disclosure;
fig. 2 is a structural diagram of a session management apparatus in a cloud platform according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application more apparent, the embodiments of the present application will be described in detail below with reference to the accompanying drawings. It should be noted that, in the embodiments of the present application, features in the embodiments and the examples may be arbitrarily combined with each other without conflict.
Fig. 1 is a flowchart of a session management method in a cloud platform according to an embodiment of the present disclosure. As shown in fig. 1, the method shown in fig. 1 is applied to a gateway, and the method includes:
in an exemplary embodiment, when a proxy server is capable of acting on hosts on an external network to access an internal network, this manner of proxy service is referred to as reverse proxy service. The proxy server now appears externally as a Web server that the external network can treat as a standard Web server without special configuration. The difference is that this server does not store the real data of any Web page, and all static Web pages or Common Gateway Interface (CGI) programs are stored on the internal Web server. Thus, attacks on the reverse proxy server do not destroy the Web page information, thus enhancing the security of the Web server. That is, the reverse proxy is a client that receives a connection request on the Internet (external network) by using a reverse proxy server, forwards the connection request to a server on the internal network, and returns the result obtained from the server to the client requesting the connection on the Internet.
In an exemplary embodiment, the reverse proxy may be deployed in a gateway, so as to implement lightweight deployment and reduce deployment cost.
in an exemplary embodiment, after a user who logs in successfully initiates a service request to a microserver, the microserver starts thread task timing for a Session identifier of a current user, and if the timing time is up, the user is automatically logged out and cannot continuously access the microserver. Therefore, the effective time of the session of the user is prolonged by triggering the micro server, so that the problem that the user is automatically logged out is avoided, and the service request can be ensured to normally respond.
According to the method provided by the embodiment of the application, the micro server is triggered to prolong the effective time of the session of the user by determining the user successfully logged in the user accessing the micro server, wherein the micro server provides service through the reverse proxy, when the determined user is detected to initiate the service request to the micro server, the management of the timeout time of the session between the user and the micro server is realized, the problem that the user is automatically logged out is avoided, and the service request can be ensured to normally respond.
The method provided by the embodiments of the present application is explained as follows:
in an exemplary embodiment, the determining users who successfully log in from among the users who access the microserver includes:
after a user initiates a login request to a micro-server positioned in an intranet through an external network, acquiring a login response of the login request sent by the micro-server;
and determining the user with successful login from the login response of the login request.
Based on the reverse proxy mechanism, the login request of the user is sent to the gateway with the reverse proxy function from the external network, and then sent to the micro server through the intranet by the gateway.
After receiving the login request sent by the intranet, the micro-service end verifies the login request. And if the verification result is an illegal request, returning a login response for identifying login failure. If the verification result is a legal request, the login request is verified to be passed, a unique Session identification is generated aiming at the current user, and a login response carrying the Session identification and the identification used for identifying the successful login is returned.
After receiving the login response of the micro server, the gateway determines the user who successfully logs in according to the identifier which is used for identifying whether the login is successful in the login response, and sends the login response to the user.
In an exemplary embodiment, the determining the user who successfully logs in from the login response of the login request includes:
analyzing a login success identifier and user identity information from a header in the login response;
and recording the user with successful login according to the successful login identification and the user identity information.
The micro server can add login success identification and user identity information through a Header of a login interface Response, on one hand, information is carried by using a blank field in a login Response, so that the information transmission efficiency can be effectively improved, and on the other hand, the user identity information is carried when the login Response is successful, so that a gateway can conveniently and quickly determine a user who successfully logs in.
In an exemplary embodiment, the destination IP address of the login response is used as the index of the user, and the login success identifier is stored;
detecting that the determined user initiates a service request to the microserver by the following method, including:
acquiring a source IP address of the service request;
judging whether the index corresponding to the login success identification stored locally has the source IP address;
and if the judgment result is that the source IP address exists, determining that the determined user initiates a service request to the micro server.
The destination IP address of the login response is used as a user index to store the login success identifier in the memory for subsequent request verification; whether a user who detects successful login initiates a service request to the micro server is determined by reading a source IP address in the service request and judging whether a login success identifier corresponding to the IP address is stored locally, so that the detection efficiency is improved.
In an exemplary embodiment, before the triggering micro server extends the effective time of the session of the user, the method further includes:
judging whether the service request accesses a service submitting interface of a micro server side;
and if the judgment result is that the business submitting interface of the micro server is accessed, executing triggering of the micro server to prolong the effective time of the conversation of the user.
By filtering and screening the service requests, the effective time of the session is prolonged aiming at the service requests of the service submitting interface of the access micro-server so as to ensure the normal response of the access requests.
In an exemplary embodiment, the determining whether the service request accesses a service submitting interface of a microserver includes:
obtaining the operation type of the service request;
comparing the operation type of the service request with a preset target operation type;
if the comparison result is that the operation type of the service request is one of the target operation types, the service request belongs to the target operation type;
wherein the target operation type satisfies the following condition: the micro server needs to complete the response to the service request of the target operation type before the session is overtime.
The filtering is carried out based on the operation type of the service request, so that the filtering efficiency of the service request can be improved, and the specific service request can be ensured to be responded within the effective time of the session.
In one exemplary embodiment, the target operation type is an operation type other than a GET operation.
The target operation type may be adding POST, modifying PUT, deleting DELETE, etc.
In an exemplary embodiment, the operation type of the service request is obtained from a method field in an HTTP message of the service request.
And judging whether the service request is a GET type request or not by analyzing the service request. And when judging that the request is other than the GET type, determining that the service request type belongs to a preset service operation type. Otherwise, when the GET type request is judged, the service request type is determined not to belong to the preset service operation type.
The requests initiated by the user to the micro-service end are all HTTP requests, wherein a request Method field in the HTTP requests is used for identifying a request action and describing the operation type of the browser where the user is located to the resources of the micro-service end at this time, and the operation type can be GET acquisition, POST addition, PUT modification, DELETE deletion and the like. When the value of the request Method field in the request is other than GET, the request belongs to a preset service operation type (i.e. a target operation type), which indicates that the Session cannot be timed out when the user performs a service operation, and at this time, the Session timeout countdown corresponding to the Session identifier of the user on the background server needs to be updated.
In an exemplary embodiment, the triggering the microserver to extend the effective time of the session of the user includes:
acquiring a session identifier of a session between the user and the micro server;
and sending the service heartbeat data corresponding to the session identification to the micro server.
The gateway can send service heartbeat data to the micro server to trigger the micro server to prolong the effective time of the session, so that the problem that a user logs out automatically is avoided.
In an exemplary embodiment, the session identifier is obtained from an authorization token field in a header of an HTTP message of the service request.
The session identifier is directly extracted from the service request sent by the user, so that the time for determining the session identifier is reduced, and the processing efficiency of the trigger operation can be improved.
In an exemplary embodiment, the micro server sends the identified service request subtype while sending the service heartbeat data corresponding to the session identifier to the micro server, and notifies the micro server to set the session timeout time corresponding to the session identifier according to the service request subtype.
Specifically, the service requests belonging to the preset business operation type can be further sub-typed according to the Method field value, for example, one Method field value corresponds to one sub-type. The method comprises the steps of establishing a corresponding relation between a plurality of subtypes and a plurality of session timeout countdown updating strategies in advance, wherein recovery values of session timeout countdown under different updating strategies are different, and the recovery values can be specifically determined according to service response time of a pre-counted service end to a service request of the subtype. For example, for a subtype service request with a service response time greater than a preset time threshold, the update policy may be to directly update the Session timeout countdown corresponding to the Session identifier to a preset Session timeout time; for a subtype service request with a service response time less than or equal to the preset duration threshold, the update policy may be to update the Session timeout countdown corresponding to the Session identifier to be one-half of the preset Session timeout time. The service response time refers to time consumed by the server from receiving the service request to sending a corresponding response.
In an exemplary embodiment, the micro server is a Dropwizard server;
sending the service heartbeat data corresponding to the session identifier to the microserver, including:
and sending the service heartbeat data carrying the session identifier to the micro server by calling a service heartbeat Restful interface of the Dropwizard server.
RESTful is a specification, constraint and principle of API architecture design;
and transmitting the Session identification of the user by using an RESTful interface, and verifying the Session identification by combining the information recorded by the micro server, thereby updating the life cycle of the Session and achieving the purpose of Session management of the user.
The openness can be used as a gateway to interface with a Dropwizard server.
In an exemplary embodiment, after sending the service heartbeat data corresponding to the session identifier to the microserver, the method includes:
receiving a heartbeat response fed back by the micro server to the service heartbeat data;
and determining whether the triggering operation is successful according to the heartbeat response.
After receiving the service heartbeat of the user sent by the OpenResty gateway, the micro-service end queries in the memory by taking the Session identification in the service heartbeat as an index. If the Session identifier is inquired, the micro-service terminal calls a function interface to update the Session timeout countdown corresponding to the Session identifier, and the response to the gateway is successful. If the query fails, no session timeout countdown operation is performed, and the response to the gateway fails.
If the gateway receives the information of successful response, the triggering operation is successful; otherwise, if the gateway receives the information of response failure, the gateway indicates that the triggering operation fails.
Through the interaction of the gateway and the service heartbeat data of the micro-service terminal, the overtime time of the session can be prolonged, and the session can not quit overtime in the using process of a user.
In an exemplary embodiment, after determining that the login of the user accessing the microserver is successful, the method further includes:
receiving a query request of a user heartbeat packet initiated by the determined user, wherein the operation type of the user heartbeat packet is GET, the GET carries a session identifier of a session between the user and the micro server, and the GET is used for querying whether the session corresponding to the session identifier is overtime or not;
and sending a query request of the user heartbeat packet to the micro server.
In an exemplary embodiment, after the sending the user heartbeat packet to the microserver, the method further includes:
receiving a query response sent by the micro server, wherein the query response carries result information whether the session corresponding to the session identifier is overtime or not;
and sending the query response to the user.
The detection mechanism of the heartbeat of the user is to determine whether the session is timed out based on the query operation, so as to determine whether the user can continue to initiate the service request.
Different from the way of carrying out heartbeat trigger among the correlation technique, this application embodiment has realized the trigger of dual heartbeat, include:
(1) user heartbeat between browser where user is located and background micro-server
The heartbeat of the user is triggered at regular time, the invocation of a rest interface can be realized by using a foreground ajax technology, and the purpose is to carry a session identifier cached by a client to inquire whether a background session is overtime or not;
(2) service heartbeat of gateway and micro-service terminal
The service heartbeat belongs to event heartbeat, namely, when a user initiates a trigger when a browser submits a non-GET request, the call of a rest interface can be realized by using a Lua module of OpenResty, so that a background updates the timeout time of the session after the trigger, and the session cannot be overtime exited in the using process of the user.
In an exemplary embodiment, if the heartbeat response is a failure response or the inquiry response is a session timeout, the method further comprises:
and deleting the local record of successful login corresponding to the session identifier.
And if the received information fed back by the micro server indicates that the session is overtime or the overtime cannot be prolonged, deleting the log-in success record corresponding to the session identifier to end the management of the gateway on the session.
If the user initiates the service request under the unknown condition, the gateway does not record that the user is the user with successful login, the service request can be directly rejected, and interaction with the micro-service terminal aiming at the service request is not needed.
In an exemplary embodiment, if the heartbeat response is a failure response or the inquiry response is a session timeout, the method further comprises:
and instructing the browser used by the user to delete the session identification of the session.
After the user logs in, the micro-service end automatically generates a Session identifier unique to the user, responds to the browser end of the user through a login interface, records the Session identifier in the browser Cookie, and can stop the user from continuing to use the Session to initiate a service request by deleting the Session identifier, so that the purpose of ending the Session is achieved.
In an exemplary embodiment, the instructing the browser used by the user to delete the session identifier of the session includes:
when the session identifier is stored in cookies of the small text file of the browser, setting corresponding identifier information in a Set-Cookie of an HTTP header of a notification or query response corresponding to the heartbeat response, wherein the identifier information is used for indicating the operation of deleting the session identifier;
and sending a notification or query response corresponding to the heartbeat response carrying the identification information to the browser.
The browser is instructed to delete the session identifier, so that the user cannot use the session identifier to initiate a service request again; in addition, the information is transmitted by using the field of the message header, so that the data transmission quantity is small and the transmission efficiency is high.
In an exemplary embodiment, after determining that the login of the user accessing the microserver is successful, the method further includes:
after detecting that a user initiates a logout request, acquiring a login response of the logout request sent by the micro server;
and if the login response of the login request determines that the user login request is legal, deleting the local record of the user with successful login.
After receiving the login response for the logout request as legal, identifying that the session between the user and the micro-service terminal is ended, deleting the local record of the user who successfully logs in, and ending the maintenance work of the session.
The following description takes an application scenario provided in the embodiment of the present application as an example:
fig. 2 is a schematic diagram of a session management system according to an embodiment of the present application. As shown in fig. 2, the system shown in fig. 2 includes an openreserve gateway and a Dropwizard server, where:
the OpenResty gateway is used for realizing the transmission of the reverse proxy and the service heartbeat;
after a reverse proxy forwards a user login, before a service request is initiated, performing type identification on the service request, when the service request is a non-GET request, determining that the service request belongs to a request with a specific service operation type, interacting with a Dropwizard server through an RESTful interface, and updating the Session time of the user in a memory of the Dropwizard server, wherein the non-GET request is that the Session cannot be overtime when the user performs service operation;
and the Dropwizard server is used for realizing user Session management and service processing, passively receiving the RESTful request and controlling logic according to the actual service.
In the system, after a user logs in, a background Dropwizard micro server automatically generates a unique Session identification of the user, responds to a browser end of the user through a login interface, and records the Session identification in a browser Cookie, wherein the Cookie refers to data stored in a local terminal of the user for identifying the identity of the user and tracking the Session; the background Dropwizard micro server starts thread task timing according to the current user Session identification, a user who is not updated Session in a fixed period can be automatically logged out of the system, and if the user has a service submitting interface for accessing the server, the OpenResty gateway can update the timing of the user Session identification on the Dropwizard server through triggering heartbeat by a reverse proxy, so that the Session is not overtime when responding to a service request.
In the system, the openreserve gateway can be used as a gateway proxy, the user request is filtered and distributed, and the user Session identifier generated by the background service is transmitted by using a RESTful interface, so that the aims of triggering the user heartbeat and updating the user Session based on the reverse proxy are fulfilled; in addition, Session identification verification, updating and life cycle maintenance can be performed by combining with a background service memory record, so that the purpose of user Session management is achieved, and the problem of user Session management under the deployment of a Dropwizard framework built based on a reverse proxy is solved.
The flow of the embodiment of the present application will be described below by taking the system shown in fig. 2 as an example, specifically as follows.
Step 201, a browser on an external network side initiates a login request of a user to a Dropwizard server on an internal network side, wherein the login request includes user identity information.
In this step, the user can log in the Dropwizard service background through the WEB interface on the browser, input user identity information (user name, password) and verification code, click the login button and submit the login button to the background service side through a POST request.
Step 202, after receiving the login request of the user, the front openresource gateway on the internal network side sends the login request to the Dropwizard server of the internal network.
Step 203, after verifying that the login request of the user passes, the Dropwizard server generates a Session identifier of the user, sends a login response carrying the user identity information, the Session identifier and the login success identifier to the browser, and starts Session timeout countdown corresponding to the Session identifier to maintain the login state of the user. Specifically, the Session identifier is deleted when the countdown is finished, and the user logs in the network.
In this step, the Dropwizard server may verify the login request of the user according to a preset system security policy, for example, whether the carried user name, password, and verification code are correct, which may be specifically implemented by using any existing verification technology. And if the verification result is an illegal request, returning a login response for identifying login failure to the browser. If the verification result is a legal request, the login request is verified to be passed, a unique Session identification is generated for the current user, the Header of the login interface Response is returned to the WEB interface of the browser through the OpenResty gateway, and meanwhile, a login success identification and user identity information are added in the Header.
In addition, for example, starting the session timeout countdown corresponding to the session identifier may specifically include: after verifying that the login request of the user passes, the Dropwizard server can record the user Session identifier in the memory Map object, start a thread timing task corresponding to the user Session identifier according to the user Session timeout time set by a preset system security policy, decrease the timing task on the basis of the Session timeout time until the time is cleared, clear the user Session identifier, log out the login state of the user, and stop a timer.
And step 204, the openreserve gateway receives the login response of successful login, stores the login success identifier of the user in the response, and sends the response to the browser.
In specific implementation, the openreserve gateway analyzes the login success identifier in the Header when processing the response, and stores the login success identifier in the memory by taking the destination IP address of the response as the user index for verification of the subsequent request.
And step 205, after receiving a login response of successful login from the Dropwizard server, the browser extracts the Session identification and the user identity information for storage.
In this step, the browser can automatically analyze the Set-Cookie information carried in the Header of the response, and record the Session identifier and the user identity information in the Set-Cookie information in the browser Cookie for use when a service request is subsequently initiated.
Step 206, the browser initiates a service request to the Dropwizard server.
Step 207, the openreserve gateway receives the service request from the browser, and checks whether the user corresponding to the service request logs in successfully. If so, step 209 is performed, otherwise step 208 is performed.
In this step, the openreserve gateway reads the source IP address in the service request, and determines whether a login success identifier corresponding to the IP address is stored locally.
And step 208, the Openresty gateway refuses to send the service request to the Dropwizard server, and returns an abnormal request response to the browser.
In this step, after the openness gateway verifies that the service request fails (i.e., the login success identifier corresponding to the source IP address where the service request is not stored locally), the openness gateway redirects the service request of the browser (returns to http 302), so that the browser returns to the login interface.
And step 209, the openreserve gateway identifies the type of the service request. If the service request type belongs to the preset service operation type, triggering a service heartbeat, and executing step 211, otherwise, not triggering the service heartbeat, and executing step 210.
In this step, it can be determined whether the service request is a GET type request by parsing the service request. And when judging that the request is other than the GET type, determining that the service request type belongs to a preset service operation type. Otherwise, when the GET type request is judged, the service request type is determined not to belong to the preset service operation type.
In the embodiment of the invention, the requests initiated by the browser to the background server are all HTTP requests. The request Method field in the HTTP request is used for identifying a request action, and describes the operation type of the browser for the resource of the background server at this time, where the operation type may be GET, POST, PUT, DELETE, or the like. When the value of the request Method field in the request is other than GET, the request belongs to a preset service operation type, which indicates that the user at the browser end is performing service operation, Session cannot be overtime, and at this time, Session timeout countdown corresponding to the Session identifier of the user at the background server end needs to be updated.
Step 210, the openreserve gateway forwards the service request of the non-preset service operation type to the Dropwizard server for service response.
Step 211, the openresource gateway initiates a service heartbeat of the user under the service request to the Dropwizard server.
In this step, after the service request of the browser is verified by the openness gateway, the service request is further analyzed, and the Session identifier (the Authentication-Token field located in the TTTP header information) carried in the service request is extracted. After the extraction is successful, the Openresty gateway triggers the calling of a service heartbeat Restful interface of the Dropwizard server side, and transmits a Session identification.
Step 212, the Dropwizard server checks the Session identifier in the received service heartbeat of the user. If the verification is successful, execute step 213-214; if the verification fails, steps 215 and 216 are performed.
And step 213, updating the Session timeout countdown corresponding to the Session identifier of the user by the Dropwizard server, and successfully responding to the OpenResty gateway.
In step 214, the openresource gateway receives the successful response of the Dropwizard server, and forwards the service request of the preset service operation type to the Dropwizard server for service response.
Step 215, the Dropwizard server side fails to respond to the openresistance gateway.
Step 216, the openness gateway receives the failure response of the Dropwizard server, clears the Session identifier of the user in the locally stored service request, and executes step 208. Optionally, the openness gateway further sets HTTP response header Set-Cookie information to instruct the browser to clear the cached Cookie information.
In step 212 and 216, after receiving the service heartbeat of the user sent by the openresource gateway, the Dropwizard server queries in the memory by using the Session identifier in the service heartbeat as an index. If the Session identifier is inquired, the Dropwizard server calls a function interface to update the Session timeout countdown corresponding to the Session identifier, and the response to the OpenResty gateway is successful. And if the query fails, no session timeout countdown operation is carried out, and the response failure is sent to the OpenResty gateway.
The updating of the Session timeout countdown corresponding to the Session identifier may be updating the Session timeout countdown corresponding to the Session identifier to a preset Session timeout time. Specifically, the time management of the user Session is a thread task executed in seconds, the Session timeout time (i.e., the Session timeout time corresponding to the Session identifier) recorded by the user is automatically decremented to 0 and is then incremented every second execution, and the update Session timeout countdown is the Session timeout time set by the security policy and reassigned to the auto-decrement variable.
More preferably, the service requests belonging to the preset business operation type can be further sub-typed according to the Method field value, for example, a Method field value corresponds to a sub-type. The method comprises the steps of establishing a corresponding relation between a plurality of subtypes and a plurality of session timeout countdown updating strategies in advance, wherein recovery values of session timeout countdown under different updating strategies are different, and the recovery values can be specifically determined according to service response time of a pre-counted service end to a service request of the subtype. For example, for a subtype service request with a service response time greater than a preset time threshold, the update policy may be to directly update the Session timeout countdown corresponding to the Session identifier to a preset Session timeout time; for a subtype service request with a service response time less than or equal to the preset duration threshold, the update policy may be to update the Session timeout countdown corresponding to the Session identifier to be one-half of the preset Session timeout time. The service response time refers to time consumed by the server from receiving the service request to sending a corresponding response. In the preferred embodiment, in step 211, the openreserve gateway needs to carry the subtype of the service request identified by the openreserve gateway in the service heartbeat of the user under the service request initiated by the Dropwizard server.
In the embodiment of the invention, all legal service requests of a user are forwarded to a Dropwizard server through an Openresty gateway agent, a Lua script can be added by combining with an Lua (lightweight and compact scripting language) module integrated in Openresty, the code in the script realizes the login success identification of a verification memory, after the verification is successful, the type of the user service request is analyzed according to the value of a Method field, a service heartbeat interface is triggered when the analysis monitors that the user has a non-GET type service request action, and the user Session timeout countdown recorded by a background service memory is updated.
In addition, after step 205, the technical solution provided by the present invention further includes the following steps:
and step 217, the browser periodically sends a user heartbeat packet carrying the Session identifier of the user to the Dropwizard server through the Openresty gateway.
In this step, after the user successfully logs in, the browser triggers a user heartbeat task, and the user heartbeat task reads the user name and the Session identifier recorded in the Cookie and sends a user query GET request (i.e., a user heartbeat packet) to the Dropwizard server, where the user query GET request includes the user name and the Session identifier.
Step 218, after receiving the heartbeat packet of the user, the Dropwizard server queries whether the Session identifier of the user in the heartbeat packet of the user is stored locally.
If yes, a response (for example, a user name) for identifying the success of the query is returned to the browser through the OpenResty gateway; if the query fails or does not exist, a response (e.g., null) identifying the query failure is returned to the browser via the openreserve gateway.
Step 219, after receiving the response that the identifier query is successful, the browser does not process the request; otherwise, after receiving the response of the identifier query failure, the browser considers that the Session of the user of the Dropwizard server side is cleared, stops sending the heartbeat packet of the user, clears the saved Session identifier and the user identity information, and jumps to the login interface.
Optionally, the scheme further includes step 220, the browser monitors a logout instruction of the user, and initiates a logout request carrying the Session identifier of the user and the user identity information to the Dropwizard server through the openness gateway;
and after verifying the user Session identification and the user identity information and successfully determining that the logout request is legal, the Dropwizard server clears the user Session identification stored in the memory, stops timing of the timeout countdown of the related Session, and returns a logout response after the logout request is successful.
And the Openresty gateway analyzes the target IP address in the log-out response, clears the login success identifier corresponding to the target IP address recorded in the memory, and the whole session of the user is ended.
In the above flow, as can be seen from the contents of step 212 and step 217, both the client and the openresource gateway send heartbeat data to the Dropwizard server, so that triggering of dual heartbeats is realized, where:
(1) the heartbeat of the user at the client and the heartbeat of the user at the background server belong to timing heartbeat, and can be realized by realizing the calling of a rest interface through a foreground ajax technology, so as to carry the session identifier cached by the client to inquire whether the background session is overtime or not.
(2) The service heartbeat of the Openresty gateway agent and the background server belongs to an event heartbeat, and can be realized by using a Lua module of Openresty to realize the calling of a rest interface, wherein the event heartbeat is only triggered when a client submits a non-GET request (whether a user performs configuration operation is identified), and the background Dropwizard server updates the timeout time of the session after the trigger, so that the session cannot be overtime exited in the using process of the user.
The method provided by the embodiment of the application has the following advantages that:
1. the safety is high: the Openresty gateway and the Dropwizard server perform double check on information sent by the user, and the client and the Openresty gateway perform double heartbeat on the Dropwizard server in the session process, so that the safety of the user in login and the session process is guaranteed.
2. And (3) light weight deployment: the agent tool is installed by one key, so that the Openresty gateway has the function of providing the reverse agent service for the Dropwizard server and the function of providing the service by using the reverse agent for the Dropwizard server, and complex system configuration is not needed.
3. The design flow is simple and easy and the practicality is strong: the whole design flow is simple and easy to understand, and the functions can support user Session management based on a reverse proxy microservice deployment scene.
4. High performance: deployment based on the Openresty + Dropwizard framework has less resource consumption and supports distributed deployment.
5. High concurrency: the use of the openreserve component can support the requirements of highly concurrent configuration development scenarios.
6. The expansibility is strong: session management based on the micro-service framework can be used for interfacing various functions of user security policies, user black and white lists, user group management, user forced offline and the like under different scenes.
7. Supporting multi-platform deployment: the components depended by the invention support multi-platform deployment, and are applicable to Linux and Windows systems.
An embodiment of the present application provides a storage medium, in which a computer program is stored, wherein the computer program is configured to perform the method described in any one of the above when the computer program runs.
An embodiment of the application provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the computer program to perform the method described in any one of the above.
It will be understood by those of ordinary skill in the art that all or some of the steps of the methods, systems, functional modules/units in the devices disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed by several physical components in cooperation. Some or all of the components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on computer readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). The term computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data, as is well known to those of ordinary skill in the art. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by a computer. In addition, communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media as known to those skilled in the art.
Claims (21)
1. A session management method in a cloud platform is applied to a gateway, and the method comprises the following steps:
determining users who successfully log in from users who access the micro server, wherein the micro server provides services for the users in a reverse proxy mode through a gateway;
and when detecting that the determined user initiates a service request to the micro server, triggering the micro server to prolong the effective time of the session of the user.
2. The method of claim 1, wherein determining users who successfully log on among the users accessing the microserver comprises:
after a user initiates a login request to a micro-server positioned in an intranet through an external network, acquiring a login response of the login request sent by the micro-server;
and determining the user with successful login from the login response of the login request.
3. The method of claim 2, wherein determining the user who successfully logged in from the login response of the login request comprises:
analyzing a login success identifier and user identity information from a header in the login response;
and recording the user with successful login according to the successful login identification and the user identity information.
4. The method of claim 3, wherein:
taking the destination IP address of the login response as the index of the user, and storing the login success identifier;
detecting that the determined user initiates a service request to the microserver by the following method, including:
acquiring a source IP address of the service request;
judging whether the index corresponding to the login success identification stored locally has the source IP address;
and if the judgment result is that the source IP address exists, determining that the determined user initiates a service request to the micro server.
5. The method of claim 1, wherein before the triggering microserver extends the active time of the user's session, the method further comprises:
judging whether the service request accesses a service submitting interface of a micro server side;
and if the judgment result is that the business submitting interface of the micro server is accessed, executing triggering of the micro server to prolong the effective time of the conversation of the user.
6. The method of claim 5, wherein the determining whether the service request accesses a service submission interface of a microserver comprises:
obtaining the operation type of the service request;
comparing the operation type of the service request with a preset target operation type;
if the comparison result is that the operation type of the service request is one of the target operation types, the service request belongs to the target operation type;
wherein the target operation type satisfies the following condition: the micro server needs to complete the response to the service request of the target operation type before the session is overtime.
7. The method of claim 6, wherein the target operation type is an operation type other than a GET operation.
8. The method according to claim 6 or 7, wherein the operation type of the service request is obtained from a method field in an HTTP message of the service request.
9. The method of claim 1, wherein the triggering the microserver to extend the active time of the session of the user comprises:
acquiring a session identifier of a session between the user and the micro server;
and sending the service heartbeat data corresponding to the session identification to the micro server.
10. The method of claim 9, wherein the session identifier is obtained from an authorization token field in a header of an HTTP packet of the service request.
11. The method of claim 10,
and sending the identified sub-type of the service request while sending the service heartbeat data corresponding to the session identifier to the micro server, and informing the micro server to set the session timeout time corresponding to the session identifier according to the sub-type of the service request.
12. The method according to any one of claims 9 to 11,
the micro server is a Dropwizard server;
sending the service heartbeat data corresponding to the session identifier to the microserver, including:
and sending the service heartbeat data carrying the session identifier to the micro server by calling a service heartbeat Restful interface of the Dropwizard server.
13. The method according to claim 9, wherein after sending the service heartbeat data corresponding to the session identifier to the microserver, the method comprises:
receiving a heartbeat response fed back by the micro server to the service heartbeat data;
and determining whether the triggering operation is successful according to the heartbeat response.
14. The method of claim 1, wherein after determining the successful login user of the users accessing the microserver, the method further comprises:
receiving a query request of a user heartbeat packet initiated by the determined user, wherein the operation type of the user heartbeat packet is GET, the GET carries a session identifier of a session between the user and the micro server, and the GET is used for querying whether the session corresponding to the session identifier is overtime or not;
and sending a query request of the user heartbeat packet to the micro server.
15. The method of claim 14, wherein after sending the user heartbeat packet to the microserver, the method further comprises:
receiving a query response sent by the micro server, wherein the query response carries result information whether the session corresponding to the session identifier is overtime or not;
and sending the query response to the user.
16. The method according to claim 13 or 15, wherein if the heartbeat response is a failure response or the inquiry response is a session timeout, the method further comprises:
and deleting the local record of successful login corresponding to the session identifier.
17. The method according to claim 13 or 15, wherein if the heartbeat response is a failure response or the inquiry response is a session timeout, the method comprises:
and instructing the browser used by the user to delete the session identification of the session.
18. The method of claim 17, wherein the instructing the browser used by the user to delete the session identifier of the session comprises:
when the session identifier is stored in cookies of the small text file of the browser, setting corresponding identifier information in a Set-Cookie of an HTTP header of a notification or query response corresponding to the heartbeat response, wherein the identifier information is used for indicating the operation of deleting the session identifier;
and sending a notification or query response corresponding to the heartbeat response carrying the identification information to the browser.
19. The method of claim 1, wherein after determining the successful login user of the users accessing the microserver, the method further comprises:
after detecting that a user initiates a logout request, acquiring a login response of the logout request sent by the micro server;
and if the login response of the login request determines that the user login request is legal, deleting the local record of the user with successful login.
20. A storage medium, in which a computer program is stored, wherein the computer program is arranged to perform the method of any of claims 1 to 19 when executed.
21. An electronic device comprising a memory and a processor, wherein the memory has stored therein a computer program, and wherein the processor is arranged to execute the computer program to perform the method of any of claims 1 to 19.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010692222.XA CN111988360B (en) | 2020-07-17 | 2020-07-17 | Session management method in cloud platform, storage medium and electronic device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010692222.XA CN111988360B (en) | 2020-07-17 | 2020-07-17 | Session management method in cloud platform, storage medium and electronic device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111988360A true CN111988360A (en) | 2020-11-24 |
| CN111988360B CN111988360B (en) | 2023-06-20 |
Family
ID=73438691
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010692222.XA Active CN111988360B (en) | 2020-07-17 | 2020-07-17 | Session management method in cloud platform, storage medium and electronic device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111988360B (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112751854A (en) * | 2020-12-30 | 2021-05-04 | 福州掌中云科技有限公司 | SSO login method and system |
| CN113076462A (en) * | 2021-03-25 | 2021-07-06 | 恒安嘉新（北京）科技股份公司 | Network session data query method, device, equipment and medium |
| CN113746941A (en) * | 2021-11-04 | 2021-12-03 | 深圳市明源云采购科技有限公司 | Method, device and storage medium for removing restriction of third-party cookie |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070078986A1 (en) * | 2005-09-13 | 2007-04-05 | Cisco Technology, Inc. | Techniques for reducing session set-up for real-time communications over a network |
| US20080178278A1 (en) * | 2007-01-22 | 2008-07-24 | Doron Grinstein | Providing A Generic Gateway For Accessing Protected Resources |
| US7873994B1 (en) * | 2005-06-27 | 2011-01-18 | Juniper Networks, Inc. | Management of session timeouts in an SSL VPN gateway |
| CN102739680A (en) * | 2012-06-28 | 2012-10-17 | 用友软件股份有限公司 | Session life prolonging device and method |
| CN108683675A (en) * | 2018-05-23 | 2018-10-19 | 南京联创信息科技有限公司 | Report activating method based on SSO extending sessions durations |
| US20190020665A1 (en) * | 2017-07-11 | 2019-01-17 | Cisco Technology, Inc. | Securing micro-services |
-
2020
- 2020-07-17 CN CN202010692222.XA patent/CN111988360B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7873994B1 (en) * | 2005-06-27 | 2011-01-18 | Juniper Networks, Inc. | Management of session timeouts in an SSL VPN gateway |
| US20070078986A1 (en) * | 2005-09-13 | 2007-04-05 | Cisco Technology, Inc. | Techniques for reducing session set-up for real-time communications over a network |
| US20080178278A1 (en) * | 2007-01-22 | 2008-07-24 | Doron Grinstein | Providing A Generic Gateway For Accessing Protected Resources |
| CN102739680A (en) * | 2012-06-28 | 2012-10-17 | 用友软件股份有限公司 | Session life prolonging device and method |
| US20190020665A1 (en) * | 2017-07-11 | 2019-01-17 | Cisco Technology, Inc. | Securing micro-services |
| CN108683675A (en) * | 2018-05-23 | 2018-10-19 | 南京联创信息科技有限公司 | Report activating method based on SSO extending sessions durations |
Non-Patent Citations (3)
| Title |
|---|
| 张晶等: "一种微服务框架的实现", 《计算机系统应用》 * |
| 张晶等: "一种微服务框架的实现", 《计算机系统应用》, no. 04, 15 April 2017 (2017-04-15) * |
| 陈建海;陈淼;浦云明;: "基于微服务架构B/S系统的性能分析", 计算机系统应用, no. 02 * |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112751854A (en) * | 2020-12-30 | 2021-05-04 | 福州掌中云科技有限公司 | SSO login method and system |
| CN113076462A (en) * | 2021-03-25 | 2021-07-06 | 恒安嘉新（北京）科技股份公司 | Network session data query method, device, equipment and medium |
| CN113076462B (en) * | 2021-03-25 | 2024-04-30 | 恒安嘉新（北京）科技股份公司 | Network session data query method, device, equipment and medium |
| CN113746941A (en) * | 2021-11-04 | 2021-12-03 | 深圳市明源云采购科技有限公司 | Method, device and storage medium for removing restriction of third-party cookie |
| CN113746941B (en) * | 2021-11-04 | 2022-02-08 | 深圳市明源云采购科技有限公司 | Method, device and storage medium for removing restriction of third-party cookie |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111988360B (en) | 2023-06-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109587133B (en) | Single sign-on system and method | |
| CN111988360B (en) | Session management method in cloud platform, storage medium and electronic device | |
| US11122067B2 (en) | Methods for detecting and mitigating malicious network behavior and devices thereof | |
| US11750651B2 (en) | Honeypots for infrastructure-as-a-service security | |
| CN112822222B (en) | Login verification method, automatic login verification method, server and client | |
| CN112261172B (en) | Service addressing access method, device, system, equipment and medium | |
| EP4161012A1 (en) | Authentication method and apparatus, electronic device, server, program, and storage medium | |
| CN108924210A (en) | Service request processing method, device, server and storage medium | |
| CN106302308B (en) | Trust login method and device | |
| US7089311B2 (en) | Methods, systems and computer program products for resuming SNA application-client communications after loss of an IP network connection | |
| WO2021027600A1 (en) | Single log-in method, apparatus and device, and computer-readable storage medium | |
| CN114902612A (en) | Edge network based account protection service | |
| US10728267B2 (en) | Security system using transaction information collected from web application server or web server | |
| CN110764871A (en) | Cloud platform-based mimicry application packaging and control system and method | |
| CN112968963B (en) | WebSocket-based method for forced real-time offline of user | |
| JP4751379B2 (en) | Automated security platform | |
| CN111209349A (en) | Method and device for updating session time | |
| US20200267146A1 (en) | Network analytics for network security enforcement | |
| CN115941224A (en) | Network access information management method and device and computer readable storage medium | |
| CN110430062A (en) | Logging request processing method, device, equipment and medium | |
| CN116647572B (en) | Access endpoint switching method, device, electronic equipment and storage medium | |
| US20220166791A1 (en) | Content delivery network (CDN)-based bot detection service with stop and reset protocols | |
| CN113422784B (en) | Login certificate updating method and device, computer equipment and storage medium | |
| CN116015824A (en) | Unified authentication method, equipment and medium for platform | |
| CN116996238A (en) | Processing method and related device for network abnormal access |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |