CN111162956A - Log recording method and device - Google Patents
Log recording method and device Download PDFInfo
- Publication number
- CN111162956A CN111162956A CN201811324793.7A CN201811324793A CN111162956A CN 111162956 A CN111162956 A CN 111162956A CN 201811324793 A CN201811324793 A CN 201811324793A CN 111162956 A CN111162956 A CN 111162956A
- Authority
- CN
- China
- Prior art keywords
- server
- user
- domain name
- user token
- target
- 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
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/02—Capturing of monitoring data
- H04L43/022—Capturing of monitoring data by sampling
-
- 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/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- 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/14—Session management
- H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
-
- 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/56—Provisioning of proxy services
- H04L67/567—Integrating service provisioning from a plurality of service providers
Abstract
The application provides a log recording method and device. The server caches a user token of at least one user and a domain name corresponding to the user token. The method can comprise the following steps: the server side obtains a target user token carried by an HTTP request header of the user side; the server side analyzes whether the target user token exists in the server side cache, and if the target user token exists in the server side cache, the server side analyzes whether the domain name accessed by the user side is matched with the target domain name corresponding to the target user token cached by the server side; and if the domain name accessed by the user side is matched with the target domain name, the service side starts a log recording function on the domain name accessed by the user side. Therefore, only when the user token carried by the HTTP request head of the user end and the domain name accessed by the user end are matched with the user token cached by the server end and the corresponding domain name, the server end can start the log recording function, and the problem that logs can not be recorded aiming at the network access behavior of a specific user in the prior art is solved.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for recording logs.
Background
After the website is online operated, a server providing website resources (such as a WEB server and a cache server) may start a log recording function, for example, record data operation statements, loaded files, program operation events, occupied memory size, and the like executed when a server program is operated, and an IP address, a request event, an accessed domain name, an HTTP source address, and the like of a user side. By checking and analyzing the logs, developers and maintainers of the website can know the operation conditions of the server at each time of the operation of the website, thereby providing reference for the developers to optimize the performance of the website.
In the prior art, if a developer wants to obtain a log of a website operation, the developer can start a log recording function of a server program. However, if the logging function is enabled for the website running on the line, the server program logs whether the developer or the ordinary user accesses the webpage. When a large number of users access the web page, the server program can frequently record a large number of logs, consume limited system resources, and reduce the operating efficiency of the server, so that the response speed of the web page is reduced, and the use experience of the users is influenced. Moreover, because the access amount of the user to the website is usually much larger than that of the developer to the website, most of the logs recorded by the server program are generated according to the behavior of the user access, but the logs are not interested by the users and have no demand, so most of the logs recorded by the server are redundant logs, and the difficulty of the developer in consulting the logs is improved while system resources are consumed.
However, there is no effective solution for logging the behavior of developers' network accesses when logging is enabled for a running website.
Disclosure of Invention
The embodiment of the application provides a log recording method and device, and aims to solve the problem that logs cannot be recorded aiming at network access behaviors of specific users in the prior art.
In a first aspect, the present application provides a log recording method, which is applied to a server, where a user token of at least one user and a domain name corresponding to the user token are cached in the server, and the method specifically includes:
the server side obtains a target user token carried by an HTTP request header of the user side;
the server side analyzes whether the target user token exists in the server side cache;
if the target user token exists in the server cache, the server analyzes whether the domain name accessed by the user side is matched with a target domain name corresponding to the target user token cached by the server;
and if the domain name accessed by the user side is matched with the target domain name, the service side starts a log recording function on the domain name accessed by the user side.
In a second aspect, the present application provides a log recording apparatus, which is applied to a server, where a user token of at least one user and a domain name corresponding to the user token are cached in the server, and the apparatus specifically includes:
the acquisition module is used for acquiring a target user token carried by an HTTP request header of a user side;
the first matching module is used for analyzing whether the target user token exists in the server cache or not;
the second matching module is used for analyzing whether the domain name accessed by the user side is matched with the target domain name corresponding to the target user token cached by the server side or not if the target user token exists in the server side cache;
and the execution module is used for starting a log recording function on the domain name accessed by the user side if the domain name accessed by the user side is matched with the target domain name.
According to the technical scheme, the application provides a log recording method and device. The server caches a user token of at least one user and a domain name corresponding to the user token. The method specifically comprises the following steps: the server side obtains a target user token carried by an HTTP request header of the user side; then, the server side analyzes whether the target user token exists in the server side cache, and if the target user token exists in the server side cache, the server side analyzes whether the domain name accessed by the user side is matched with the target domain name corresponding to the target user token cached by the server side; and finally, if the domain name accessed by the user side is matched with the target domain name, the service side starts a log recording function on the domain name accessed by the user side. Therefore, according to the technical scheme provided by the application, when a user accesses a website, only when the user token carried by the HTTP request header of the user side and the domain name accessed by the user side are matched with the user token cached by the server side and the corresponding domain name, the server side can start the log recording function, and therefore the problem that logs cannot be recorded aiming at the network access behavior of a specific user in the prior art is solved.
In a third aspect, the present application provides a log recording method, which is applied to a user side, and specifically includes:
a user side acquires a user token owned by a current user;
the user side sends an HTTP request head to the server side, the HTTP request head carries a user token, and the user token is used for indicating the server side to start a log recording function.
In a fourth aspect, the present application provides a logging apparatus, which is applied to a user side, and specifically includes:
the acquisition module is used for acquiring a user token of a current user, and the user token is generated by a server;
and the sending module is used for sending an HTTP request head to the server, wherein the HTTP request head carries a user token, and the user token is used for indicating the server to start a log recording function.
According to the technical scheme, the application provides a log recording method and device. Firstly, a user side acquires a user token owned by a current user; and then, the user side sends an HTTP request head to the server side, the HTTP request head carries a user token, and the user token is used for indicating the server side to start a log recording function. Therefore, a user with a user token can send an HTTP request head carrying the user token to a server through a user side, so that the server starts a log recording function according to the user token, and for the server, when the user accesses a website, the log recording function can be started only when the user token carried by the HTTP request head of the user side and a domain name accessed by the user side are matched with the user token and the domain name cached by the server, so that the problem that logs can not be recorded aiming at network access behaviors of specific users in the prior art is solved.
Drawings
In order to more clearly explain the technical solution of the present application, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious to those skilled in the art that other drawings can be obtained according to the drawings without any creative effort.
Fig. 1 is a flowchart of a log recording method according to an embodiment of the present application;
fig. 2 is a flowchart of a log recording method step S130 according to an embodiment of the present application;
fig. 3 is a flowchart of a log recording method step S140 according to an embodiment of the present application;
fig. 4 is a schematic diagram of data flow at a user side according to an embodiment of the present application;
fig. 5 is a flowchart of a log recording method according to an embodiment of the present application;
fig. 6 is a flowchart of a log recording method step S210 according to an embodiment of the present application;
fig. 7 is a schematic diagram of a logging apparatus according to an embodiment of the present disclosure;
fig. 8 is a schematic diagram of a second matching module 330 of a logging apparatus according to an embodiment of the present disclosure;
fig. 9 is a schematic diagram of a logging apparatus according to an embodiment of the present application.
Detailed Description
In order to make those skilled in the art better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
After the website is online operated, a server providing website resources (such as a WEB server and a cache server) may start a log recording function, for example, record data operation statements, loaded files, program operation events, occupied memory size, and the like executed when a server program is operated, and an IP address, a request event, an accessed domain name, an HTTP source address, and the like of a user side.
In the prior art, if a developer wants to obtain a log of a website operation, the developer can start a log recording function of a server program. However, if the logging function is enabled for the website running on the line, the server program logs whether the developer or the ordinary user accesses the webpage. When a large number of users access the web page, the server program can frequently record a large number of logs, consume limited system resources, and reduce the operating efficiency of the server, so that the response speed of the web page is reduced, and the use experience of the users is influenced. Moreover, because the access amount of the user to the website is usually much larger than that of the developer to the website, most of the logs recorded by the server program are generated according to the behavior of the user access, but the logs are not interested by the users and have no demand, so most of the logs recorded by the server are redundant logs, and the difficulty of the developer in consulting the logs is improved while system resources are consumed.
In order to solve the above problem, some solutions propose to turn on the logging function of the server in the test environment. However, in the test environment, the number of clients connected to the server and the load generated by the server are far from the actual situation in the production environment, and therefore, the log obtained in the test environment cannot reflect the actual performance of the server in the production environment.
Other proposals provide that after the user logs in the website, the logging function is started. However, many websites do not require the user to log in, and thus, the feasibility of this approach is not high.
Some proposals also provide that a switch is arranged in the background of the server to control the server to start or close the logging function. The disadvantage of this solution is that once the background switch is turned on, the access behaviors of all website users including developers and common users are logged by the server, which may result in an excessive load on the server, a reduction in response speed of the server, and a redundancy in log amount. In addition, if the user forgets to turn off the switch, the server will record logs all the time, which may cause risks such as overflow of the memory of the server.
Therefore, some solutions proposed by the prior art can not solve the problems existing in the prior art.
The embodiment of the application provides a log recording method which can be applied to a server side. The server may include, for example, a WEB server and the like, and is used to provide data resources of a website and record a log generated by a server program.
Specifically, in the log recording method provided by the embodiment of the present application, the user token of at least one user and the domain name corresponding to the user token are cached at the server. The user token and the domain name corresponding to the user token may be cached in, for example, a RAM (random access memory) of the WEB server, a HDD (hard disk drive) of the WEB server, or a flash memory (e.g., SSD (solid-state drive)) of the WEB server.
For example, referring to table 1, the user token and the domain name corresponding to the user token may be cached in the form of a data table:
| Key | Value |
| logToken：Ado | admin.xin.com |
| logToken：Tomas | wx.qlogo.cn |
| logToken：Nick | nexus.officeapps.live.com |
TABLE 1 user token and Domain name cached by the Server
As shown in table 1, the user token and the domain name cached by the server are stored in pair in the form of "Key-Value". The "Key" and the "Value" are names of data keys, a Key Value of the data Key "is a name of a user token, and a Key Value of the data Key" Value "is a domain name corresponding to the user token. Specifically, for example, in the Key value "logToken" of "Key": ado "in which" logToken "is the declaration of the user token, indicating that the key is a user token, and" Ado "is the name of the user, indicating that the user token belongs to the user Ado; further, a key Value "admin. xin. com" such as "Value" represents that the user token "logToken: ado "corresponding domain name.
Additionally, in some embodiments, each user token may correspond to one or more domain names, see, for example, table 2:
| Key | Value |
| logToken：Ado | img.xin.com |
| logToken：Ado | admin.xin.com |
| logToken：Tomas | wx.qlogo.cn |
| logToken：Nick | nexus.officeapps.live.com |
table 2 user token and domain name cached by server
As shown in table 2, "Key" has two identical Key values "logToken: ado ", two key values corresponding to" Value ", whereby the user token" logToken: two domain names are corresponding to Ado'. Therefore, in a mode that one user token corresponds to a plurality of domain names, a user can indicate the server to start a log recording function on the plurality of domain names through the same user token.
Additionally, in some embodiments, each user may possess one or more user tokens, see, for example, table 3:
TABLE 3 user token and Domain name cached by the Server
As shown in table 3, "Key" has two Key values "logToken: ado _0 "and" logToken: ado _1 ", which means that the user Ado has two user tokens, which correspond to different domain names, respectively. Therefore, the user can use different user tokens according to the self requirement so as to realize the function of starting the log record of different domain names.
Further, in some embodiments, Redis may be used to store the user token and domain name. Redis is a network-enabled, memory-based, optionally persistent, key-value pair storage database written using ANSI C. In the Redis, a user token and a domain name corresponding to the user token are stored in a form of a "Key-Value" Key Value pair, the Redis database may be cached in a RAM (random access memory) of a WEB server, for example, and the high-speed storage and reading of the user token and the domain name are realized by using the high-speed access capability of the RAM which is far superior to that of an HDD (hard disk drive) and a flash memory (e.g., a SSD (solid-state drive, etc.); in addition, when the Redis database is stored in the RAM, the temporary storage of the user token and the domain name is realized by utilizing the volatility of the RAM, the user can temporarily configure the user token and the domain name which need to be used at the server side, and the data such as the user token and the domain name which are used by the user can be erased at any time after the user token and the domain name are used, so that the user token is prevented from being stolen by a third person, and the safety of the user token is ensured. In addition, the Redis database may be persistently stored in, for example, a hard disk (HDD) of the WEB server, or cached in a flash memory (e.g., a solid-state drive (SSD)) of the WEB server, so that even after an unexpected fault such as power loss occurs in the WEB server, the user token and the domain name are not erased, log data at the time of the unexpected fault can be recorded, and more comprehensive reference data can be provided for a user to analyze the fault cause.
Further, the user token may include other data formats in addition to the data format caching of key-value pairs as shown above, such as:
an example unstructured data format may be:
“logToken：Ado；img.xin.com”
“logToken：Tomas；wx.qlogo.cn”
when each user token may correspond to multiple domain names, the unstructured data format of the above example may be:
“logToken：Ado；img.xin.com，admin.xin.com”
when each user may own multiple user tokens, the unstructured data of the above example may be:
“logToken：Ado_1；img.xin.com|Ado_2：admin.xin.com”
it should be added that the storage manner and data format of the user token and the domain name shown above are only a part of the embodiments shown in the embodiments of the present application, and not all of the embodiments, and those skilled in the art may also design other embodiments under the technical design and concept of the user token and the domain name shown in the embodiments of the present application, and the design and concept herein can be applied without departing from the protection scope of the embodiments of the present application.
Fig. 1 is a flowchart of a log recording method according to an embodiment of the present application.
In a case that a server caches a user token of at least one user and a domain name corresponding to the user token, as shown in fig. 1, the diary recording method provided in the embodiment of the present application may include the following steps:
step S110, the server side obtains a target user token carried by the HTTP request head of the user side.
Specifically, the user may add a target user token owned by the user at the user side, and before the user side sends the HTTP request to the server side, the target user token is added to the HTTP request header, and then the HTTP request header to which the user token is added is sent to the server side, so that the server side may obtain the target user token from the received HTTP request header.
HTTP request headers (HTTP headers) are information indicating the type of a request when a HTTP (hypertext transfer protocol) client program (e.g., a WEB browser) sends the request to a WEB server (server). When a user inputs a domain name of a website in an address bar of a WEB browser at a service end, or a domain name access request is triggered through operation in the WEB browser, the WEB browser creates and sends an HTTP request to a WEB server according to the domain name, and an HTTP request head of the HTTP request contains the domain name to be accessed by the user, information of the WEB browser and the like. When the WEB server receives the HTTP request, it parses the domain name and other information in the HTTP request header.
Exemplarily, when the domain name input by the user Ado in the address bar of the browser is "img.xin.com", the server adds a target user token "logToken" of the user Ado in the HTTP request header: the result of Ado "is (other information in the HTTP request header is not shown):
“
……
Host：img.xin.com
logToken：Ado
……
”
wherein the "Host: com "indicates that the domain name that the user side requests the service side to access is" img.xin.com "," logToken: ado "is a target user token for user Ado.
Further, when the server receives the HTTP request header sent by the user, the server may first check the content of the HTTP request header, analyze whether the HTTP request header includes the "logToken" field, if not, the server may not start the logging function for the domain name currently accessed by the user, and if the "logToken" field is included, execute step S120.
Therefore, the server side performs first verification on the HTTP request header sent by the user side by analyzing whether the HTTP request header contains the 'logToken' field, and when the HTTP request header does not contain the 'logToken' field, the server side cannot start a log recording function, so that when the server side runs in a production environment, the server side cannot record logs on the network access behavior of the ordinary user because the ordinary user does not have a user token.
Step S120, the server side analyzes whether the target user token exists in the server side cache.
When the server side obtains the target user token from the HTTP request head, the server side matches the target user token with the user token cached by the server side, so that whether the target user token exists in the server side cache or not is analyzed.
For example, the server caches the user token and the domain name whose contents are shown in table 1 through the Redis database, and then, when the server obtains the contents "logToken: when Ado's target user token, the server uses the token of "logToken: ado "matches all Key values owned by the data Key" of the Redis database, and thus can match the Key value "logToken: ado ", illustrating the target user token" logToken: ado "exists in the server cache, thereby performing step S130. Further, if the server uses "logToken: ado 'cannot match a corresponding key value in the Redis database, which indicates that the target user token' logToken: ado' does not exist in the server cache, and the server does not record logs for the network access behaviors of the Ado of the user.
Step S130, if the target user token exists in the server cache, the server analyzes whether the domain name accessed by the user side matches the target domain name corresponding to the target user token cached by the server.
Specifically, if the target user token exists in the server cache, the server acquires the domain name of the domain name accessed by the user terminal from the HTTP request header, and matches the domain name with the target domain name corresponding to the target user token cached by the server.
Illustratively, when the target user token is "logToken: ado ", and the domain name obtained by the server from the HTTP request header of the client is: com, if the target user token "logToken" cached by the server: if the target domain name corresponding to Ado is admin.xin.com, it indicates that the domain name accessed by the user side is matched with the target domain name, and step S140 should be further executed; if the target user token 'logToken' cached by the server: if the target domain name corresponding to Ado' is other content, it indicates that the domain name accessed by the user end is not matched with the target domain name, and the server end cannot start the log recording function.
It should be added that, because a user usually opens or jumps multiple web pages continuously while browsing a website, thereby initiating multiple HTTP requests containing different domain names, if the user wants to open log records to all the domain names by the server, all the domain names need to be cached to the server, which results in an excessive number of domain names cached by the server, and reduces the domain name matching efficiency.
For example, if the user Ado wants to start the logging function for two domain names of "www.xin.com/app/" and "www.xin.com/app/sj", the user needs to cache the contents as shown in table 4 at the server:
| Key | Value |
| logToken：Ado | www.xin.com/app/ |
| logToken：Ado | www.xin.com/app/sj |
table 4 user token and domain name cached by server
Then, if the user wants more domain names for the server to record logs, the data size in table 4 is also more, which is not beneficial to improving the matching efficiency and is also not beneficial to maintenance and management.
Therefore, in an embodiment, in order to reduce the number of domain names cached by the server and improve the matching efficiency, the embodiment of the present application further provides some achievable domain name matching methods, for example, a parent-level domain name matching method: as long as the full word of the target domain name cached by the server is the same as the parent domain name of the domain name accessed by the user terminal, the two domain names are considered to be matched.
Illustratively, the server caches the contents as shown in table 5 below:
| Key | Value |
| logToken：Ado | www.xin.com/app/ |
TABLE 5 user token and Domain name cached by the Server
Then, when the domain name accessed by the user side is www.xin.com/app/, the domain name accessed by the user side is the same as the target domain name cached by the server side, and therefore, the two domain names match. When the domain name requested by the user side is www.xin.com/app/sj, its parent domain name www.xin.com/app/is the same as the target domain name cached by the server side, so the two domain names also match. Therefore, by the parent-level domain name matching method, if a log recording function is started for a plurality of webpages with common parent-level domain names, the common parent-level domain names of the domain names are cached at the server as target domain names, so that the number of the domain names needing to be cached by the server can be reduced, and the matching efficiency is improved.
Step S140, if the domain name accessed by the user end matches the target domain name, the server end starts a log recording function for the domain name accessed by the user end.
The user can configure the content of the log recorded by the server according to the self requirement, for example: the server executes which SQL (structured query language) statements, which files are loaded, which programs are executed, execution time of the programs, occupied memory (RAM) size, processor utilization rate, and the like in response to one HTTP request.
According to the technical scheme, the log recording method is provided. The server caches a user token of at least one user and a domain name corresponding to the user token. The method specifically comprises the following steps: the server side obtains a target user token carried by an HTTP request header of the user side; then, the server side analyzes whether the target user token exists in the server side cache, and if the target user token exists in the server side cache, the server side analyzes whether the domain name accessed by the user side is matched with the target domain name corresponding to the target user token cached by the server side; and finally, if the domain name accessed by the user side is matched with the target domain name, the service side starts a log recording function on the domain name accessed by the user side. Therefore, according to the method provided by the application, when a user accesses a website, only when the user token carried by the HTTP request header of the user side and the domain name accessed by the user side are matched with the user token cached by the server side and the corresponding domain name, the server side can start the log recording function, and therefore the problem that logs cannot be recorded aiming at the network access behavior of a specific user in the prior art is solved.
Fig. 2 is a flowchart of a log recording method step S130 according to an embodiment of the present application.
In one embodiment, the service end sets an expiration date for the cached user token, and the step S130, as shown in fig. 2, may include the following steps:
step S131, if the target user token exists in the server cache, the server analyzes whether the target user token is valid according to the validity period.
Specifically, when the server creates the user token for the user, the time for creating the user token can be recorded, and the validity period of the user token is set, so that the user token automatically fails after the validity period elapses. The server may set the same validity period for all the user tokens, for example, the validity period is 10 minutes; it is also possible to set different validity periods for each user token or for each user token, for example, a validity period of 10 minutes for the user token of user Ado, a validity period of 20 minutes for the user token of user Tomas, etc.
Illustratively, the user token "logToken" of the user Ado: ado "is created at the server end in 2019, 1, 11: 30: 00, effective period of 10 minutes. If the server side is in 2019, 1 month, 1 day, 11: 37: 45, a token "logToken" carrying a target user is obtained: ado "HTTP request header, the user token is valid, step S132 is performed. If the server side is in 2019, 1 month, 1 day, 11: 40: 01, a token "logToken" carrying a target user is obtained: ado ", the target user token is invalid, and the server does not start the logging function.
Step S132, if the target user token is valid, the server analyzes whether the domain name accessed by the user side is matched with the target domain name.
Specifically, if the target user token is valid, the server acquires the domain name accessed by the user terminal from the HTTP request header, and matches the domain name with the target domain name corresponding to the target user token cached by the server terminal. Please refer to the contents of step S130 in the embodiments of the present application for a specific matching method, which is not described herein again.
Therefore, the user token is invalid in time after being used by setting the valid time for the user token, so that the user token is prevented from being utilized by other people under the condition of accidental leakage; meanwhile, the time length of the server side for recording the logs can be limited, and the situation that the server side records the logs all the time when the user forgets to close the log recording function of the server side is prevented.
In one embodiment, the service end resets the validity period of the cached target user token when the service end starts the logging function on the domain name accessed by the user end. Therefore, if the server does not continuously acquire the HTTP request header carrying the target user token, the target user token fails after the validity period expires, and the time length for the server to record the log is equal to the time length of the validity period; if the server side continues to acquire the HTTP request head carrying the target user token, the valid period of the target user token is continuously reset, and the server side continuously records the log. Therefore, the log can be continuously recorded by the server during the period that the user side has active network access behaviors, and the log recording function can be timely closed by the server after the user side stops network access, so that system resources are released.
Fig. 3 is a flowchart of a log recording method step S140 according to an embodiment of the present application.
In one embodiment, as shown in fig. 3, step S140 may include the steps of:
in step S141, the server monitors whether the cached target user token is within the validity period.
Specifically, after the server side starts the logging function, whether the target user token is in the valid period is continuously monitored.
Illustratively, the creation time of the target user token is 2019, 1, 11: 30: 00, effective period of 10 minutes. If the server does not reset the validity period of the target user token when the logging function is started, the validity period of the target user token is 2019, 1 month, 1 day, 11: 30: 1 month, 1 day, 11 in 00-2019: 39: 59; if the service end sets the valid period of the reset target user token when the logging function is started, the valid period of the user target token is within 10 minutes after the reset time.
In step S1411, if the service end is in the valid period, the service end keeps the logging function in the on state.
In step S1412, if the time period is not within the validity period, the server closes the logging function.
Therefore, the log can be continuously recorded by the server during the period that the user side has active network access behaviors, and the log recording function can be timely closed by the server after the user side stops network access, so that system resources are released.
Fig. 4 is a schematic diagram of data flow at a user side according to an embodiment of the present application.
In one embodiment, as shown in fig. 4, the client is provided with a proxy server, and the proxy server is configured to send the HTTP request header to the server after adding the user token to the HTTP request header of the client, so that the server obtains the target user token from the HTTP request header sent by the proxy server.
Specifically, a user may perform an operation such as input or click on a WEB browser at a user side to generate an HTTP request pointing to a certain domain name, where the HTTP request carries an HTTP request header, and the proxy server first obtains the HTTP request, adds a pre-configured target user token in the HTTP request header, and then sends the HTTP request header added with the target user token to the server side. Therefore, when a plurality of users need to start the log recording function of the server, only the target user token owned by the user needs to be configured in the proxy server, so that the method is flexible to use and convenient to maintain.
The embodiment of the application provides a log recording method which can be applied to a user side.
Fig. 5 is a flowchart of a log recording method according to an embodiment of the present application. As shown in fig. 5, the method specifically includes the following steps:
step S210, the user side obtains a user token owned by the current user.
Specifically, a legal user token should be generated and distributed to the user by the server, and after the user takes the user token, the user token may be input to the user side, so that the user side acquires and records the user token. For the data format, the generation mode, and the like of the user token, please refer to the contents set forth in the foregoing embodiments of the present application, which are not described herein again.
Step S220, the user side sends an HTTP request head to the server side, the HTTP request head carries a user token, and the user token is used for indicating the server side to start a log recording function.
According to the technical scheme, the log recording method is provided. Firstly, a user side acquires a user token owned by a current user; and then, the user side sends an HTTP request head to the server side, the HTTP request head carries a user token, and the user token is used for indicating the server side to start a log recording function. Therefore, a user with a user token can send an HTTP request head carrying the user token to a server through a user side, so that the server starts a log recording function according to the user token, and for the server, when the user accesses a website, the log recording function can be started only when the user token carried by the HTTP request head of the user side and a domain name accessed by the user side are matched with the user token and the domain name cached by the server, so that the problem that logs can not be recorded aiming at network access behaviors of specific users in the prior art is solved.
Fig. 6 is a flowchart of step S210 of a logging method according to an embodiment of the present application.
In one embodiment, as shown in fig. 4, the user side is provided with a proxy server. Step S210 the fig. 6 shows that the following steps may be included:
step S211, the user configures the user token of the current user in the proxy server.
For example, the proxy server may be Charles, Charles an HTTP proxy server, Charles may monitor all data sent and received by a browser when the browser at the user end connects Charles to access the internet, Charles allows the user to view HTTP communications sent and received via Charles, for example: HTTP request, HTTP response header, and the like.
Therefore, the user configures the user token of the current user in the proxy server, so that the proxy server is allowed to add the user token in the HTTP request header sent by the browser of the user side, and the HTTP request header added with the user token is sent to the server side.
It should be noted that, if the HTTP request header is an HTTPs (hypertext transfer protocol secure) request header, a CA certificate (authentication authority) needs to be installed for the proxy server, so that the proxy server can successfully decrypt the information in the HTTPs request header to smoothly add the user token.
In step S212, the user end sets the address of the proxy server as the destination address for sending the HTTP request header.
Therefore, the user side does not directly send the HTTP request head to the server side, but sends the HTTP request head to the target address, namely the proxy server, so that the proxy server adds the user token into the HTTP request head and forwards the HTTP request head added with the user token to the server side.
The following are embodiments of an apparatus of the present application, which may be used to perform embodiments of the method of the present application, including software modules for performing the various steps of embodiments of the method of the present application. For details which are not disclosed in the embodiments of the apparatus of the present application, reference is made to the embodiments of the method of the present application.
The embodiment of the application provides a log recording device which is applied to a server side. The server caches a user token of at least one user and a domain name corresponding to the user token.
Fig. 7 is a schematic diagram of a logging apparatus according to an embodiment of the present application. As shown in fig. 7, the apparatus includes:
an obtaining module 310, configured to obtain a target user token carried by an HTTP request header of a user side;
a first matching module 320, configured to analyze whether a target user token exists in a server cache;
a second matching module 330, configured to analyze whether a domain name accessed by the user side matches a target domain name corresponding to the target user token cached by the server side if the target user token exists in the server side cache;
the executing module 340 starts a log recording function for the domain name accessed by the user terminal if the domain name accessed by the user terminal is matched with the target domain name.
According to the technical scheme, the log recording device is applied to the server side. The server caches a user token of at least one user and a domain name corresponding to the user token. The device is used for acquiring a target user token carried by an HTTP request header of a user side; then, whether the target user token exists in the server cache is analyzed, and if the target user token exists in the server cache, whether the domain name accessed by the user side is matched with the target domain name corresponding to the target user token cached by the server is analyzed; and finally, if the domain name accessed by the user side is matched with the target domain name, starting a log recording function on the domain name accessed by the user side. Therefore, according to the device provided by the application, when a user accesses a website, only when the user token carried by the HTTP request header of the user side and the domain name accessed by the user side are matched with the user token cached by the server side and the corresponding domain name, the server side can start the log recording function, and therefore the problem that logs cannot be recorded aiming at the network access behavior of a specific user in the prior art is solved.
Fig. 8 is a schematic diagram of a second matching module 330 of a logging apparatus according to an embodiment of the present disclosure.
In one embodiment, as shown in fig. 8, the second matching module 330 includes:
and the validity period analysis sub-module 331 is configured to, if the target user token exists in the server cache, analyze whether the target user token is valid according to the validity period.
A domain name matching sub-module 332, configured to analyze whether a domain name accessed by the user end matches the target domain name if the target user token is valid.
Therefore, the user token is invalid in time after being used by setting the valid time for the user token, so that the user token is prevented from being utilized by other people under the condition of accidental leakage; meanwhile, the time length of the server side for recording the logs can be limited, and the situation that the server side records the logs all the time when the user forgets to close the log recording function of the server side is prevented.
The embodiment of the application provides a log recording device which is applied to a user side.
Fig. 9 is a schematic diagram of a logging apparatus according to an embodiment of the present application. As shown in fig. 9, the apparatus includes:
an obtaining module 410, configured to obtain a user token of a current user, where the user token is generated by a server;
the sending module 420 is configured to send an HTTP request header to the server, where the HTTP request header carries a user token, and the user token is used to instruct the server to start a log recording function.
According to the technical scheme, the application provides a log recording method and device. Firstly, a user side acquires a user token owned by a current user; and then, the user side sends an HTTP request head to the server side, the HTTP request head carries a user token, and the user token is used for indicating the server side to start a log recording function. Therefore, a user with a user token can send an HTTP request head carrying the user token to a server through a user side, so that the server starts a log recording function according to the user token, and for the server, when the user accesses a website, the log recording function can be started only when the user token carried by the HTTP request head of the user side and a domain name accessed by the user side are matched with the user token and the domain name cached by the server, so that the problem that logs can not be recorded aiming at network access behaviors of specific users in the prior art is solved.
Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.
It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.
Claims (10)
1. A log recording method is applied to a server, and is characterized in that the server caches a user token of at least one user and a domain name corresponding to the user token, and the method comprises the following steps:
a server side acquires a target user token carried by HTTP request headers (HTTP header fields) of a user side;
the server side analyzes whether the target user token exists in a server side cache;
if the target user token exists in the server cache, the server analyzes whether the domain name accessed by the user side is matched with a target domain name corresponding to the target user token cached by the server;
and if the domain name accessed by the user side is matched with the target domain name, the server side starts a log recording function on the domain name accessed by the user side.
2. The method of claim 1, wherein a service end sets an expiration date for the cached user token, and the analyzing, by the service end, whether the domain name accessed by the user end matches a target domain name corresponding to the target user token cached by the service end if the target user token exists in the service end cache comprises:
if the target user token exists in the server cache, the server analyzes whether the target user token is valid according to the validity period;
and if the target user token is valid, the server side analyzes whether the domain name accessed by the user side is matched with the target domain name.
3. The method of claim 2, wherein the server opens a logging function for a domain name accessed by the user side, and further comprising:
and the server resets the validity period of the cached target user token.
4. The method according to any one of claims 2 or 3, wherein the server side starts a logging function for the domain name accessed by the user side, and the logging function comprises:
the server side monitors whether the cached target user token is in the valid period or not;
if the log recording function is in an open state in the valid period, the server side keeps the log recording function;
and if the log record function is not in the validity period, the server side closes the log record function.
5. The method according to claim 1, wherein the client is provided with a proxy server, the proxy server is configured to send the HTTP request header to the server after adding the target user token to the HTTP request header of the client, and the server obtains the target user token carried by the HTTP request header of the client, including:
and the server side acquires the target user token from the HTTP request header sent by the proxy server.
6. A logging method is applied to a user side, and is characterized by comprising the following steps:
a user side acquires a user token owned by a current user;
and the user side sends an HTTP request head to the server side, wherein the HTTP request head carries the user token, and the user token is used for indicating the server side to start a log recording function.
7. The method according to claim 6, wherein a proxy server is provided at the client, and the client obtains the user token generated by the server, including:
a user side configures a user token of a current user in a proxy server;
and the client sets the address of the proxy server as a target address for sending the HTTP request header.
8. The method of claim 7, wherein the sending, by the client, an HTTP request header to a server, the HTTP request header carrying the user token, comprises:
and the user side sends an HTTP request head to the proxy server according to the target address, and the proxy server is used for adding a user token into the HTTP request head and forwarding the HTTP request head to the server side.
9. A log recording device is applied to a server, and is characterized in that the server caches a user token of at least one user and a domain name corresponding to the user token, and the device comprises:
the acquisition module is used for acquiring a target user token carried by an HTTP request header of a user side;
the first matching module is used for analyzing whether the target user token exists in a server cache or not;
the second matching module is used for analyzing whether the domain name accessed by the user side is matched with the target domain name corresponding to the target user token cached by the server side or not if the target user token exists in the server side cache;
and the execution module is used for starting a log recording function on the domain name accessed by the user side if the domain name accessed by the user side is matched with the target domain name.
10. A logging device applied to a user side is characterized in that the logging device comprises:
the acquisition module is used for acquiring a user token of a current user, and the user token is generated by a server;
and the sending module is used for sending an HTTP request head to a server, wherein the HTTP request head carries the user token, and the user token is used for indicating the server to start a log recording function.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811324793.7A CN111162956B (en) | 2018-11-08 | 2018-11-08 | Log recording method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811324793.7A CN111162956B (en) | 2018-11-08 | 2018-11-08 | Log recording method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111162956A true CN111162956A (en) | 2020-05-15 |
| CN111162956B CN111162956B (en) | 2021-07-30 |
Family
ID=70555475
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811324793.7A Active CN111162956B (en) | 2018-11-08 | 2018-11-08 | Log recording method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111162956B (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112312165A (en) * | 2020-10-19 | 2021-02-02 | 中移（杭州）信息技术有限公司 | Video distribution method and device and computer readable storage medium |
| CN113746673A (en) * | 2021-08-24 | 2021-12-03 | 济南浪潮数据技术有限公司 | Method, device, equipment and medium for deploying bare metal server ipxe |
| CN114697140A (en) * | 2022-05-30 | 2022-07-01 | 云账户技术(天津)有限公司 | Method and device for acquiring application log, electronic equipment and storage medium |
| WO2023026086A1 (en) * | 2021-08-25 | 2023-03-02 | Sensetime International Pte. Ltd. | Logging method and apparatus, electronic device, and computer-readable storage medium |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007172695A (en) * | 2005-12-20 | 2007-07-05 | Matsushita Electric Ind Co Ltd | Optical disk device |
| CN101242307A (en) * | 2008-02-01 | 2008-08-13 | 刘峰 | Website access analysis system and method based on built-in code proxy log |
| US20110247085A1 (en) * | 2010-03-30 | 2011-10-06 | Hon Hai Precision Industry Co., Ltd. | Electronic device and method of protecting software |
| CN103645982A (en) * | 2013-11-29 | 2014-03-19 | 北京奇虎科技有限公司 | Log processing method and client |
| CN105005600A (en) * | 2015-07-02 | 2015-10-28 | 焦点科技股份有限公司 | Preprocessing method of URL (Uniform Resource Locator) in access log |
| CN107294903A (en) * | 2016-03-30 | 2017-10-24 | 无锡天脉聚源传媒科技有限公司 | A kind of network address access method and device |
| CN108449349A (en) * | 2018-03-23 | 2018-08-24 | 新华三大数据技术有限公司 | The method and device for preventing malice domain name from attacking |
-
2018
- 2018-11-08 CN CN201811324793.7A patent/CN111162956B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007172695A (en) * | 2005-12-20 | 2007-07-05 | Matsushita Electric Ind Co Ltd | Optical disk device |
| CN101242307A (en) * | 2008-02-01 | 2008-08-13 | 刘峰 | Website access analysis system and method based on built-in code proxy log |
| US20110247085A1 (en) * | 2010-03-30 | 2011-10-06 | Hon Hai Precision Industry Co., Ltd. | Electronic device and method of protecting software |
| CN103645982A (en) * | 2013-11-29 | 2014-03-19 | 北京奇虎科技有限公司 | Log processing method and client |
| CN105005600A (en) * | 2015-07-02 | 2015-10-28 | 焦点科技股份有限公司 | Preprocessing method of URL (Uniform Resource Locator) in access log |
| CN107294903A (en) * | 2016-03-30 | 2017-10-24 | 无锡天脉聚源传媒科技有限公司 | A kind of network address access method and device |
| CN108449349A (en) * | 2018-03-23 | 2018-08-24 | 新华三大数据技术有限公司 | The method and device for preventing malice domain name from attacking |
Non-Patent Citations (1)
| Title |
|---|
| 张煜: "一种HTTP前端替换方案的研究与实现", 《中国优秀硕士学位论文全文数据库 信息科技辑》 * |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112312165A (en) * | 2020-10-19 | 2021-02-02 | 中移（杭州）信息技术有限公司 | Video distribution method and device and computer readable storage medium |
| CN113746673A (en) * | 2021-08-24 | 2021-12-03 | 济南浪潮数据技术有限公司 | Method, device, equipment and medium for deploying bare metal server ipxe |
| CN113746673B (en) * | 2021-08-24 | 2023-03-24 | 济南浪潮数据技术有限公司 | Method, device, equipment and medium for deploying bare metal server ipxe |
| WO2023026086A1 (en) * | 2021-08-25 | 2023-03-02 | Sensetime International Pte. Ltd. | Logging method and apparatus, electronic device, and computer-readable storage medium |
| CN114697140A (en) * | 2022-05-30 | 2022-07-01 | 云账户技术(天津)有限公司 | Method and device for acquiring application log, electronic equipment and storage medium |
| CN114697140B (en) * | 2022-05-30 | 2022-08-23 | 云账户技术(天津)有限公司 | Method and device for acquiring application log, electronic equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111162956B (en) | 2021-07-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111162956B (en) | Log recording method and device | |
| US8850550B2 (en) | Using cached security tokens in an online service | |
| US10079907B2 (en) | Cached data detection | |
| US8595847B2 (en) | Systems and methods to control web scraping | |
| US11695842B2 (en) | Managing operation of instances | |
| US8219752B1 (en) | System for caching data | |
| US8463998B1 (en) | System and method for managing page variations in a page delivery cache | |
| RU2358306C2 (en) | Substitution after caching | |
| US20120084346A1 (en) | Page Loading Optimization Using Page-Maintained Cache | |
| US8365241B1 (en) | Method and apparatus for archiving web content based on a policy | |
| CN102982082A (en) | Intelligent caching for security trimming | |
| US10567388B1 (en) | Automatic account resource and policy decommissioning | |
| CN108334641B (en) | Method, system, electronic equipment and storage medium for collecting user behavior data | |
| US20080177647A1 (en) | Online Compliance Engine | |
| US11095705B2 (en) | Content distributed over secure channels | |
| CN111539775B (en) | Application management method and device | |
| US11645186B2 (en) | Remote deployment of monitoring agents on computing systems | |
| US8997076B1 (en) | Auto-updating an application without requiring repeated user authorization | |
| US11562044B1 (en) | Systems and methods for integraton of electronic information cards into a client application | |
| US8296262B1 (en) | Systems and methods for real-time online monitoring of computing devices | |
| CN111460256A (en) | Webpage data crawling method and device, computer equipment and storage medium | |
| CN112491931A (en) | JWT (just noticeable WT) -based current limiting method and device for user authentication | |
| CN116319090B (en) | Power and environment monitoring system and method based on micro-service | |
| Fan et al. | A dynamic password authentication system based on nosql and rdbms combination | |
| US20200401559A1 (en) | File transferring using artificial intelligence |
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 |