CN111181961A - User offline detection method and device - Google Patents
User offline detection method and device Download PDFInfo
- Publication number
- CN111181961A CN111181961A CN201911394775.0A CN201911394775A CN111181961A CN 111181961 A CN111181961 A CN 111181961A CN 201911394775 A CN201911394775 A CN 201911394775A CN 111181961 A CN111181961 A CN 111181961A
- Authority
- CN
- China
- Prior art keywords
- user
- authentication
- browser
- usb key
- user name
- 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.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
Abstract
The application provides a user offline detection method and device. A user offline detection method is applied to a client and comprises the following steps: when a USB Key insertion event is detected, accessing a Portal authentication page through a browser; acquiring authentication information input by a user in the Portal authentication page; the authentication information includes at least: a user name and a password; comparing whether the user name is consistent with the user name recorded by the USB Key, and if so, sending the authentication information to authentication equipment for authentication so that the user can access network resources when the user passes the authentication; and when the USB Key pulling event is detected, sending a offline request to the authentication equipment to download the user. By the method, when the USB Key is detected to be pulled out, the offline request is sent to the authentication equipment, so that the authentication equipment can timely take the user offline.
Description
Technical Field
The present application relates to the field of communications technologies, and in particular, to a method and an apparatus for detecting a user offline.
Background
Portal authentication, also known as Web authentication, is a common authentication method. When the unauthenticated user accesses the internet through the client, the unauthenticated user receives a specific authentication page pushed by the authentication equipment, fills authentication information such as a user name, a password and the like in the page, and can access network resources after being successfully authenticated by the authentication equipment.
Generally, the authentication device monitors the internet traffic of a client used by a user, and if the internet traffic of the client is not monitored within a certain time, the authentication device takes the user off-line. However, if the user uses the computer to access the network resources after the Portal authentication, if the user leaves the computer, there may be others who occupy the computer and continue to access the network by using the account of the user in the time before the authentication device takes the user off line. This action causes the authentication device to continuously monitor the computer's internet traffic, thereby not taking the user offline.
Disclosure of Invention
The application provides a user offline detection method and device, which are used for determining user offline by detecting a USB Key pull-out event. The technical scheme provided by the application comprises the following steps:
in a first aspect, the present application provides a method for detecting a user offline, which is applied to a client, and includes:
when a USB Key insertion event is detected, accessing a Portal authentication page through a browser;
acquiring authentication information input by a user in the Portal authentication page; the authentication information at least includes: a user name and a password;
comparing whether the user name is consistent with the user name recorded by the USB Key, and if so, sending the authentication information to designated authentication equipment for authentication so that the user can access network resources when the authentication is passed;
and when the USB Key unplugging event is detected, sending an offline request to the authentication equipment to download the user.
In a second aspect, the present application provides a user offline detection device, applied to a client, including:
the access unit is used for accessing a Portal authentication page through a browser when a USB Key insertion event is detected;
the acquisition unit is used for acquiring the authentication information input by the user in the Portal authentication page; the authentication information at least includes: a user name and a password;
the authentication unit is used for comparing whether the user name is consistent with the user name recorded by the USB Key or not, and when the user name is consistent with the user name recorded by the USB Key, the authentication information is sent to the designated authentication equipment for authentication so that the user can access network resources when the user passes the authentication;
and the offline unit is used for sending an offline request to the authentication equipment to download the user when the USB Key is detected to be unplugged.
When the USB Key is detected to be inserted, a Portal authentication page is accessed, and when a user name contained in authentication information input by a user is consistent with a user name stored in the USB Key, the authentication information input by the user on the page is sent to authentication equipment to complete authentication; when the USB Key is detected to be pulled out, the user is offline by sending an offline request to the authentication equipment, so that the user can be identified to be offline in time, and the authentication equipment can timely and quickly offline the user. The problem that the client used by the user is occupied by others and the user continues to use the account to access the network due to the fact that the authentication equipment needs a certain time to take the user off line is solved.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure.
FIG. 1 is a schematic diagram of a Portal authentication architecture provided by an embodiment of the present application;
FIG. 2 is a flowchart of Portal authentication provided by an embodiment of the present application;
FIG. 3 is a flowchart of a user offline detection method provided in the present application;
FIG. 4 is a flowchart illustrating an implementation of step 301 provided in an embodiment of the present application;
fig. 5 is a schematic structural diagram of a user offline detection device provided in the present application;
fig. 6 is a schematic structural diagram of another offline detection device for a user according to the present application;
fig. 7 is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present application.
Detailed Description
The terminology used in the description herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the description. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information, without departing from the scope of the present specification. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
Portal authentication belongs to Web authentication and is a common authentication mode. Portal authentication architectures typically include at least a client and an authentication device, with some Portal authentication architectures also including other devices such as an authentication server. The relationship among the client, the authentication device and the authentication server can be seen in fig. 1. The authentication server is mainly responsible for authenticating the authentication information sent by the authentication equipment, the functions of the authentication server and the authentication equipment are overlapped to a certain extent, and the authentication server is not arranged in part of the Portal authentication system, so the authentication server is omitted in the following description.
The process of performing Portal authentication through the Portal authentication system can be referred to as a flow chart shown in fig. 2, and fig. 2 is a flow chart of Portal authentication provided in the embodiment of the present application. When a user accesses to any website through a client, for example, after receiving an access request for the website sent by the client, the authentication device checks whether the client passes Portal authentication.
If the authentication device checks that the client is not authenticated by Portal, the authentication device sends a Portal authentication page to the client. The user inputs authentication information such as a user name and a password in the authentication page and then sends the authentication information to the authentication device. The authentication device authenticates the received authentication information, and if the authentication result is successful, the user can access the network resource through the client. The authentication device also sends the authentication result to the client, so that the user can know the authentication result of the authentication.
Besides receiving the Portal authentication page sent by the authentication device to perform Portal authentication, when a user who does not pass Portal authentication wants to access the Internet, the user can also actively access the known Portal authentication page through the browser and input authentication information to perform authentication.
When a user needs to log off, the current common method for logging off the user is as follows: after the authentication information sent by the user through any client passes the authentication successfully, the authentication equipment records the relevant information of the client into a locally stored online list and monitors the internet traffic of the client. If the authentication equipment does not monitor the internet traffic of the client within a certain time, the authentication equipment considers that the user is offline, and therefore the user is offline.
This means that a certain time period elapses from when the user actually stops accessing the network resource to when the authentication device takes the user off-line, that is, the authentication device cannot timely detect the user's intention to take the user off-line. This makes it possible for the following problems to occur with this off-line user:
if a user uses a computer to access the internet, after the user wants to go offline and leave the computer, there may be others who occupy the computer to continue using the user's account to access the network. This may cause problems such as compromising the security of the account of the user, causing economic losses for the user due to the continuous billing of the authentication device, etc.
In order to solve the above problems, the present application provides a user offline detection method, which detects a user offline by detecting a USB Key pull-out event, so that an authentication device can timely take the user offline.
To make the objects, technical solutions and advantages of the present application more apparent, the present application will be described in detail with reference to the accompanying drawings and specific embodiments.
Referring to fig. 3, fig. 3 is a flowchart of a user offline detection method provided in the present application. In one embodiment, the flow may be applied to a client. As shown in fig. 3, the process includes:
The method provided by the application is realized by means of a USB Key. The USB Key is a hardware device with a USB interface, is internally provided with a single chip microcomputer or an intelligent card chip, has a certain storage space, can be used for storing a user private Key and a digital certificate, and can realize the authentication of the user identity by utilizing an algorithm internally arranged in the USB Key. As the user private Key stored in the USB Key can not be read by any mode theoretically, the safety of user authentication can be better ensured.
In this step 301, the client detects a USB Key insertion event in real time, as an embodiment, when detecting a USB Key insertion event, it can further determine whether the inserted USB Key is a USB Key for Portal authentication, and if so, access a Portal authentication page through a browser; if not, it is not processed, i.e., the Portal authentication page is not accessed through the browser.
In this embodiment, the USB Key for Portal authentication stores relevant information of Portal authentication, such as a user name.
In this embodiment, whether the USB Key is a USB Key for Portal authentication may be determined by a driver installed locally at the client for identifying the USB Key.
After the USB Key insertion event is detected, the user can be considered to need to carry out Portal authentication, so that the Portal authentication page can be accessed through the browser to carry out Portal authentication. In specific implementation, there are various implementation manners in which the step 301 accesses the Portal authentication page through the browser, and one of them is illustrated in fig. 4 below, which is not described herein again.
In one example, this step 301 may be applied to a service process pre-installed on a client.
For one embodiment, the service process may be configured to be started on, or manually by the user.
As an example, the service process may be a service process specifically tailored for implementing this step 301.
Step 301 above has accessed a Portal authentication page through the browser, through which authentication information entered by the user in the page can be obtained.
As an embodiment, the step 302 may be applied to a service process pre-installed on the client, and the service process may be a service process specifically customized for implementing the step 302.
In this embodiment, the service process may obtain the authentication information input by the user in the Portal authentication page by sending the received authentication information to the service process after the Portal authentication page receives the authentication information input by the user.
Typically, the authentication information for Portal authentication includes at least a username and password. If the password is a password set by the user when registering an account for Portal authentication, in order to further ensure the security of the account of the user, the authentication information input by the user in the Portal authentication page may further include a dynamic verification code, such as: short message verification code sent to user's handset, mailbox verification code sent to user's mailbox, voice verification code informing user by telephone mode, and verification code in various forms such as sliding verification code and jigsaw verification code.
In order to reduce the information that the user needs to memorize, the dynamic verification code can also be directly adopted to replace the password set when the user registers the account number for Portal authentication, and the dynamic verification code plays the same role as the password.
In addition, the authentication information for Portal authentication may also include other information, which is not listed here. The composition of the authentication information is not particularly limited in the present application.
And step 303, comparing whether the user name is consistent with the user name recorded by the USB Key, and if so, sending the authentication information to authentication equipment for authentication so that the user accesses network resources when the authentication is passed.
As an embodiment, the user name recorded in the USB Key may be obtained, and then the user name may be compared with the user name input by the user obtained in step 302.
In this embodiment, the user name recorded in the USB Key may be obtained immediately after detecting the USB Key insertion event, may be obtained after receiving the authentication information input by the user, or may be obtained at other times.
For the convenience of description, the process of comparing whether the user name input by the user is consistent with the user name recorded by the inserted USB Key is regarded as authentication. If the user name input by the user is consistent with the user name recorded in the USB Key after comparison, the user is determined to pass identity verification, and the currently inserted USB Key can be considered to belong to the user, so that the authentication information input by the user in a Portal authentication page can be sent to authentication equipment for authentication.
To facilitate the understanding of this step 303, a simple example is given below:
assuming that the user name included in the authentication information input by the user is admin1 and the user name recorded in the USB Key is admin1, it can be determined through this step 303 that the user name input by the user is consistent with the user name recorded in the USB Key, and the authentication information input by the user is continuously sent to the authentication device for authentication.
At present, after a client receives authentication information input by a user on a Portal authentication page, the client usually directly sends the authentication information to authentication equipment for authentication. If the authentication information of the user, such as a user name, a password and the like, is leaked, other people can log in by using the authentication information of the user, and since the accounting process of Portal authentication is usually performed based on the authentication information at present, the use of the authentication information of the user by other people is likely to cause economic loss of the user.
Through this step 303, when the user name in the authentication information input by the user is consistent with the user name recorded in the inserted USB Key, the client sends the authentication information input by the user to the authentication device for authentication.
This means that even if the authentication information of the user is acquired by another person, the other person cannot pass the authentication in step 303 because the other person does not have the USB Key in which the user name is recorded, so that the client does not transmit the input authentication information to the authentication device for authentication, and therefore the other person cannot perform Portal authentication using the authentication information of the user. Therefore, compared with the prior art, the step 303 further ensures that the authentication information of the user is not used for Portal authentication by others.
As an embodiment, this step 303 may be applied to a service process pre-installed on the client, and the service process may be a service process specifically customized for implementing this step 303.
In this embodiment, when it is determined that the user name input by the user is consistent with the user name recorded by the currently inserted USB Key, the service process may send the authentication information input by the user to the authentication device.
In this embodiment, when it is determined that the user name input by the user is consistent with the user name recorded by the currently inserted USB Key, the service process may also notify the browser to send the authentication information input by the user to the authentication device according to this result.
As an embodiment, if the user name contained in the authentication information input by the user acquired in step 302 is not consistent with the user name recorded in the inserted USB Key, the following steps may be further performed:
and outputting prompt information to the user to prompt that the user name input by the user is inconsistent with the user name recorded in the currently inserted USB Key.
For example, if the user name included in the authentication information input by the user is admin1 and the user name recorded in the currently inserted USB Key is admin66, it can be determined in this step 303 that the user name input by the user is not consistent with the user name recorded in the USB Key, and thus it is determined that the user has not passed authentication, and it is considered that the USB Key does not belong to the user, and therefore the authentication information input by the user is not sent to the authentication device for authentication, and prompt information is output to the user.
The content of the prompt message in this embodiment may be: "authentication failure: the information input by the user is not matched with the information in the USB Key, and the like can prompt the user that the user name input by the user is inconsistent with the user name recorded by the inserted USB Key.
As an embodiment, after determining that the user name included in the authentication information input by the user is inconsistent with the user name recorded in the inserted USB Key, the browser may be notified to clear the authentication information input by the user in the Portal authentication page so that the user may re-input the authentication information.
As an example, after sending the authentication information to the authentication device, the authentication result sent by the authentication device is typically received. If the authentication result is successful, it can be determined that the user passes Portal authentication and can access network resources, and step 304 can be continued on the basis.
If the received authentication result is an authentication failure, i.e., the user is not authenticated by Portal, then step 304 may not be necessary.
In this embodiment, if the authentication result sent by the authentication device is received by the service process, after receiving the authentication result, the service process may send the authentication result to the authentication page, so that the authentication page displays the authentication result.
And step 304, when the USB Key unplugging event is detected, sending an offline request to the authentication equipment to download the user.
In actual application, when the user wants to stop accessing the network, the USB Key can be directly pulled out, so this step 304 determines that the user is actually offline through the USB Key pulling event, and sends an offline request to the authentication device to take the user offline.
As an embodiment, this step 304 is executed in the case where the authentication information transmitted to the authentication device in the above step 303 is successfully authenticated, that is, the authentication success information transmitted by the authentication device is received. If the authentication information sent to the authentication device in step 303 is not successfully authenticated, that is, the authentication failure information sent by the authentication device is received, it is not necessary to detect the USB Key removal event.
As there may be a situation that the user actually stops accessing the network or actually leaves the client and forgets to pull out the USB Key, as an embodiment, the internet traffic of the client can be monitored when the user authentication passes; if the internet traffic of the client is zero within the preset time, an offline request can be sent to the authentication device to download the user.
The embodiment may also be executed when the USB Key removal event is not detected, that is, after the internet traffic of the client is determined to be zero within the preset time, if the USB Key removal event is not detected before, the embodiment sends an offline request to the authentication device to download the user.
The flow shown in fig. 3 is completed.
As can be seen from the flow shown in fig. 3, in the present application, when a USB Key insertion event is detected, a Portal authentication page is accessed, and whether to send authentication information input by a user to an authentication device to complete authentication is determined according to authentication information input by the user on the page and a user name recorded in the USB Key; and under the condition that the authentication information is sent to the authentication equipment and passes the authentication of the authentication equipment, when a USB Key pull-out event is detected, determining that the user is offline in time, and sending an offline request to the authentication equipment to offline the user.
Therefore, the method and the device realize timely detection of the user offline and enable the authentication device to timely take the user offline, and avoid the problem that a certain time is required from the time when the user actually stops accessing the network resources to the time when the user is offline by the authentication device, so that other people possibly occupy the client side of the user in the online state to perform network access.
In one example, the flow shown in FIG. 3 may be applied to a service process pre-installed on a client.
As an embodiment, the service process pre-installed on the client may be one, that is, the complete flow shown in fig. 3 is executed by the one service process;
as another embodiment, there may be a plurality of service processes pre-installed on the client, each service process at least completes one step in the flow shown in fig. 3, and the complete flow shown in fig. 3 is implemented through information interaction between the service processes.
For example, the service process for executing step 301 may notify the service process for executing step 302 to start executing step 302 after step 301 is executed, that is, after the USBKey insertion event is detected and the Portal authentication page is accessed through the browser, and so on.
The specific setting and installation manner of the service process is not particularly limited in this application.
How the above step 301 is accessed through a browser to a Portal authentication page is described below:
in one embodiment, the client pre-stores the URL of the Portal authentication page, which can be used to access the Portal authentication page through the browser. Referring to fig. 4, fig. 4 is a flowchart illustrating implementation of step 301 provided in an embodiment of the present application. As shown in fig. 4, the process may include the following steps:
Since a client can usually install a plurality of browsers, as an embodiment, one browser can be pre-designated for accessing the Portal authentication page, and when checking whether the browser is started through the present step 401, it can be directly checked whether the pre-designated browser for accessing the Portal authentication page is started.
As another embodiment, it may be checked whether any browser installed by the client has been launched, and if there is a launched browser, it is determined that the browser has been launched.
The client pre-stores the URL of the Portal authentication page, which may be stored in the browser as one embodiment. When the URL needs to be accessed through the browser, the browser directly accesses the URL stored by the browser.
If the above step 301 is applied to a service process pre-installed on a client, when the URL of the Portal authentication page needs to be accessed through the browser, an access command may be sent by the service process to the browser to make the browser access the URL.
This step is executed when the browser is not started in the above step 401. If a browser is pre-designated for accessing the Portal authentication page, then this step 403 may, as one embodiment, access the pre-designated browser directly and access the URL via the browser.
As another example, if there is no browser designated in advance for accessing the Portal authentication page, a browser is selected from the browsers installed at the client side to be started, and the URL is accessed through the browser.
The flow shown in fig. 4 is completed.
The process shown in fig. 4 realizes the access to the Portal authentication page by accessing the URL in which the Portal authentication page is stored in advance through the browser.
If the client does not store the URL of the Portal authentication page in advance, in another embodiment, any known URL that requires a connection to a network access may be accessed through the browser. Since the user is not authenticated by Portal at this time, the authentication device returns a Portal authentication page to the user, so that the Portal authentication page can be accessed through the browser.
To facilitate understanding of the present embodiment, a simple example is given below.
When a USB Key insertion event is detected, the browser can access any known URL that needs to be accessed to the network, such as: http:// www.baidu.com.
Since the user is not authenticated by Portal at this time, the authentication device, upon receiving an access request to the URL, checks to determine that the user is not authenticated by Portal and therefore sends a Portal authentication page to it. And the browser receives the Portal authentication page sent by the authentication equipment, thereby realizing the access to the Portal authentication page.
This completes the description of how step 301 accesses the Portal authentication page through the browser.
The method provided by the present application is described above, and the device provided by the present application is described below:
referring to fig. 5, fig. 5 is a schematic structural diagram of a user offline detection device provided in the present application. In one embodiment, the apparatus is applicable to a client. As shown in fig. 5, the apparatus includes an accessing unit 501, an acquiring unit 502, an authenticating unit 503, and a downline unit 504.
In one example, the accessing unit 501 is configured to, when detecting a USB Key insertion event, access a Portal authentication page through a browser;
an obtaining unit 502, configured to obtain authentication information input by a user in the Portal authentication page; the authentication information at least includes: a user name and a password;
an authentication unit 503, configured to compare whether the user name is consistent with the user name recorded by the USB Key, and if so, send the authentication information to an authentication device for authentication, so that the user accesses a network resource when the authentication is passed;
and the offline unit 504 is configured to send an offline request to the authentication device to download the user when the USB Key unplugging event is detected.
As an embodiment, the apparatus is implemented based on a service process, and the specified service process is installed in the client in advance.
As an embodiment, the client stores a URL of a Portal authentication page in advance, and the access unit 501 is specifically configured to:
checking whether a browser is started, if so, directly accessing the URL through the browser;
if not, the browser is started and the URL is accessed through the browser.
As an example, referring to fig. 6, the apparatus further includes:
and a prompting unit 505, configured to output a prompting message to the user to prompt that the user identity authentication fails when the user name is inconsistent with the user name recorded by the USB Key.
As an embodiment, the apparatus further comprises:
a detecting unit 506, configured to monitor internet traffic of the device when the user authentication passes;
a second offline unit 507, configured to send an offline request to the authentication device to offline the user if the internet traffic of the device is zero within a preset time.
It should be understood that the prompting unit 505 and the detecting unit 506 may be configured in the apparatus at the same time as shown in fig. 6 or separately as two independent modules, and therefore the structure shown in fig. 6 should not be construed as a limitation to the embodiments described in this specification.
The implementation process of the functions and actions of the modules in the apparatus is specifically described in the implementation process of the corresponding steps in the method, and is not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the components shown as modules may or may not be physical modules, may be located in one place, or may be distributed over a plurality of network modules. The modules can be selected according to actual needs to achieve the purpose of the scheme in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.
Referring to fig. 7, fig. 7 is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present disclosure. The electronic device may include a processor 701, a memory 702, and a communication bus 703. The processor 701 and the memory 702 communicate with each other via a communication bus 703. Wherein, the memory 702 stores a computer program; the processor 701 may perform the user offline detection method described above by executing the program stored on the memory 702.
The memory 702 referred to herein may be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and the like. For example, the memory 702 may be: RAM (random access memory), volatile memory, non-volatile memory, flash memory, a storage drive (e.g., a hard drive), a solid state drive, any type of storage disk (e.g., an optical disk, dvd, etc.), or similar storage medium, or a combination thereof.
Embodiments of the present application also provide a machine-readable storage medium, such as the memory 702 in fig. 7, storing a computer program, which can be executed by the processor 701 in the electronic device shown in fig. 7 to implement the offline user detection method described above.
For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functionality of the units may be implemented in one or more software and/or hardware when implementing the present application.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.
Claims (10)
1. A user offline detection method is applied to a client, and the method comprises the following steps:
when a USB Key insertion event is detected, accessing a Portal authentication page through a browser;
acquiring authentication information input by a user in the Portal authentication page; the authentication information includes at least: a user name and a password;
comparing whether the user name is consistent with the user name recorded by the USB Key, and if so, sending the authentication information to authentication equipment for authentication so that the user can access network resources when the user passes the authentication;
and when the USB Key pulling event is detected, sending a offline request to the authentication equipment to download the user.
2. The method of claim 1, wherein the method is applied to a service process preinstalled on the client.
3. The method of claim 1, wherein the client pre-stores the URL of a Portal authentication page, and wherein accessing the Portal authentication page via a browser comprises:
checking whether a browser is started or not, and if so, directly accessing the URL through the browser;
if not, starting the browser and accessing the URL through the browser.
4. The method according to claim 1, wherein if the user name is not consistent with the user name recorded by the USB Key, the method further comprises:
and outputting prompt information to the user to prompt the user that the user name is inconsistent with the user name recorded in the USB Key.
5. The method of claim 1, further comprising:
monitoring the internet access flow of the equipment under the condition that the user authentication is passed;
and if the internet flow of the equipment is zero within the preset time, sending an offline request to the authentication equipment to download the user.
6. A user offline detection device is applied to a client, and comprises:
the access unit is used for accessing a Portal authentication page through a browser when a USB Key insertion event is detected;
the acquisition unit is used for acquiring the authentication information input by the user in the Portal authentication page; the authentication information includes at least: a user name and a password;
the authentication unit is used for comparing whether the user name is consistent with the user name recorded by the USB Key or not, and when the user name is consistent with the user name recorded by the USB Key, the authentication information is sent to authentication equipment for authentication so that the user can access network resources when the user passes the authentication;
and the offline unit is used for sending an offline request to the authentication equipment to download the user when the USB Key is detected to be unplugged.
7. The apparatus according to claim 6, wherein the apparatus is implemented based on a service process, and the service process is pre-installed in the client.
8. The apparatus of claim 6, wherein the client pre-stores the URL of a Portal authentication page, and the accessing unit accesses the Portal authentication page through a browser, comprising:
checking whether a browser is started or not, and if so, directly accessing the URL through the browser;
if not, starting the browser and accessing the URL through the browser.
9. The apparatus of claim 6, further comprising:
and the prompting unit is used for outputting prompting information to the user when the user name is inconsistent with the user name recorded by the USB Key so as to prompt the user that the user name is inconsistent with the user name recorded in the USB Key.
10. The apparatus of claim 6, further comprising:
the detection unit is used for monitoring the internet access flow of the equipment under the condition that the user authentication passes;
and the second offline unit is used for sending an offline request to the authentication equipment to download the user if the internet surfing flow of the equipment is zero within the preset time.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911394775.0A CN111181961A (en) | 2019-12-30 | 2019-12-30 | User offline detection method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911394775.0A CN111181961A (en) | 2019-12-30 | 2019-12-30 | User offline detection method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111181961A true CN111181961A (en) | 2020-05-19 |
Family
ID=70650598
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911394775.0A Pending CN111181961A (en) | 2019-12-30 | 2019-12-30 | User offline detection method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111181961A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111866029A (en) * | 2020-08-20 | 2020-10-30 | 杭州迪普科技股份有限公司 | Access server authentication offline method and system |
| CN112580017A (en) * | 2020-12-25 | 2021-03-30 | 深信服科技股份有限公司 | Authentication method and device, electronic equipment and storage medium |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1571366A (en) * | 2003-07-23 | 2005-01-26 | 华为技术有限公司 | Method for monitoring user connection state |
| CN1925401A (en) * | 2006-10-12 | 2007-03-07 | 中国网通（集团）有限公司北京市分公司 | Internet access system and method |
| CN102148838A (en) * | 2011-05-12 | 2011-08-10 | 福建星网锐捷网络有限公司 | Web authentication method, network equipment and Web authentication system |
| US20130305327A1 (en) * | 2011-01-17 | 2013-11-14 | Tencent Technology (Shenzhen) Company Limited | Method and apparatus to assist user input based on a mobile terminal browser |
| CN103634792A (en) * | 2012-08-27 | 2014-03-12 | 中国移动通信集团公司 | Method, device and system for monitoring WLAN network user state and client |
| CN104796261A (en) * | 2015-04-16 | 2015-07-22 | 长安大学 | Secure access control system and method for network terminal nodes |
| CN108259457A (en) * | 2017-09-27 | 2018-07-06 | 新华三技术有限公司 | A kind of WEB authentication methods and device |
| CN109327468A (en) * | 2018-11-22 | 2019-02-12 | 杭州迪普科技股份有限公司 | A kind of offline reminding method, device, equipment and storage medium |
| CN110166471A (en) * | 2019-05-28 | 2019-08-23 | 杭州迪普科技股份有限公司 | A kind of portal authentication method and device |
-
2019
- 2019-12-30 CN CN201911394775.0A patent/CN111181961A/en active Pending
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1571366A (en) * | 2003-07-23 | 2005-01-26 | 华为技术有限公司 | Method for monitoring user connection state |
| CN1925401A (en) * | 2006-10-12 | 2007-03-07 | 中国网通（集团）有限公司北京市分公司 | Internet access system and method |
| US20130305327A1 (en) * | 2011-01-17 | 2013-11-14 | Tencent Technology (Shenzhen) Company Limited | Method and apparatus to assist user input based on a mobile terminal browser |
| CN102148838A (en) * | 2011-05-12 | 2011-08-10 | 福建星网锐捷网络有限公司 | Web authentication method, network equipment and Web authentication system |
| CN103634792A (en) * | 2012-08-27 | 2014-03-12 | 中国移动通信集团公司 | Method, device and system for monitoring WLAN network user state and client |
| CN104796261A (en) * | 2015-04-16 | 2015-07-22 | 长安大学 | Secure access control system and method for network terminal nodes |
| CN108259457A (en) * | 2017-09-27 | 2018-07-06 | 新华三技术有限公司 | A kind of WEB authentication methods and device |
| CN109327468A (en) * | 2018-11-22 | 2019-02-12 | 杭州迪普科技股份有限公司 | A kind of offline reminding method, device, equipment and storage medium |
| CN110166471A (en) * | 2019-05-28 | 2019-08-23 | 杭州迪普科技股份有限公司 | A kind of portal authentication method and device |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111866029A (en) * | 2020-08-20 | 2020-10-30 | 杭州迪普科技股份有限公司 | Access server authentication offline method and system |
| CN112580017A (en) * | 2020-12-25 | 2021-03-30 | 深信服科技股份有限公司 | Authentication method and device, electronic equipment and storage medium |
| CN112580017B (en) * | 2020-12-25 | 2023-12-29 | 深信服科技股份有限公司 | Authentication method and device, electronic equipment and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11765177B1 (en) | System and method for providing a web service using a mobile device capturing dual images | |
| CN106779716B (en) | Authentication method, device and system based on block chain account address | |
| CN105591743B (en) | Method and device for identity authentication through equipment operation characteristics of user terminal | |
| US10212151B2 (en) | Method for operating a designated service, service unlocking method, and terminal | |
| US10511592B1 (en) | System and method for authenticating a user via a mobile device to provide a web service on a different computer system | |
| CN105337997B (en) | Login method of application client and related equipment | |
| US9680644B2 (en) | User authentication system and methods | |
| CN106161348B (en) | Single sign-on method, system and terminal | |
| WO2014166362A1 (en) | Method, server, client and system for verifying verification codes | |
| CN110690972B (en) | Token authentication method and device, electronic equipment and storage medium | |
| KR20130107188A (en) | Server and method for authentication using sound code | |
| CN105429943B (en) | Information processing method and terminal thereof | |
| CN108877098B (en) | Cardless withdrawal method, device, system, storage medium and electronic equipment | |
| CN108650098B (en) | Method and device for user-defined verification mode | |
| CN110247898B (en) | Identity verification method, identity verification device, identity verification medium and electronic equipment | |
| KR20220019834A (en) | Method and system for authenticating transmission of secure credentials to a device | |
| US11777942B2 (en) | Transfer of trust between authentication devices | |
| CN111181961A (en) | User offline detection method and device | |
| CN113672897A (en) | Data communication method, device, electronic equipment and storage medium | |
| CN109829321B (en) | Method, device, equipment and storage medium for authenticating identity | |
| CN110971609A (en) | Anti-cloning method of DRM client certificate, storage medium and electronic equipment | |
| CN113761509B (en) | iframe verification login method and device | |
| CN106533685B (en) | Identity authentication method, device and system | |
| CN103716366A (en) | Cloud computing server access system and access method | |
| CN105071993B (en) | Encrypted state detection method and system |
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 | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200519 |
|
| RJ01 | Rejection of invention patent application after publication |