CN112100536A - A web page access method, apparatus, device and readable storage medium - Google Patents

Abstract

The present application discloses a web page access method, device, device and computer-readable storage medium. The method includes: if it is detected that an interface invocation in a target web page fails, recording a target url corresponding to the target web page; sending a message to a first server Login request; the web page corresponding to the first server and the target web page have different domain names; obtain the token sent by the first server, and use the token and the target url to send an access request to the second server corresponding to the target web page, so as to re-register the target web page access; this method records the target url corresponding to the target web page, so as to use the token and the target url to send an access request to the second server; since the target url is added to the access request and a new token is carried, it can The target web page can be accessed directly without the user's operation, which avoids cumbersome operations, shortens the web page access time, and improves the user experience.

Description

A web page access method, apparatus, device and readable storage medium

technical field

The present application relates to the field of network technologies, and in particular, to a web page access method, a web page access device, a web page access device, and a computer-readable storage medium.

Background technique

In practical applications, there are the following situations: there are two sets of web systems (hereinafter referred to as system A and system B), they are not under the same domain name, local cache and cookies cannot be shared, but they share the same user center, the same authority and user system, and only set the login interface in system A. The user needs a token (ie, token) to access the web page, and after the token expires, he needs to log in again to obtain a new token. In the related art, after re-login, it is possible to jump back to the web page in the same system before re-login (ie, any web page in system A), or jump to the home page of another system (ie, system B). However, if the web page the user is on before re-login is a non-home page in system B, the user needs to re-operate to enter the web page where he was before re-login, resulting in cumbersome operations, long time required for web page access, and poor user experience. Difference.

Therefore, the related art has the problems of complicated operation and poor user experience, which are technical problems to be solved by those skilled in the art.

SUMMARY OF THE INVENTION

In view of this, the purpose of the present application is to provide a web page access method, a web page access device, a web page access device and a computer-readable storage medium, which can directly access a target web page and avoid cumbersome operations.

In order to solve the above-mentioned technical problems, the present application provides a web page access method, including:

If it is detected that the interface invocation in the target web page fails, record the target url corresponding to the target web page;

Send a login request to the first server; the webpage corresponding to the first server and the target webpage have different domain names;

The token sent by the first server is acquired, and an access request is sent to the second server corresponding to the target webpage by using the token and the target url, so as to re-access the target webpage.

Optionally, the sending an access request to the second server corresponding to the target webpage by using the token and the target url includes:

Use the target url to generate an initial access request;

A token is added to the initial access request, the access request is obtained, and the access request is sent to the second server.

Optionally, the sending a login request to the first server includes:

Obtain user name information and password information;

generating the login request using the username information and the password information;

Send the login request to the first server, so that the first server verifies the user name information and the password information, and uses the token to verify the login request after the verification is passed. respond.

Optionally, after obtaining the token sent by the first server, the method further includes:

Flush the local cache and store the token in the local cache.

Optionally, the recording of the target url corresponding to the target web page includes:

The target url is recorded using the referrer attribute.

Optionally, after the obtaining the token sent by the first server, before the sending an access request to the second server corresponding to the target webpage by using the token and the target url, the method further includes:

Determine whether there is a jump url;

If the jump url does not exist, send a default access request to the first server or the second server;

If there is the jump url, then determine whether the jump url is the target url;

If the jump url is not the target url, send the access request to the first server by using the jump url and the token;

If the jump url is the target url, the step of sending an access request to the second server corresponding to the target webpage by using the token and the target url is performed.

Optionally, the detection process of the interface invocation failure includes:

sending an interface invocation request corresponding to the target interface on the target webpage to the second server;

Determine whether the response content of the second server is an error code;

If the response content is the error code, it is determined that a failure to call the target interface in the target webpage is detected.

The application also provides a web page access device, including:

a recording module, configured to record the target url corresponding to the target webpage if it is detected that the interface invocation in the target webpage fails;

a login module, configured to send a login request to a first server; the webpage corresponding to the first server and the target webpage have different domain names;

an access module, configured to obtain the token sent by the first server, and use the token and the target url to send an access request to the second server corresponding to the target web page, so as to re-access the target web page .

The present application also provides a web page access device, including a memory and a processor, wherein:

the memory for storing computer programs;

The processor is configured to execute the computer program to implement the above-mentioned web page access method.

The present application also provides a computer-readable storage medium for storing a computer program, wherein when the computer program is executed by a processor, the above-mentioned web page access method is implemented.

In the web page access method provided by the present application, if it is detected that the interface call in the target web page fails, the target url corresponding to the target web page is recorded; a login request is sent to the first server; the web page corresponding to the first server and the target web page have different domain names ; Obtain the token sent by the first server, and use the token and the target url to send an access request to the second server corresponding to the target web page, so as to re-access the target web page.

It can be seen that when the method detects that the interface call in the target web page fails, it indicates that the token is invalid and needs to log in again. The web page corresponding to the first server and the target web page have different domain names, indicating that the target web page belongs to a system that does not have a web page with a login interface. The target url corresponding to the target webpage is recorded, so that the target webpage can be accessed directly in the future. When logging in again, a login request is sent to the first server, and after obtaining the token sent by the first server, an access request is sent to the second server by using the token and the target url. The access request carries a new token, so the web page on the second server can be accessed, and the target url is added to the access request, so the target web page can be accessed directly without the user's operation, which avoids cumbersome operations. Shorter access times improve user experience.

In addition, the present application also provides a web page access device, a web page access device and a computer-readable storage medium, which also have the above beneficial effects.

Description of drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the accompanying drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only It is an embodiment of the present application. For those of ordinary skill in the art, other drawings can also be obtained according to the provided drawings without any creative effort.

1 is a flowchart of a method for accessing a webpage provided by an embodiment of the present application;

2 is a schematic diagram of a data flow provided by an embodiment of the present application;

3 is a schematic diagram of a login process provided by an embodiment of the present application;

FIG. 4 is a flowchart of another web page access method provided by an embodiment of the present application;

FIG. 5 is a schematic structural diagram of a webpage access device provided by an embodiment of the present application;

FIG. 6 is a schematic structural diagram of a device for accessing a webpage according to an embodiment of the present application.

Detailed ways

In order to make the purposes, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments It is only a part of the embodiments of the present application, but not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

Please refer to FIG. 1 , which is a flowchart of a method for accessing a webpage according to an embodiment of the present application. The method includes:

S101: If it is detected that the interface call in the target web page fails, record the target url corresponding to the target web page.

It should be noted that, some or all of the steps in the embodiments of the present application may be performed by using a web page access device. The webpage access device may specifically be a terminal such as a computer and a smart phone, and the specific form of the webpage access device is not limited in this embodiment. In this embodiment, the target web page is the web page currently being accessed. It should be noted that it is also a non-home page corresponding to a web page system that does not have a login page. In this embodiment, the A system is used to represent a web page system with a login page, and the B system is used to represent a web page system without a login page. It can be understood that the target webpage is any webpage in the B system that is not the homepage. Since a corresponding token (ie, token) is required when accessing any webpage, the token has a time-limited lifespan. If the target web page is accessed for too long, that is, if the target web page stays for too long, the token will expire. Interface call failed. This embodiment does not limit the specific content and form of the interface, for example, it can be a download interface, and the form can be text or image. This embodiment does not limit the specific manner of detecting the failure of the interface invocation. For example, it can be determined whether the server responds, or it can be determined whether the server has made a correct response.

If it is detected that the interface call fails, the token is invalid, and you need to log in again to obtain a new token. In order to directly access the webpage after logging in and obtaining the new token, in this embodiment, the target url corresponding to the target webpage needs to be recorded. URL is the Uniform Resource Locator (Uniform Resource Locator), also known as the web page address, which is the standard resource address (Address) on the Internet. By recording the target url, you can use the target url to directly access the target web page after logging in. This embodiment does not limit the specific manner of recording the target url, for example, a new special variable can be used to record the target url, or an existing variable can be used to record the target url.

In a possible implementation manner, in order to accurately detect whether an interface invocation failure occurs, the detection process of the interface invocation failure may include:

Step 11: Send an interface invocation request corresponding to the target interface on the target webpage to the second server.

Step 12: Determine whether the response content of the second server is an error code.

Step 13: If the response content is an error code, it is determined that it is detected that the invocation of the target interface in the target web page fails.

The target interface can be any interface on the target web page, and the interface call request corresponds to the target interface, and its specific content and form are not limited. By sending an interface invocation request for invoking the target interface to the second server, the second server can be made to respond to the interface invocation request, that is, the response content sent by the second server can be obtained. By judging whether the response content is an error code, it can be determined whether the invocation is successful. If the response content is an error code, such as a 401 status code, it means that the invocation of the target interface fails, so it can be determined that the interface invocation failure is detected. By using the interface invocation failure detection method, it is possible to avoid being mistakenly identified as the interface invocation failure due to the timeout of the response of the second server, thereby improving the detection accuracy of the interface invocation failure.

In one embodiment, the target url can be recorded using the referrer attribute. The referrer attribute is the document.reffer field, which can record and return the url that loads the current file. Therefore, the document.reffer field can be used to record the target url, and there is no need to add a special field to record the target url.

S102: Send a login request to the first server.

It should be noted that the webpage corresponding to the first server and the target webpage have different domain names. Since system A and system B correspond to different domain names, when the target webpage is a non-homepage webpage in system B, the first server is the server corresponding to system A. Only system A includes a login page for login, so after the token expires, a login request needs to be sent to the first server in order to log in again. The specific content and form of the login request are not limited, and it may include necessary information required for login such as user name and password, or may also include information such as verification code. The information may be input by the user, or the pre-stored information may be read from the pre-stored location, thereby generating a login request.

Specifically, step S102 may include:

Step 21: Obtain user name information and password information.

Step 22: Generate a login request using the user name information and the password information.

Step 23: Send the login request to the first server, so that the first server verifies the user name information and the password information, and uses the token to respond to the login request after the verification is passed.

In this embodiment, in order to reduce the length of the login request, only user name information and password information may be acquired, and a login request may be generated by using them. After getting the login request, send it to the first server. The first server parses the login request after obtaining it, and verifies the user name information and password information obtained by the analysis. The specific verification process is not limited. For example, the user name information can be used to search in the database to obtain the corresponding password, and match the password with the password information to determine whether the two are the same. If the two are the same, it can be determined that the verification is passed, and if they are different, it is determined that there is no verification. After the verification is passed, the first server can use the new token to respond to the login request, that is, send the token to the webpage access device.

S103: Obtain the token sent by the first server, and send an access request to the second server corresponding to the target webpage by using the token and the target url, so as to re-access the target webpage.

After obtaining the token sent by the first server, the token and the target url can be used to generate an access request, and the access request is sent to the second server. This embodiment does not limit the specific generation method of the access request. The second server corresponds to the target web page, and after the access request includes the target url and a valid token, the second server may allow the web page access device to directly access the target web page. Specifically, the second server may extract the token and detect the token. After determining that the token is valid, access to the target web page can be allowed. The specific method of extracting the token is not limited. In one embodiment, the logic code required for extracting the token can be written for each webpage in the second server; if there are too many webpages, the corresponding code is written for each webpage. The logic code is too cumbersome, so in another implementation, the token can be extracted using the navigation guard. The specific form of the navigation guard is not limited. For example, for the vue framework (a front-end framework), the navigation guard is vue-router. Specifically, in router.beforeEach, the to.query attribute can be used to determine whether the request exists. token, and get the token when it exists and store it. It should be noted that, in one embodiment, the first server and the second server are different servers; in another embodiment, the first server and the second server may be the same server, which is running system A . The first server is the first server when executing the service corresponding to the A system, and the second server is the second server when the B system is running and the service corresponding to the B system is executed.

In one embodiment, the step of using the token and the target url to send an access request to the second server corresponding to the target webpage may include:

Step 31: Use the target url to generate an initial access request.

Step 32: Add a token to the initial access request, obtain the access request, and send the access request to the second server.

In this embodiment, when generating the access request, the target url is used to generate the initial access request first, and the specific manner of generating the initial access request is not limited. After the initial access request is obtained, a token can be added to the initial access request. Specifically, the axios.defaults.headers.Authorization function can be used to put the token into the request header of the initial access request to obtain the access request, and use the axios.defaults.headers.Authorization function. The access request is sent to the second server.

In a specific implementation manner, after acquiring the token sent by the first server, it can be stored locally. Specifically, after acquiring the token sent by the first server, it may further include:

Step 41: Clear the local cache and store the token in the local cache.

In this embodiment, before the token is stored, the local cache (ie, localstorage) can be cleared, so as to prevent the stored old token or other service cache from affecting the storage process, thereby causing bugs (vulnerabilities), and then causing new tokens Error saving. So the token can be stored in the local cache after clearing the local cache.

Based on the foregoing embodiments, this embodiment does not limit the execution order of the foregoing steps. Therefore, step S103 may be directly executed, that is, the token sent by the first server may be obtained. At this time, the following situation may occur: In practical applications, it may not be necessary to jump to the webpage of system B when accessing the webpage after obtaining the token. . The user may stay on a webpage in system A for too long, causing the token to fail, or log in to system A for the first time. In this case, the token sent by the first server is also received. At this time, using the target url to access the webpage may access the wrong webpage, that is, the webpage that the user wants to visit. In view of the above problem, after obtaining the token sent by the first server, before using the token and the target url to send an access request to the second server corresponding to the target web page, the method may further include:

Step 51: Determine whether there is a redirect url.

Step 52: If there is no redirect url, send a default access request to the first server or the second server.

Step 53: If there is a jumping url, it is judged whether the jumping url is the target url.

Step 54: If the jump url is not the target url, send an access request to the first server by using the jump url and the token.

Step 55: If the jump url is the target url, the step of sending an access request to the second server corresponding to the target webpage by using the token and the target url is performed.

In this embodiment, the jump url is the url of the webpage accessed by the user before obtaining the token, which may be the url corresponding to any webpage in the A system, or the url corresponding to any webpage in the B system. If there is a jump url, it means that the webpage corresponding to the jump url is being accessed when the token is invalid, so you need to access the webpage corresponding to the jump url when logging in. If there is no jump url, it indicates the first visit, so a default visit request can be sent to the first server or the second server, and the default visit request is used to log in to the home page of the web page system. Send a default access request to the first server to access the home page of system A, and send a default access request to the second server to access the home page of system B. The specific server to send a default access request can be set according to the actual situation. This embodiment This is not limited.

If there is a jump url, it is judged whether the jump url is the target url, that is, it is judged whether the previously visited webpage belongs to the A system. If the jump url is the target url, it means that the previously accessed web page belongs to the B system, so the step of using the token and the target url to send an access request to the second server corresponding to the target web page, that is, the step in S103 is performed. If the jump url is not the target url, it means that the previously accessed web page belongs to the A system, so the token and the jump url can be used to send an access request to the first server, so as to directly access the webpage corresponding to the jump url after logging in. This embodiment does not limit the specific method of judging whether the redirected url is the target url. For example, the host part of the redirected url can be intercepted to determine whether it is the domain name corresponding to the A system. If so, the redirected url is not the target url.

By applying the web page access method provided by the embodiment of the present application, when it is detected that the interface call in the target web page fails, it indicates that the token is invalid and needs to log in again. The web page corresponding to the first server and the target web page have different domain names, indicating that the target web page belongs to a system that does not have a web page with a login interface. The target url corresponding to the target webpage is recorded, so that the target webpage can be accessed directly in the future. When logging in again, a login request is sent to the first server, and after obtaining the token sent by the first server, an access request is sent to the second server by using the token and the target url. The access request carries a new token, so the web page on the second server can be accessed, and the target url is added to the access request, so the target web page can be accessed directly without the user's operation, which avoids cumbersome operations. Shorter access times improve user experience.

Based on the above embodiments, this embodiment describes a specific webpage access process. Please refer to FIG. 2 , which is a schematic diagram of a data flow according to an embodiment of the present application. In this embodiment, a client is used as a device for accessing a webpage, and the client may specifically be a terminal such as a smart phone or a computer. The client sends an interface invocation request to the second server, the second server returns an error code after finding that the token has expired, and the client sends a login request to the first server after receiving the error code. Specifically, please refer to FIG. 3 , which is a schematic diagram of a login process provided by an embodiment of the present application. The obtained username (user name information) and password (password information) are encrypted at the front end (ie the client) and sent to the first server, and decrypted and verified at the back end (ie the first server). If the verification fails, the login fails, and if the verification succeeds, a token (ie, token) is returned to the client. The front-end (ie, the client) obtains the token and caches it, and can subsequently call the token to send an interface call request. If the token is valid, the data fed back by the server can be obtained. If the token is invalid or incorrect, the error code 401 will be obtained.

Save the token returned by the backend (ie, the first server) in localStorage (ie, the local cache), and put the encrypted token into the request header through axios.defaults.headers.Authorization and send it with the interface. Whenever the token is invalid or maliciously modified, the interface returns 401, and this information is obtained through the interceptor. The page will jump back to the login page, and the token in the cache will be cleared, and the new token will be recorded after the user successfully logs in next time.

Please refer to FIG. 4 , which is a flowchart of another method for accessing a webpage according to an embodiment of the present application. When getting the 401 error code, you can remember the current url and use the oldurl string to record. When jumping to the login page, the oldurl will be added to the url parameter, so that the oldurl can be used to directly access the target page after the login is successful. Specifically, taking the vue framework as an example, in system B, if the user stays on page X for too long, the token expires, and the interface fails to return to the login page of system A. After the login is successful, the document.reffer attribute confirms the need to jump Back to the X page of the B system, so the token field is obtained, and it is stored in the localstorage, and then the token is brought in the axios to initiate a request to the second server.

The web page access apparatus provided by the embodiments of the present application is introduced below, and the web page access apparatus described below and the web page access method described above may refer to each other correspondingly.

Please refer to FIG. 5. FIG. 5 is a schematic structural diagram of a webpage access device provided by an embodiment of the present application, including:

The recording module 110 is configured to record the target url corresponding to the target webpage if it is detected that the interface call in the target webpage fails;

The login module 120 is configured to send a login request to the first server; the webpage corresponding to the first server and the target webpage have different domain names;

The access module 130 is configured to acquire the token sent by the first server, and use the token and the target url to send an access request to the second server corresponding to the target web page, so as to re-access the target web page.

Optionally, access module 130 includes:

The initial access request generating unit is used to generate the initial access request by using the target url;

The access request sending unit is configured to add a token to the initial access request, obtain the access request, and send the access request to the second server.

Optionally, the login module 120 includes:

an information acquisition unit, used to acquire user name information and password information;

a login request generating unit, used for generating a login request by using the user name information and the password information;

The login request sending unit is configured to send the login request to the first server, so that the first server verifies the user name information and the password information, and uses the token to respond to the login request after the verification is passed.

Optionally, also include:

Flush the local cache and store the token in the local cache.

Optionally, the recording module 110 includes:

The attribute record unit is used to record the target url using the referrer attribute.

Optionally, also include:

The first judgment module is used to judge whether there is a jump url;

a first sending module, configured to send a default access request to the first server or the second server if there is no jump url;

The second judgment unit is used to judge whether the jump url is the target url if there is a jump url;

The second sending module is used to send an access request to the first server by using the jump url and the token if the jump url is not the target url;

Correspondingly, the access module 130 is a module that uses the token and the target url to send an access request to the second server corresponding to the target webpage if the jump url is the target url.

Optionally, the recording module 110 includes:

a request sending unit, configured to send an interface invocation request corresponding to the target interface on the target webpage to the second server;

a content judging unit for judging whether the response content of the second server is an error code;

The determining unit is configured to determine that if the response content is an error code, it is detected that the invocation of the target interface in the target web page fails.

The web page access device provided by the embodiments of the present application will be introduced below, and the web page access device described below and the web page access method described above may refer to each other correspondingly.

Please refer to FIG. 6 , which is a schematic structural diagram of a device for accessing a webpage according to an embodiment of the present application. The webpage access device 100 may include a processor 101 and a memory 102 , and may further include one or more of a multimedia component 103 , an information input/information output (I/O) interface 104 and a communication component 105 .

Wherein, the processor 101 is used to control the overall operation of the web page access device 100 to complete all or part of the steps in the above-mentioned web page access method; the memory 102 is used to store various types of data to support operations on the web page access device 100, These data may include, for example, instructions for any application or method to operate on the web page access device 100, as well as application-related data. The memory 102 may be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (Electrically Erasable Programmable Read Only Memory) Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (Read-Only) One or more of Memory, ROM), magnetic memory, flash memory, magnetic disk or optical disk.

Multimedia components 103 may include screen and audio components. Wherein the screen can be, for example, a touch screen, and the audio component is used for outputting and/or inputting audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signal may be further stored in the memory 102 or transmitted through the communication component 105 . The audio assembly also includes at least one speaker for outputting audio signals. The I/O interface 104 provides an interface between the processor 101 and other interface modules, and the above-mentioned other interface modules may be a keyboard, a mouse, a button, and the like. These buttons can be virtual buttons or physical buttons. The communication component 105 is used for wired or wireless communication between the web page access device 100 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC for short), 2G, 3G or 4G, or one or a combination of them, so the corresponding communication component 105 may include: Wi-Fi parts, Bluetooth parts, NFC parts.

The webpage accessing device 100 may be implemented by one or more Application Specific Integrated Circuit (ASIC for short), Digital Signal Processor (DSP for short), Digital Signal Processing Device (DSPD for short), Programmable Logic Device (Programmable Logic Device, PLD for short), Field Programmable Gate Array (Field Programmable Gate Array, FPGA for short), controller, microcontroller, microprocessor or other electronic components are implemented for implementing the above-mentioned embodiments. out page access method.

The computer-readable storage medium provided by the embodiments of the present application is introduced below. The computer-readable storage medium described below and the web page access method described above may refer to each other correspondingly.

The present application further provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the above web page access method are implemented.

The computer-readable storage medium may include: a USB flash drive, a removable hard disk, a read-only memory (Read-Only Memory, ROM), a random access memory (Random Access Memory, RAM), a magnetic disk or an optical disk, etc., which can store program codes. medium.

The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts of the various embodiments may be referred to each other. As for the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant part can be referred to the description of the method.

Those skilled in the art may further realize that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two, in order to clearly illustrate the hardware and software In the above description, the components and steps of each example have been generally described according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may use different methods for implementing the described functionality for each particular application, but such implementations should not be considered beyond the scope of this application.

The steps of a method or algorithm described in conjunction with the embodiments disclosed herein may be directly implemented in hardware, a software module executed by a processor, or a combination of the two. A software module can be placed in random access memory (RAM), internal memory, read only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other in the technical field. in any other known form of storage medium.

Finally, it should also be noted that, in this context, relationships such as first and second, etc., are used only to distinguish one entity or operation from another, and do not necessarily require or imply these entities or that there is any such actual relationship or sequence between operations. Furthermore, the terms including, comprising or any other variation are intended to cover non-exclusive inclusion such that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or Yes also includes elements inherent to such a process, method, article or apparatus.

The principles and implementations of the present application are described herein by using specific examples. The descriptions of the above embodiments are only used to help understand the methods and core ideas of the present application. There will be changes in the specific implementation and application scope. To sum up, the content of this specification should not be construed as a limitation on the application.

Claims (10)

1. A method for accessing a web page, comprising:

if the interface in the target webpage is detected to be failed to be called, recording a target url corresponding to the target webpage;

sending a login request to a first server; the webpage corresponding to the first server and the target webpage have different domain names;

and obtaining a token sent by the first server, and sending an access request to a second server corresponding to the target webpage by using the token and the target url so as to access the target webpage again.

2. The method for accessing a web page according to claim 1, wherein the sending an access request to a second server corresponding to the target web page by using the token and the target url includes:

generating an initial access request by using the target url;

and adding a token in the initial access request to obtain the access request, and sending the access request to the second server.

3. The method for accessing a web page according to claim 1, wherein the sending a login request to the first server comprises:

acquiring user name information and password information;

generating the login request by using the user name information and the password information;

and sending the login request to the first server so that the first server can verify the user name information and the password information, and responding to the login request by using the token after the verification is passed.

4. The method for accessing web pages according to claim 1, further comprising, after the obtaining the token sent by the first server:

and emptying a local cache and storing the token in the local cache.

5. The method for accessing a web page according to claim 1, wherein the recording a target url corresponding to the target web page comprises:

and recording the target url by using the referrer attribute.

6. The method for accessing web pages according to claim 1, wherein after the obtaining the token sent by the first server, before the sending an access request to the second server corresponding to the target web page by using the token and the target url, the method further comprises:

judging whether a skip url exists or not;

if the jump url does not exist, sending a default access request to the first server or the second server;

if the jump url exists, judging whether the jump url is the target url;

if the skip url is not the target url, sending the access request to the first server by using the skip url and the token;

and if the skip url is the target url, executing the step of sending an access request to a second server corresponding to the target webpage by using the token and the target url.

7. The method for accessing a web page according to claim 1, wherein the interface calls a failed detection process, comprising:

sending an interface calling request corresponding to a target interface on the target webpage to the second server;

judging whether the response content of the second server is an error code;

and if the response content is the error code, determining that the calling of the target interface in the target webpage fails.

8. A web page access apparatus, comprising:

the recording module is used for recording a target url corresponding to a target webpage if the failure of interface calling in the target webpage is detected;

the login module is used for sending a login request to the first server; the webpage corresponding to the first server and the target webpage have different domain names;

and the access module is used for acquiring the token sent by the first server and sending an access request to a second server corresponding to the target webpage by using the token and the target url so as to access the target webpage again.

9. A web page access device comprising a memory and a processor, wherein:

the memory is used for storing a computer program;

the processor is configured to execute the computer program to implement the web page access method according to any one of claims 1 to 7.

10. A computer-readable storage medium for storing a computer program, wherein the computer program when executed by a processor implements the web page access method of any one of claims 1 to 7.

Images