CN111245803B - Method for acquiring MAC address of computer equipment through browser - Google Patents
Method for acquiring MAC address of computer equipment through browser Download PDFInfo
- Publication number
- CN111245803B CN111245803B CN202010009749.8A CN202010009749A CN111245803B CN 111245803 B CN111245803 B CN 111245803B CN 202010009749 A CN202010009749 A CN 202010009749A CN 111245803 B CN111245803 B CN 111245803B
- Authority
- CN
- China
- Prior art keywords
- proxy
- mac address
- message
- data
- browser
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/142—Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
-
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- 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/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
-
- 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/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
- H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2101/00—Indexing scheme associated with group H04L61/00
- H04L2101/60—Types of network addresses
- H04L2101/618—Details of network addresses
- H04L2101/622—Layer-2 addresses, e.g. medium access control [MAC] addresses
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Power Engineering (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The invention relates to the technical field of Internet, in particular to a method for acquiring an MAC address of computer equipment through a browser. A method for obtaining a MAC address of a computer device through a browser. Compared with the prior art, the method for acquiring the MAC address of the computer equipment through the browser can conveniently and quickly acquire the MAC address of the computer where the current webpage is located, and can meet the requirement that a specific account number is limited to login on a special computer so as to protect the safety of the account number and the safety of system data.
Description
Technical Field
The invention relates to the technical field of Internet, in particular to a method for acquiring an MAC address of computer equipment through a browser.
Background
The data of the information system is valuable wealth of enterprises, the use safety of the information system in the enterprises is more and more important in enterprise internal control management, and how to ensure the access validity of the information system is one of the key points of enterprise information system design.
The method is an effective solution for binding the login equipment and the account number and establishing a corresponding authentication strategy on the basis of obtaining equipment and account number information, and along with popularization of a B/S (browser/server) architecture system, a scene that computer equipment accesses the system through a browser is common, and the requirement on how to obtain the MAC (media access control) address of the client computer equipment in the scene is very prominent.
Disclosure of Invention
The invention provides a method for acquiring the MAC address of the computer equipment through the browser, which can conveniently and quickly acquire the MAC address of the computer where the current webpage is located, and can solve the problem that a specific account number is limited to login on a special computer so as to protect the safety of the account number and the safety of system data.
In order to achieve the above object, a method for obtaining a MAC address of a computer device through a browser is provided, which includes: the method comprises the following steps:
(1) acquiring a Proxy installation package, installing and operating the Proxy, wherein an open designated port of the Proxy receives WebSocket connection and receives a message in a specific format sent by the WebSocket;
(2) entering a browser, opening a specific webpage by a user, and inputting and submitting login information;
(3) after the information is submitted to the WebServer, the WebServer searches the information of the MAC address corresponding to the Token sent back by the Proxy in the previous step according to the Token and judges whether the login request needs to be rejected;
(4) the WebServer receives a request sent by the Proxy, and verifies the validity of data firstly after encrypting a message by using an RSA public key in the Proxy; if the data is valid, storing the related data information of the MAC address corresponding to the Token on the Redis, storing the related data information on the Redis in a Hash mode, setting the validity period of the data, and automatically deleting the data after the specified time; if the data is invalid, returning to the step (2);
(5) after receiving the response of the WebServer, the Proxy can directly transmit or analyze the conversion message and send the conversion message to the browser through the previously established Websocket;
(6) after receiving a login request, the WebServer on the browser firstly verifies the validity of data, if the data is valid, the WebServer calls an MAC address authorization management module to decide whether a user can log in, if the data is rejected, the login fails, and a prompt is given; if the login is successful, returning Authorization information, prompting that the login is successful and guiding the page to jump; otherwise, the login fails, and the step (2) is returned;
(7) after the login verification processing is completed, the MAC address information corresponding to the Token is deleted, that is, one Token corresponds to only one verification process.
The specific webpage is characterized in that after loading is finished, the specific webpage needs to be connected with a local Proxy through a WebSocket, a specified message which can be identified by the Proxy is sent, data returned by the Proxy is waited, and the returned data determines which functions on the webpage can be used or determines which buttons or functions can be used.
The message capable of being identified by the Proxy comprises the following identification: identification number, version: version number, Token: the page loads the session identification number brought from the server, time _ stamp: and sending the timestamp of the message, wherein the data format of the timestamp is JSON.
The Proxy is software locally installed on computer equipment, has the characteristics of non-decompilation and difficult cracking, and has the capabilities of acquiring a local machine MAC address, concurrently receiving a WebSocket request, processing a received message, encrypting and sending the message to a WebServer, and synchronously responding information to a browser connected through the WebSocket.
After receiving WebSocket response, the browser submits login information, wherein the submitted information comprises userName: user name, Password: password, Token: token and verification code sent to Proxy.
Compared with the prior art, the method for acquiring the MAC address of the computer equipment through the browser can conveniently and quickly acquire the MAC address of the computer where the current webpage is located, and can meet the requirement that a specific account number is limited to login on a special computer so as to protect the safety of the account number and the safety of system data.
Drawings
FIG. 1 is a timing diagram of the present invention.
Detailed Description
The invention is further illustrated below with reference to the accompanying drawings.
A method for acquiring a MAC address of a computer device through a browser comprises the following steps:
(1) acquiring a Proxy installation package, installing and operating the Proxy, wherein an open designated port of the Proxy receives WebSocket connection and receives a message in a specific format sent by the WebSocket;
(2) entering a browser, opening a specific webpage by a user, and inputting and submitting login information;
(3) after the information is submitted to the WebServer, the WebServer searches the information of the MAC address corresponding to the Token sent back by the Proxy in the previous step according to the Token and judges whether the login request needs to be rejected;
(4) the WebServer receives a request sent by the Proxy, and verifies the validity of data firstly after encrypting a message by using an RSA public key in the Proxy; if the data is valid, storing the related data information of the MAC address corresponding to the Token on the Redis, storing the related data information on the Redis in a Hash mode, setting the validity period of the data, and automatically deleting the data after the specified time; if the data is invalid, returning to the step (2);
(5) after receiving the response of the WebServer, the Proxy can directly transmit or analyze the conversion message and send the conversion message to the browser through the previously established Websocket;
(6) after receiving a login request, the WebServer on the browser firstly verifies the validity of data, if the data is valid, the WebServer calls an MAC address authorization management module to decide whether a user can log in, if the data is rejected, the login fails, and a prompt is given; if the login is successful, returning Authorization information, prompting that the login is successful and guiding the page to jump; otherwise, the login fails, and the step (2) is returned;
(7) after the login verification processing is completed, the MAC address information corresponding to the Token is deleted, that is, one Token corresponds to only one verification process.
The specific webpage is characterized in that after loading is finished, the specific webpage needs to be connected with a local Proxy through a WebSocket, a specified message which can be identified by the Proxy is sent, data returned by the Proxy is waited, wherein the returned data determines which functions on the webpage can be used, or determines which buttons or functions can be used.
The message capable of being identified by the Proxy comprises the following identification: identification number, version: version number, Token: the page loads the session identification number brought from the server, time _ stamp: and sending the timestamp of the message, wherein the data format of the timestamp is JSON.
The Proxy is software locally installed in computer equipment, has the characteristics of non-decompilation and difficult cracking, and has the capabilities of acquiring a local machine MAC address, concurrently receiving a WebSocket request, processing a received message, encrypting and sending the message to a WebServer, and synchronously responding information to a browser connected through the WebSocket.
After receiving the WebSocket response, the browser submits login information, wherein the submitted information comprises userName: user name, Password: password, Token: token and verification code sent to Proxy,
as shown in fig. 1, the method for acquiring the MAC address of the computer where the browser of the web page is located specifically includes the following steps.
Firstly, (steps 1 and 1.1 in the sequence diagram) inputting a website in a browser, and opening a login page: the login page contains the following main contents: user name, password, identifying code, hidden field Token.
And secondly, (step 2) in the sequence diagram), after the page is loaded, automatically running a script (JS or TS) on the page, and connecting a local Proxy by using WebSocket (the Proxy program needs to be installed on the local machine firstly). After the connection is successful, a message is sent to the Proxy, the message format is JSON, and the example is as follows:
{"identified":"0xFF22DD",
"version":"1.0",
"Token":"847487393FS02FA",
"url":"/login",
"time_stamp":11113322}。
identified: to mark the identity of the requestor for Proxy identification.
Version: refers to the interactive version number with Proxy, which will verify if its version number is consistent with the version number. If not, the failure request is answered.
Token: and hiding Token carried by the domain for loading the login page.
url: is the address of the current requested page.
time _ stamp: and assembling the millisecond time stamp of the message, judging whether the message is overtime according to the field after the Proxy receives the request, and responding to the failure request if the message is overtime.
Here, the WebSocket of the browser should wait for the response for a timeout time, and if no response is received after timeout, it is considered that the request is abnormal, and the process should be restarted.
And thirdly, (step 2.1) verifying the timestamp information, judging whether the message is overtime, verifying whether the version numbers are matched and verifying whether the identified is identifiable, and if one is not consistent, failing to respond to the client. If the above verifications are passed, the processing of the request data is started, comprising the following steps:
and acquiring the MAC address of the machine, and sequencing and splicing the multiple MAC addresses in a dictionary sequence.
And acquiring the current time and converting the current time into a time stamp.
And assembling the data obtained in the two steps and the data obtained through the WebSocket into a message with a specific format.
And encrypting the message by using an RSA public key in the Proxy, then sending an HTTPS POST request to a specified WebServer, and waiting for the response of the WebServer.
Fourthly, (step 2.2.1 in the sequence diagram) the WebServer receives the request sent by the Proxy, and after using the RSA private key to decrypt the message, firstly verifies the validity of the data, including the following parts:
and verifying the validity of the time, comparing the message time with the WebServer time, and judging whether the time is overtime.
And verifying the validity of Token.
And verifying the validity of the MAC address format.
If the above conditions are met, storing the related data information of the MAC address corresponding to the Token to the Redis, storing the related data information on the Redis in a Hash mode, setting the validity period of the data, and automatically deleting the data after the specified time.
Five, (step 2.2.2 in the timing diagram): if there is an exception in the process, the status of resCode is not 0 needs to be acknowledged, and resMsg is required to be taken to describe the error message and possible resolution. If the processing is successful, the state that the resCode is 0 is replied, and a message is formed and sent to the Proxy.
In the process, Proxy has a response waiting timeout mechanism, if no response message is received within a specified time, the request processing is considered to be abnormal, and the server performs retry for a limited number of times, so that the server should consider the idempotent problem of Token data.
Sixth, (step 2.2.3 in the timing diagram): after receiving the response of the WebServer, the Proxy can directly transmit or analyze the conversion message and send the message to the browser through the previously established Websocket.
After the loading from the page is completed, the login button is in an unavailable state, a 2.2.3 response is waited to unlock the login button, and in the process from 2 to 2.2.3, the browser is executed asynchronously, that is, in the period, the user can operate the webpage, such as inputting a user name, a password and an authentication code, and then after the login button becomes available, the login button is clicked to submit data such as the user name and the password.
When a login button is available, as above, the user may submit login data for verification, which submitted data includes: user name, password, identifying code, Token and the like.
Seventhly, (step 3.1) 3.1 WebServer in the sequence diagram receives the login request, firstly verifies the data validity, and comprises the following aspects:
and verifying the validity period of Token.
And verifying whether the user name and the password are matched.
And searching whether the MAC address stored by the Redis exists according to the Token.
If one of the information is not satisfied, the login fails, and the user is prompted to log in again by answering or redirecting the page. If the verification is successful, calling the MAC address authorization management module, deciding whether the user can log in, if the user can not log in, failing to log in, and giving a prompt. If the login is successful, returning Authorization information, prompting that the login is successful and guiding the page to jump.
After the login verification process is completed, the MAC address information corresponding to the Token is deleted, that is, one Token corresponds to only one verification process.
In an embodiment, the Token is generated by WebServer, and its characteristic has system uniqueness, and in a session (session), its value is unique, and the lifecycle begins from the first visit of the opened browser to the specified website, i.e. the session begins, i.e. a new Token is generated. Token expires after a login is submitted (regardless of whether the login was successful or failed). Its Token runs through the process of one-time page interaction by the user, starting from the loading of the login page to the verification of the login submission server. And correlating the login request submitted by the user with the MAC address information sent back by the Proxy. The protocol for Token generation is: UUID, snowflake algorithm, etc., in a distributed environment, it may be considered to use the INCR of Redis to implement the globally unique sequence number obtained by atomic self-growth.
In the embodiment, the login page and the Proxy communicate through a WebSocket protocol, the Proxy and the WebServer use an HTTPS protocol, and the communication content uses an RSA asymmetric encryption mode. The decrypted secret key is only stored in the WebServer, so that the data security is ensured and the authentication data is prevented from being forged.
In the embodiment, the browser is responsible for releasing the connection after receiving the response message through the connection established by the WebSocket and the Proxy, and the Proxy forcibly releases the connection at the designated time after processing the response, so that the reliability of the session between the browser and the Proxy and the management of the Proxy on the life cycle of the connection resource are ensured.
In the embodiment, the message sent by the WebSocket to the Proxy contains identified ID, version negotiation information, Token: session id, time, etc. information generated by WebServer. Wherein, the identity is appointed by the identified;
in the interaction between the browser and the Proxy, the following abnormal conditions can be met:
and if the Proxy is not started, the WebSocket connection fails, and a guiding prompt is given in the webpage.
Version number negotiation is not correct, for example, the version of Proxy is too low, and the version of Proxy needs to be upgraded to solve the problem.
And if the message sent to the Proxy is overtime, the webpage performs retry operation resolution.
The Proxy response message contains processing result information, and key fields of the Proxy response message include a resCode: if the processing result code is nonzero, failure exists, if the processing result code fails, a resMsg field certainly exists, the failure reason is described, after messages are received through WebSocket in a webpage, if the messages are successful, certain functions are correspondingly unlocked or decision-making judgment is carried out, and if the messages fail, error prompt and guide operation are given.
In implementation, the problem of package sticking of WebSocket is solved, a JSON format is used for communication between a browser and a Proxy, JSON validity is verified after the Proxy receives data, if the JSON validity is invalid, the JSON validity is verified by considering the fact that a message waiting for receiving again, and the JSON validity is verified when JSON is valid once. When a connection is closed, all received data of the current connection is discarded.
In the embodiment, the Proxy acquires the MAC address of the user, the writing is recommended by using a go language, an API (application programming interface) under a net packet provided by a go system is used for acquiring a MAC address list of the system, and a plurality of MAC addresses need to be subjected to dictionary ordering and then spliced. Then the messages are assembled and encrypted for transmission. The Proxy and the WebServer are communicated in an HTTPS mode, so that the problem of packet sticking does not exist. The request uses a POST mode, and the encrypted content is stored in HTTP BODY. HTTP HEADER contains the basic information of the request, including byte Length Content Length field of the encrypted data.
In an embodiment, the encrypted transmission uses RSA asymmetric encryption, public key encryption, and private key decryption, the public key is included in the program and is only usable by the application, and the private key is only stored in the WebServer and is used to decrypt data sent by the Proxy.
In the embodiment, the WebServer reads data sent by the Proxy, decrypts the data, verifies the timeout time of the data and the validity of Token, and ensures the safety and the non-forgery of the data, after each request is constructed by the Proxy, the message is not received by the WebServer within a certain time or is received overtime, the message is regarded as an invalid message, namely the request is regarded as an invalid request, the Proxy is required to provide a limited retry mechanism, and after the retry is not successful, a response is sent to the browser, and the interaction flow is restarted. If the process is reinitiated, a new Token is generated.
In the embodiment, the WebServer stores data sent by the Proxy, in single-node deployment, a LocalCache mode is used, and in a cluster environment, data sharing needs to be considered, and Hash storage using Redis or a DB mode is needed to be considered to store and maintain the state of the data, so as to achieve multi-node data sharing.
In the embodiment, the Proxy returns the response to the browser through the WebSocket, if the message is processed successfully, the browser unlocks the submission button, the submitted data is verified at the WebServer, and verification items of the submitted data comprise a user name, a password and Token. If all the verifications are passed, the user login user name and password are correct, the MAC address has the login authority, the login authorization is carried out, otherwise, the login is failed, and the prompt of denial of service is given through response.
In the embodiment, after the login verification processing of the WebServer is completed, the life cycle corresponding to Token is ended. The WebServer deletes or marks invalid data (the Token corresponds to the MAC address related record).
In the embodiment, the Proxy is used as a Proxy service, processes the request and the forwarding request, processes the response and forwards the response, and uses an IO mode with the browser and the WebServer, so that the browser initiates a request once, needs a timeout mechanism, and needs to initiate the request again after timeout. Proxy and WebServer also need to have a timeout mechanism, if timeout occurs, Proxy retries for a limited number of times without reinitiating the flow.
Based on the above flow and interaction mechanism, the legality of the current user logging in the computer is verified, the problems of account authorization logging and account security are solved, and the security of system data is enhanced. Therefore, the MAC address of the computer where the current webpage is located is accurately obtained. At other requests, the Token verifies that the resource requested by the current user is authorized on the requesting computer.
Claims (5)
1. A method for obtaining a computer device MAC address through a browser is characterized in that: the method comprises the following steps:
(1) acquiring a Proxy installation package, installing and operating a Proxy, wherein an open designated port of the Proxy receives WebSocket connection and receives a message in a specific format sent by the WebSocket;
(2) entering a browser, and opening a specific webpage by a user;
(3) after the page is loaded, automatically running a script on the page and sending a message to a Proxy;
(4) the Proxy verifies the timestamp, the version number and the identification number identified in the received message, if the verification is passed, the Proxy encrypts the Token, the MAC address and the timestamp of the user PC by using an RSA public key and then sends a request to the WebServer;
(5) the WebServer receives a request sent by the Proxy, firstly verifies the validity of data after using an RSA private key to decrypt a message, and if the data is valid, stores relevant data information of an MAC address corresponding to Token to Redis and then responds to the Proxy;
(6) after receiving the response of the WebServer, the Proxy can directly transmit or analyze the conversion message, and sends the conversion message to the browser through the previously established WebSocket, and then the user inputs a username and a password to carry out login operation;
(7) after receiving a login request, the WebServer firstly verifies the validity of data, if the data is valid, the WebServer calls an MAC address authorization management module to decide whether a user can log in, and if the data is rejected, the login fails, and a prompt is given; if the login is successful, returning Authorization information, prompting that the login is successful and guiding the page to jump; otherwise, the login fails; after the login verification processing is completed, the MAC address information corresponding to the Token is deleted, that is, one Token corresponds to only one verification process.
2. The method for acquiring the MAC address of the computer device through the browser according to claim 1, wherein: after the loading of the specific webpage is finished, the specific webpage needs to be connected with a local Proxy through a WebSocket, a specified message which can be identified by the Proxy is sent, and data returned by the Proxy is waited, wherein the returned data determines which functions on the webpage can be used, or determines which buttons or functions can be used.
3. The method for acquiring the MAC address of the computer device through the browser according to claim 2, wherein: the message capable of being identified by the Proxy comprises the following identification: identification number, version: version number, Token: the page loads the session identification number brought from the server, time _ stamp: and sending the timestamp of the message, wherein the data format of the timestamp is JSON.
4. The method for acquiring the MAC address of the computer device through the browser according to claim 1, wherein: the Proxy is software locally installed on computer equipment, has the characteristics of non-decompilation and difficult cracking, and has the capabilities of acquiring a local machine MAC address, concurrently receiving a WebSocket request, processing a received message, encrypting and sending the message to a WebServer, and synchronously responding information to a browser connected through the WebSocket.
5. The method for acquiring the MAC address of the computer device through the browser according to claim 1, wherein: after receiving WebSocket response, the browser submits login information, wherein the submitted information comprises userName: user name, Password: password, Token: token and verification code sent to Proxy.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010009749.8A CN111245803B (en) | 2020-01-06 | 2020-01-06 | Method for acquiring MAC address of computer equipment through browser |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010009749.8A CN111245803B (en) | 2020-01-06 | 2020-01-06 | Method for acquiring MAC address of computer equipment through browser |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111245803A CN111245803A (en) | 2020-06-05 |
CN111245803B true CN111245803B (en) | 2021-12-07 |
Family
ID=70872297
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010009749.8A Active CN111245803B (en) | 2020-01-06 | 2020-01-06 | Method for acquiring MAC address of computer equipment through browser |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111245803B (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112887359B (en) * | 2020-12-31 | 2022-12-02 | 北京思特奇信息技术股份有限公司 | Cross-domain session sharing method and system |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103249045A (en) * | 2013-05-13 | 2013-08-14 | 华为技术有限公司 | Identification method, device and system |
US8893255B1 (en) * | 2013-10-23 | 2014-11-18 | Iboss, Inc. | Device authentication using device-specific proxy addresses |
CN104410622A (en) * | 2014-11-25 | 2015-03-11 | 珠海格力电器股份有限公司 | Security Authentication Method, Client and System for Logging in Web System |
CN104424411A (en) * | 2013-09-07 | 2015-03-18 | 镇江金软计算机科技有限责任公司 | B/S (Browser/Server) system login control method based on MAC (Media Access Control) address determination |
CN110336781A (en) * | 2019-05-09 | 2019-10-15 | 极智(上海)企业管理咨询有限公司 | A kind of method and apparatus based on browser identification terminal uniqueness |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9363256B2 (en) * | 2013-04-11 | 2016-06-07 | Mx Technologies, Inc. | User authentication in separate authentication channels |
CN106534158A (en) * | 2016-11-29 | 2017-03-22 | 努比亚技术有限公司 | Account login control device and method |
US20180241745A1 (en) * | 2017-02-20 | 2018-08-23 | Giovanni Laporta | Method and system for validating website login and online information processing |
-
2020
- 2020-01-06 CN CN202010009749.8A patent/CN111245803B/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103249045A (en) * | 2013-05-13 | 2013-08-14 | 华为技术有限公司 | Identification method, device and system |
CN104424411A (en) * | 2013-09-07 | 2015-03-18 | 镇江金软计算机科技有限责任公司 | B/S (Browser/Server) system login control method based on MAC (Media Access Control) address determination |
US8893255B1 (en) * | 2013-10-23 | 2014-11-18 | Iboss, Inc. | Device authentication using device-specific proxy addresses |
CN104410622A (en) * | 2014-11-25 | 2015-03-11 | 珠海格力电器股份有限公司 | Security Authentication Method, Client and System for Logging in Web System |
CN110336781A (en) * | 2019-05-09 | 2019-10-15 | 极智(上海)企业管理咨询有限公司 | A kind of method and apparatus based on browser identification terminal uniqueness |
Also Published As
Publication number | Publication date |
---|---|
CN111245803A (en) | 2020-06-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR100615793B1 (en) | Method and apparatus for serving content from a semi-trusted server | |
JP4886508B2 (en) | Method and system for stepping up to certificate-based authentication without interrupting existing SSL sessions | |
US8799639B2 (en) | Method and apparatus for converting authentication-tokens to facilitate interactions between applications | |
RU2332711C2 (en) | PROTECTED CLIENT SYSTEM MANDATE PROCESSING FOR ACCESSING Web-BASED RESOURCES | |
US6934848B1 (en) | Technique for handling subsequent user identification and password requests within a certificate-based host session | |
US6976164B1 (en) | Technique for handling subsequent user identification and password requests with identity change within a certificate-based host session | |
EP1654852B1 (en) | System and method for authenticating clients in a client-server environment | |
CN109547458B (en) | Login verification method and device, computer equipment and storage medium | |
US7665127B1 (en) | System and method for providing access to protected services | |
US8191123B2 (en) | Provisioning a network appliance | |
US8191122B2 (en) | Provisioning a network appliance | |
WO2020140407A1 (en) | Cloud security-based cloud desktop login method, device, equipment and storage medium | |
US9264420B2 (en) | Single sign-on for network applications | |
KR20190003764A (en) | Automatic login method and apparatus among a plurality of websites | |
US6874088B1 (en) | Secure remote servicing of a computer system over a computer network | |
US20140006781A1 (en) | Encapsulating the complexity of cryptographic authentication in black-boxes | |
CN1783052A (en) | Portable computing environment | |
WO2012120106A1 (en) | Method and system for granting access to a secured website | |
WO2010135883A1 (en) | File uploading realization method and system for web application | |
WO2006073008A1 (en) | Login-to-network-camera authentication system | |
JP2008152666A (en) | Authentication system, authentication control program, and authentication control method | |
JP4608929B2 (en) | Authentication system, server authentication program, and client authentication program | |
CN111245803B (en) | Method for acquiring MAC address of computer equipment through browser | |
CN112929388B (en) | Network identity cross-device application rapid authentication method and system, and user agent device | |
JP2011221729A (en) | Id linking 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 | ||
CB02 | Change of applicant information |
Address after: 201900 room 502A, building 2, No. 439, Shitai Road, Baoshan District, Shanghai Applicant after: Shanghai Fuli Technology Co., Ltd Address before: 201900 room 502A, building 2, No. 439, Shitai Road, Baoshan District, Shanghai Applicant before: SHANGHAI FULI FINANCIAL INFORMATION SERVICE Co.,Ltd. |
|
CB02 | Change of applicant information | ||
GR01 | Patent grant | ||
GR01 | Patent grant |