CN112015383A - Login method and device - Google Patents

Abstract

The invention discloses a login method and device, and relates to the technical field of computers. A specific implementation of the method includes: intercepting a request message and a response message corresponding to the request message; judging whether the user is logged in according to a predefined login judgment rule and a status code in the response message; wherein, the login judgment rule sets There are status codes and meanings represented by the status codes; when the user is not logged in, the login address information is obtained from the response message to log in based on the login address information. In this method, after intercepting the request message and the corresponding response message, the client determines that the user has not logged in based on the set login judgment rule and the response message, and obtains the login address information from the response message, and then completes the login. This method implements a flexible login method. The client only needs to intercept the login and does not need to care which address is used to log in.

Description

A login method and device

technical field

The present invention relates to the field of computers, and in particular, to a login method and device.

Background technique

At present, most applications are developed in a way of separating the client and the server. The client uses Vue, React and other technologies, and the server provides an interface. In an application program, user login is the most basic function, and the prior art generally only performs login processing from a server (also called a backend) or a client. The implementation principle of login processing from the server is as follows: the server configures an interceptor, intercepts all page requests, and determines whether there is a login ID in the page request. If not, it automatically jumps to the login page; if so, continues to complete the page request. The implementation principle of the login processing from the client is: the client determines whether there is a cookie in the page opened for the first time, if it exists, it will not be processed; if it does not exist, it will jump to the login page.

In the process of realizing the present invention, the inventor found that there are at least the following problems in the prior art:

(1) The method of logging in from the server is only suitable for server-side rendering or when the client and server are not separated. In the environment where the client and server are separated, this method is due to the obstruction of client services. Or the reason of client-side ajax will make it impossible to jump to the login page.

(2) In the method of login processing from the client, it is necessary to determine whether there is a cookie in the page before proceeding with the next request, which is easy to cause the cookie to be forged, and the cookie parsing rules are easily exposed, and the security is low; in addition, the login configuration of this method is The flexibility is poor. In the test environment and offline environment, the login configuration needs to be modified frequently. If the modification is wrong, the online failure will be caused.

SUMMARY OF THE INVENTION

In view of this, an embodiment of the present invention provides a login method and device. After the client intercepts the request message and the corresponding response message, based on the set login judgment rule and the response message, when it is determined that the user is not logged in, it obtains from the response message. Login address information, and then complete the login. The embodiment of the present invention implements a flexible login method, and the client only needs to perform login interception, and does not need to care which address is used to log in.

To achieve the above object, according to an aspect of the embodiments of the present invention, a login method is provided.

A login method according to an embodiment of the present invention includes: intercepting a request message and a response message corresponding to the request message; judging whether a user is logged in according to a predefined login judgment rule and a status code in the response message; Wherein, the login judgment rule is set with a status code and the meaning represented by the status code; in the case that the user is not logged in, the login address information is obtained from the response message, so as to perform a processing based on the login address information. Log in.

Optionally, the method further includes: encapsulating the request message into a common request class; respectively defining a method corresponding to the server interface, and converting the address of the server interface according to the request type of the server interface. Information is encapsulated into the method; the encapsulation result is passed to the public request class, and the method name of the method is output.

Optionally, the encapsulating the request message into a common request class includes: creating an instance object, and outputting the instance object; intercepting the request message with a request interceptor, and adding a public header to the request message information; use a response interceptor to intercept the response message corresponding to the request message, and process the response message.

Optionally, the logging in based on the login address information includes: splicing the login address information and the current address information corresponding to the request information, and performing jump login according to the spliced address information.

Optionally, the obtaining the login address information from the response message includes: obtaining the login address information from header information of the response message; wherein the header information includes the information provided by the server Login address information.

To achieve the above object, according to another aspect of the embodiments of the present invention, a login apparatus is provided.

A login device according to an embodiment of the present invention includes: an interception module for intercepting a request message and a response message corresponding to the request message; a judgment module for judging rules according to a predefined login and the response message The status code in the log is used to judge whether the user is logged in; wherein, the log-in judgment rule is set with the status code and the meaning represented by the status code; the log-in module is used to log in from the response when the user is not logged in. The login address information is obtained from the message, so as to log in based on the login address information.

Optionally, the device further includes: an encapsulation module, configured to encapsulate the request message into a common request class; respectively define methods corresponding to the server interface, and according to the request type of the server interface, The address information of the server interface is encapsulated into the method; and the encapsulation result is passed to the public request class, and the method name of the method is output.

Optionally, the encapsulation module is further configured to: create an instance object and output the instance object; use a request interceptor to intercept the request message, and add common header information to the request message; use a response interceptor The response message corresponding to the request message is intercepted, and the response message is processed.

Optionally, the login module is further configured to: splicing the login address information and the current address information corresponding to the request information, and performing jump login according to the spliced address information.

Optionally, the judging module is further configured to: obtain login address information from header information of the response message; wherein the header information includes the login address information provided by the server.

To achieve the above object, according to yet another aspect of the embodiments of the present invention, an electronic device is provided.

An electronic device according to an embodiment of the present invention includes: one or more processors; and a storage device configured to store one or more programs, when the one or more programs are executed by the one or more processors, The one or more processors are caused to implement a login method according to an embodiment of the present invention.

To achieve the above object, according to yet another aspect of the embodiments of the present invention, a computer-readable medium is provided.

A computer-readable medium of an embodiment of the present invention stores a computer program thereon, and when the program is executed by a processor, implements a login method of the embodiment of the present invention.

One embodiment of the above invention has the following advantages or beneficial effects: after the client intercepts the request message and the corresponding response message, when it is determined that the user is not logged in based on the set login judgment rule and the response message, the login address information is obtained from the response message. , and then complete the login, realizing a flexible login method. The client only needs to perform login interception, and does not need to care which address is used to log in; through the unified login judgment rule, combined with the status code, the login judgment is performed without judging whether the cookie exists, preventing It solves problems such as cookie forgery, and further improves the flexibility of the client; through the secondary encapsulation method, the request message is uniformly encapsulated into a common request class, and the server interface is uniformly encapsulated into a client API, which realizes the request message and response message. The unified processing reduces the workload of repetitive code and easily realizes login interception.

Further effects of the above non-conventional alternatives will be described below in conjunction with specific embodiments.

Description of drawings

The accompanying drawings are used for better understanding of the present invention and do not constitute an improper limitation of the present invention. in:

1 is a schematic diagram of the main steps of a login method according to an embodiment of the present invention;

2 is a schematic diagram of the main principle of a login method according to an embodiment of the present invention;

3 is a schematic flow chart of a login method according to an embodiment of the present invention;

FIG. 4 is a schematic diagram of main modules of a login device according to an embodiment of the present invention;

5 is an exemplary system architecture diagram to which an embodiment of the present invention may be applied;

FIG. 6 is a schematic structural diagram of a computer apparatus suitable for implementing the electronic device according to the embodiment of the present invention.

Detailed ways

Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, which include various details of the embodiments of the present invention to facilitate understanding and should be considered as exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted from the following description for clarity and conciseness.

The terms involved in the embodiments of the present invention are explained below.

Front-end: A web page or interface that directly interacts with users, which is a type of client.

Client: A party that can initiate a request to the server, such as an APP (Application).

Backend or server: A party that can respond to client requests, such as a cloud server.

Vue: is a progressive framework for building user interfaces. Unlike other large frameworks, Vue is designed to be applied layer by layer from the bottom up.

React: is a JavaScript library launched by Facebook for building user interfaces.

JavaScript: is a literal scripting language, abbreviated JS, is a dynamically typed, weakly typed, prototype-based language with built-in support for types.

Cookie: refers to the data stored on the user's local terminal by some websites in order to identify the user's identity and track the session.

Ajax: Asynchronous Javascript And XML (Asynchronous JavaScript and XML), refers to a web development technology for creating interactive web applications.

XML: Extensible Markup Language (Extensible Markup Language), is a markup language used to mark electronic documents to make them structured.

axios: is a promise-based http client that can be used in browsers and node.js (which is a Javascript runtime environment), and can complete ajax asynchronous requests.

url: Uniform Resource Locator (Uniform Resource Locator), is the address of standard resources on the Internet.

FIG. 1 is a schematic diagram of main steps of a login method according to an embodiment of the present invention. As shown in FIG. 1, the login method of the embodiment of the present invention mainly includes the following steps:

Step S101: Intercept the request message and the response message corresponding to the request message. The request message is encapsulated into a common request class in advance, specifically: creating an instance object in the common request class; using a request interceptor to intercept at least one request message sent by the client, and processing the request message uniformly; using a response interceptor to intercept the service The response message corresponding to the request message returned by the terminal, and the response message is processed uniformly. Subsequent clients can intercept the request message by calling the request interceptor, and intercept the response message by using the response interceptor.

Step S102: According to the predefined login determination rule and the status code in the response message, determine whether the user is logged in. The client and the server have unified login judgment rules. The rules are set with status codes and the meanings corresponding to each status code. For example, the status code 401 is defined, which means that the user is not logged in. When the user is not logged in, the server adds the login address information to the header information of the response message; after the client intercepts the response message, it can determine whether the user is logged in according to the login judgment rules and the status code in the response message. .

Step S103: in the case that the user is not logged in, obtain login address information from the response message, so as to log in based on the login address information. Encapsulate the interface requested by the server in advance, specifically: define the methods corresponding to the server interface respectively, encapsulate the address information of the server interface into the method according to the request type of the server interface; pass the encapsulation result to the public Request class, the method name of the output method. Subsequently, if the client determines that the user is not logged in and has obtained the login address information, the client can call the corresponding method through the method name to splicing the login address information and the address information of the address bar currently accessed by the user, and then follow the splicing method. The following address information is used for jump login.

FIG. 2 is a schematic diagram of the main principle of a login method according to an embodiment of the present invention. As shown in FIG. 2 , in order to achieve the purpose of the present invention, the client (the front end in the embodiment) performs multi-layer processing, including a page view layer, a common processing layer, and an application program interface layer.

The page view layer contains all request messages. This layer is used to send page request messages and perform page rendering.

The public processing layer includes a custom request request, which is requestJS in the embodiment. This layer is used to intercept the request message by using a request interceptor, summarize and uniformly process all the request messages of the page, and output it to the application program interface layer; use the response The interceptor intercepts the response messages from the API layer, and aggregates and processes all the response messages uniformly. In the embodiment, the method of secondary encapsulation is adopted to realize unified processing of all messages.

The application interface layer is used to encapsulate all server-side interfaces and expose a method name to the page view layer. The advantage of this is that all interfaces on the server can be managed in a unified manner. If the url of the server interface changes, you only need to change the file attributes corresponding to this layer, instead of changing the request message of the page in a large area, reducing the number of clients. Duplicate requests and duplicate codes. The application program interface layer is also used to send the request message to the server that currently has an http connection with the client through the corresponding interface after receiving the request message; after the interface receives the response message from the server to the request message , which is sent to the response interceptor.

FIG. 3 is a schematic flowchart of a main flow of a login method according to an embodiment of the present invention. As shown in FIG. 3 , the login method according to the embodiment of the present invention mainly includes the following steps:

Step S301: The common processing layer encapsulates all request messages for server-side data from the target page into a common request class. In the embodiment, taking the single page of the Vue project as an example, all the information exchanges between the client and the server are axios request messages. The specific implementation of encapsulating the axios request message into a common request class (requestJS) is as follows: (1) Create an axios instance object, the name of the instance object is axiosService, and then export (export) the instance object; (2) use the interceptors.request.use method (ie request interceptor) to intercept all axios request messages, and intercept the intercepted axios requests The message is processed; the processing here can be to add public header information, such as token (token), timestamp, etc.; (3) use the interceptors.response.use method (ie, the response interceptor) to intercept the and return from the server. The response message corresponding to the axios request message is processed uniformly.

In the embodiment, the unified processing of the response message mainly includes:

(1) Store the value corresponding to the applicationprofile attribute data in the header information (headers) of the response message in the client cache.

(2) Special processing is performed on the data whose content-type (content type) value in the headers of the response message is application/properties, that is, directly returned to the page calling program, where a promise object is returned.

(3) For other data: judge whether the status code (code) is equal to 200, if it is equal to 200, return the data value in the data to the page calling program; if it is not equal to 200, return the message in the data to the page calling program , which returns a promise object.

(4) Handling of wrong data: If the code is equal to 401, try to obtain the jump path in the location field in the header (the path is the login address information, and the login address information can be the url of the login page or login window). Make a jump; if the code is equal to 404, jump to the error page.

Step S302: The application program interface layer respectively defines a method corresponding to at least one server interface, and encapsulates the address information of the server interface into the method according to the request type of the server interface. Here is just to define a standard for the input and output of an interface. In the embodiment, for the interface input standard, you can only care about the name of the method to be called, and do not need to care about the specific url of the request. If the url of the server interface is changed, you only need to change the url inside the method, and you do not need to change each url. The axios request message of the page greatly reduces the amount of code duplication. The standard for interface input can be to output a promise object uniformly.

The following is an example of how to define the method corresponding to the server interface:

For example, the server interface is: v1/application/appId

The interface encapsulated by the client is:

export function getApp(appId){

return request({

url:baseUrl+'v1/application/'+appId,

method:'get'

})

}

For another example, the server interface is: v1/applications/search

The interface encapsulated by the client is:

export function searchApps(params){

let url=baseUrl+'v1/applications/search? '

for(let key in params){

url+=key+"="+params[key]+"&"

}

url=url.substring(0,url.length-1);

return request({

url: url,

method:'get'

})

}

The following is an example of how to encapsulate the address information of the server interface into the method according to the request type of the server interface:

For example, for a get type request, the corresponding url is spliced, and the incoming parameters are spliced after the url. Assuming that the incoming parameters are objects {a:1, b:2}, the incoming parameters will be combined with the url of the server and processed into the following format during encapsulation: http://xxx.jd.com/v1/xx/ get? a=1&b=2.

For another example, for post, delete, and put type requests, the incoming parameters are placed in the data (data), so it is only necessary to splicing the corresponding url, and no special processing is performed for the incoming parameters. For example, delete: http://xxx.jd.com/v1/xx/delete/:id, where id is the incoming parameter.

Step S303: The application program interface layer transfers the encapsulation result to the public request class, and outputs the method name of the method. The application interface layer only exposes one method name for the Vue page, such as getApp and searchApps. When the Vue page is called, you only need to pass in the parameters as required to output the promise object. In the embodiment, the application program interface layer passes the processed url, parameters, and other header information that needs to be processed to requestJS, and outputs (export) these method names, so as to provide these method names to the page view layer, so that the page The view layer can call these methods directly.

Step S304: The page view layer invokes the method name of the application program interface layer to intercept all request messages from the target page through the common processing layer, and the response messages corresponding to the request messages returned by the server. After receiving the request message sent by the client, the server will return the corresponding response message. The public processing layer intercepts all request messages from the target page through the request interceptor, and intercepts the response message corresponding to the request message returned by the server through the response interceptor. In the embodiment, after intercepting the request message, the public processing layer obtains a response message matching the request message based on the pre-established http connection.

Step S305: The public processing layer judges whether the user has logged in to the target page according to the predefined login judgment rule and the status code in the response message. If the user has logged in to the target page, step S306 is executed; Then step S307 is executed. Since the page is rendered by Vue, rather than the server-side rendering, when judging whether the user logs in to the target page, a cookie method is used in the prior art, but this method is prone to malicious cookie forgery attacks. In this embodiment, whether the user logs in to the target page is judged by means of the cooperation between the client and the server, that is, through a unified login judgment rule. The rule specifies a corresponding status code indicating that the user does not log in to the target page. If the user does not log in to the target page, the server will return the specific status code and the url of the corresponding login page or login window, and the client does not need to care which page the user goes to log in. For example, the client and server pre-specify that when the status code is 401, it means that the user is not logged in. At this time, the header information of the response message must contain the location field, which is used to store the url of the login page or login window ( It is defined and stored by the server so that different environments and systems can be changed at any time); when the status code is other values, it means other meanings accordingly.

Step S306: The page view layer performs page rendering on the target page to display page content.

Step S307: The public processing layer obtains the login address information from the response message, and splices the login address information and the address information of the target page to jump to the login page or login window according to the spliced address information. If the status code is 401, it means that the user has not logged in to the target page, and the client needs to jump to the login page or login window. Since the server has three systems of testing, development, and online, the login page or the URL of the login window of each system is different, so the client needs to obtain it from the header given by the server, which can greatly improve the flexibility of the client. In the embodiment, the public processing layer obtains the url of the login page or the login window from the location field included in the header of the response message. The address information of the target page is the url of the address bar of the page currently accessed by the user. In an embodiment, the process of splicing two address information may be: const returnUrl=errorresponse.headers.location+"?ReturnUrl="+nowUrl; wherein, the information in the location field is the url of the login page, such as: http:// xxx.jd.com; nowUrl is the url of the address bar of the page currently accessed by the user obtained through JS, for example: http://abc.jd.com; then the url obtained after splicing is: http://xxx. jd.com? ReturnUrl=http://abc.jd.com. After that, according to the spliced address, using the location.href method of the client, the jump from the target page currently accessed by the user to the login page or login window can be completed.

It can be seen from the login method of the embodiment of the present invention that, after intercepting the request message and the corresponding response message, the client obtains the login address information from the response message when it determines that the user is not logged in based on the set login judgment rule and the response message, and then obtains the login address information from the response message. After completing the login, a flexible login method is realized. The client only needs to intercept the login, and does not need to care which address is used to log in. Through the unified login judgment rules, combined with the status code, the login judgment is performed, and there is no need to judge whether the cookie exists, which prevents the cookie. Forgery and other problems further improve the flexibility of the client; through the method of secondary encapsulation, the request message is uniformly encapsulated into a common request class, and the server interface is uniformly encapsulated into a client API, which realizes the unification of request messages and response messages. processing, reducing the workload of repetitive code, and easily implement login interception.

FIG. 4 is a schematic diagram of main modules of a login device according to an embodiment of the present invention. As shown in FIG. 4 , the login apparatus 400 according to the embodiment of the present invention mainly includes:

The interception module 401 is configured to intercept the request message and the response message corresponding to the request message. The request message is encapsulated into a common request class in advance, specifically: creating an instance object in the common request class; using a request interceptor to intercept at least one request message sent by the client, and processing the request message uniformly; using a response interceptor to intercept the service The response message corresponding to the request message returned by the terminal, and the response message is processed uniformly. Subsequent clients can intercept the request message by calling the request interceptor, and intercept the response message by using the response interceptor.

The judging module 402 is used for judging whether the user is logged in according to the predefined login judging rule and the status code in the response message. The client and the server have unified login judgment rules. The rules are set with status codes and the meanings corresponding to each status code. For example, the status code 401 is defined, which means that the user is not logged in. When the user is not logged in, the server adds the login address information to the header information of the response message; after the client intercepts the response message, it can determine whether the user is logged in according to the login judgment rules and the status code in the response message. .

The login module 403 is configured to acquire login address information from the response message when the user is not logged in, so as to log in based on the login address information. Encapsulate the interface requested by the server in advance, specifically: define the methods corresponding to the server interface respectively, encapsulate the address information of the server interface into the method according to the request type of the server interface; pass the encapsulation result to the public Request class, the method name of the output method. Subsequently, if the client determines that the user is not logged in and has obtained the login address information, the client can call the corresponding method through the method name to splicing the login address information and the address information of the address bar currently accessed by the user, and then follow the splicing method. The following address information is used for jump login.

In addition, the login apparatus 400 in this embodiment of the present invention may further include: an encapsulation module (not shown in FIG. 4 ), which is used to encapsulate the request message into a common request class; respectively define methods corresponding to the server interface , according to the request type of the server interface, encapsulate the address information of the server interface into the method; and pass the encapsulation result to the public request class, and output the method name of the method.

As can be seen from the above description, after the client intercepts the request message and the corresponding response message, and determines that the user is not logged in based on the set login judgment rules and response message, it obtains the login address information from the response message, and then completes the login. A flexible login method, the client only needs to perform login interception, and does not need to care which address is used to log in; through unified login judgment rules, combined with the status code for login judgment, there is no need to judge whether a cookie exists, preventing cookie forgery and other problems, and further Improve the flexibility of the client; through the secondary encapsulation method, the request message is uniformly encapsulated into a common request class, and the server interface is uniformly encapsulated into a client API, which realizes the unified processing of request messages and response messages, and reduces duplication. Code workload, easy to achieve login interception.

FIG. 5 shows an exemplary system architecture 500 to which a login method or a login apparatus of an embodiment of the present invention may be applied.

As shown in FIG. 5 , the system architecture 500 may include terminal devices 501 , 502 , and 503 , a network 504 and a server 505 . The network 504 is a medium used to provide a communication link between the terminal devices 501 , 502 , 503 and the server 505 . Network 504 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

The user can use the terminal devices 501, 502, 503 to interact with the server 505 through the network 504 to receive or send messages and the like. Various communication client applications may be installed on the terminal devices 501 , 502 and 503 , such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, and the like.

The terminal devices 501, 502, 503 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.

The server 505 may be a server that provides various services, for example, a background management server that provides responses to the request messages sent by the terminal devices 501 , 502 , and 503 to the user. The background management server can analyze and process the received request information, and feed back the processing result (for example, response information) to the terminal device.

It should be noted that the login methods provided in the embodiments of the present application are generally executed by the front ends on the terminal devices 501 , 502 , and 503 .

It should be understood that the numbers of terminal devices, networks and servers in FIG. 5 are only illustrative. There can be any number of terminal devices, networks and servers according to implementation needs.

According to an embodiment of the present invention, the present invention further provides an electronic device and a computer-readable medium.

The electronic device of the present invention comprises: one or more processors; storage means for storing one or more programs, when the one or more programs are executed by the one or more processors, so that the one or more programs A plurality of processors implement a login method according to an embodiment of the present invention.

The computer-readable medium of the present invention stores a computer program thereon, and when the program is executed by a processor, a login method according to an embodiment of the present invention is implemented.

Referring to FIG. 6 below, it shows a schematic structural diagram of a computer system 600 suitable for implementing an electronic device according to an embodiment of the present invention. The electronic device shown in FIG. 6 is only an example, and should not impose any limitation on the function and scope of use of the embodiments of the present invention.

As shown in FIG. 6, a computer system 600 includes a central processing unit (CPU) 601, which can be loaded into a random access memory (RAM) 603 according to a program stored in a read only memory (ROM) 602 or a program from a storage section 608 Instead, various appropriate actions and processes are performed. In the RAM 603, various programs and data necessary for the operation of the computer system 600 are also stored. The CPU 601 , the ROM 602 , and the RAM 603 are connected to each other through a bus 604 . An input/output (I/O) interface 605 is also connected to bus 604 .

The following components are connected to the I/O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc. ; and a communication section 609 including a network interface card such as a LAN card, a modem, and the like. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I/O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is mounted on the drive 610 as needed so that a computer program read therefrom is installed into the storage section 608 as needed.

In particular, according to the disclosed embodiments of the present invention, the processes described in the main step diagrams above may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods illustrated in the main step diagrams. In such an embodiment, the computer program may be downloaded and installed from the network via the communication portion 609 and/or installed from the removable medium 611 . When the computer program is executed by the central processing unit (CPU) 601, the above-described functions defined in the system of the present invention are performed.

It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the above two. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device, or a combination of any of the above. More specific examples of computer readable storage media may include, but are not limited to, electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read only memory (ROM), erasable Programmable read only memory (EPROM or flash memory), fiber optics, portable compact disk read only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the present invention, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, however, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code therein. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device . Program code embodied on a computer readable medium may be transmitted using any suitable medium including, but not limited to, wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code that contains one or more logical functions for implementing the specified functions executable instructions. It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It is also noted that each block of the block diagrams or flowchart illustrations, and combinations of blocks in the block diagrams or flowchart illustrations, can be implemented in special purpose hardware-based systems that perform the specified functions or operations, or can be implemented using A combination of dedicated hardware and computer instructions is implemented.

The modules involved in the embodiments of the present invention may be implemented in a software manner, and may also be implemented in a hardware manner. The described module can also be set in the processor, for example, it can be described as: a processor includes an interception module, a judgment module and a login module. Wherein, the names of these modules do not constitute a limitation of the module itself under certain circumstances. For example, an interception module can also be described as "a module that intercepts request messages and response messages corresponding to the request messages".

As another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or may exist alone without being assembled into the device. The above-mentioned computer-readable medium carries one or more programs, and when the above-mentioned one or more programs are executed by a device, the device includes: intercepting a request message and a response message corresponding to the request message; according to a predefined and the status code in the response message to determine whether the user is logged in; wherein, the login judgment rule is set with the status code and the meaning represented by the status code; in the case that the user is not logged in , and obtain login address information from the response message to log in based on the login address information.

As can be seen from the above description, after the client intercepts the request message and the corresponding response message, and determines that the user is not logged in based on the set login judgment rules and response message, it obtains the login address information from the response message, and then completes the login. A flexible login method, the client only needs to perform login interception, and does not need to care which address is used to log in; through unified login judgment rules, combined with the status code for login judgment, there is no need to judge whether a cookie exists, preventing cookie forgery and other problems, and further Improved client flexibility.

The above product can execute the method provided by the embodiment of the present invention, and has corresponding functional modules and beneficial effects for executing the method. For technical details not described in detail in this embodiment, reference may be made to the method provided by the embodiment of the present invention.

The above-mentioned specific embodiments do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent replacements and improvements made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims (12)

1. A login method, comprising:

intercepting a request message and a response message corresponding to the request message;

judging whether the user logs in or not according to a predefined login judgment rule and the state code in the response message; wherein, the login judgment rule is provided with a state code and a meaning represented by the state code;

and under the condition that the user does not log in, acquiring login address information from the response message so as to log in based on the login address information.

2. The method of claim 1, further comprising:

packaging the request message into a public request class;

respectively defining methods corresponding to the server interfaces, and encapsulating address information of the server interfaces into the methods according to the request types of the server interfaces;

and transmitting the encapsulation result to the public request class, and outputting the method name of the method.

3. The method of claim 2, wherein encapsulating the request message into a common request class comprises:

creating an instance object and outputting the instance object;

intercepting the request message by using a request interceptor, and adding common header information in the request message;

and intercepting a response message corresponding to the request message by using a response interceptor, and processing the response message.

4. The method of claim 1, wherein said logging in based on said login address information comprises:

and splicing the login address information and the current address information corresponding to the request information, and performing skip login according to the spliced address information.

5. The method of claim 1, wherein the obtaining login address information from the response message comprises: acquiring login address information from the header information of the response message; wherein, the header information includes the login address information provided by the server.

6. A login apparatus, comprising:

the device comprises an interception module, a processing module and a processing module, wherein the interception module is used for intercepting a request message and a response message corresponding to the request message;

the judging module is used for judging whether the user logs in or not according to a predefined login judging rule and the state code in the response message; wherein, the login judgment rule is provided with a state code and a meaning represented by the state code;

and the login module is used for acquiring login address information from the response message under the condition that the user does not log in, so as to log in based on the login address information.

7. The apparatus of claim 6, further comprising: a package module for

Packaging the request message into a public request class;

respectively defining methods corresponding to the server interfaces, and encapsulating address information of the server interfaces into the methods according to the request types of the server interfaces; and

and transmitting the encapsulation result to the public request class, and outputting the method name of the method.

8. The apparatus of claim 7, wherein the encapsulation module is further configured to:

creating an instance object and outputting the instance object;

intercepting the request message by using a request interceptor, and adding common header information in the request message;

and intercepting a response message corresponding to the request message by using a response interceptor, and processing the response message.

9. The apparatus of claim 6, wherein the login module is further configured to: and splicing the login address information and the current address information corresponding to the request information, and performing skip login according to the spliced address information.

10. The apparatus of claim 6, wherein the determining module is further configured to: acquiring login address information from the header information of the response message; wherein, the header information includes the login address information provided by the server.

11. An electronic device, comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-5.

12. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-5.

Images