CN111245803B - Method for acquiring MAC address of computer equipment through browser - Google Patents

Method for acquiring MAC address of computer equipment through browser Download PDF

Info

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
Application number
CN202010009749.8A
Other languages
Chinese (zh)
Other versions
CN111245803A (en
Inventor
李潇
黎小波
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Fuli Technology Co Ltd
Original Assignee
Shanghai Fuli Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Shanghai Fuli Technology Co Ltd filed Critical Shanghai Fuli Technology Co Ltd
Priority to CN202010009749.8A priority Critical patent/CN111245803B/en
Publication of CN111245803A publication Critical patent/CN111245803A/en
Application granted granted Critical
Publication of CN111245803B publication Critical patent/CN111245803B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/142Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876Network 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/60Types of network addresses
    • H04L2101/618Details of network addresses
    • H04L2101/622Layer-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

Method for acquiring MAC address of computer equipment through browser
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.
CN202010009749.8A 2020-01-06 2020-01-06 Method for acquiring MAC address of computer equipment through browser Active CN111245803B (en)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

Patent Citations (5)

* Cited by examiner, † Cited by third party
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