CN111181908A - Login method, device and storage medium - Google Patents
Login method, device and storage medium Download PDFInfo
- Publication number
- CN111181908A CN111181908A CN201910718744.XA CN201910718744A CN111181908A CN 111181908 A CN111181908 A CN 111181908A CN 201910718744 A CN201910718744 A CN 201910718744A CN 111181908 A CN111181908 A CN 111181908A
- Authority
- CN
- China
- Prior art keywords
- login
- user
- information
- login request
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- 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/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The invention provides a login method, which comprises the following steps: receiving a login request containing user information; based on the fact that the local storage area does not store login information corresponding to the user information, a login request is sent to the developer server, and login is achieved based on the login request; and storing login information corresponding to the user information based on the local storage area, judging that the login state of the user is valid based on the login information, sending a login request carrying the login state to a server, and receiving feedback service data. In the scheme, in the terminal for running the applet, when the user is determined to be not logged in for the first time based on the login information corresponding to the locally stored user information, the business data is received after the fact that the login state is effective is judged based on the stored login information, a developer server does not need to request the applet server to obtain the user identity, and a small program interface does not need to be called to check the login state, so that the login mechanism is simplified, and the login efficiency is improved.
Description
Technical Field
The present invention relates to the field of software technologies, and in particular, to a login method, a login device, and a storage medium.
Background
The Mini Program is a light application Program, can be used without downloading and installing, does not occupy the memory of the mobile phone, can be opened by scanning or searching by a user, and can be directly quitted when not used. Generally need to be carried by the platform and cannot be independently run in the operating system.
In the prior art, a login mechanism of an applet needs to call a login interface of the applet, a developer server requests an applet server to acquire a user identity, and the applet interface needs to be called to check a login state when the login state is checked. The login mechanism is complex and relies on a small program interface.
Disclosure of Invention
In view of this, the present invention provides a login method, device and storage medium, so as to overcome the problems in the prior art that the login mechanism of a applet is complex and depends on an applet interface.
In order to achieve the purpose, the invention provides the following technical scheme:
a login method is applied to a terminal and comprises the following steps:
receiving a login request of a user, wherein the login request comprises user information;
judging whether a local storage area stores login information corresponding to the user information or not according to the user information of the login request to obtain a first judgment result;
representing that login information corresponding to the user information is not stored in a local storage area based on the first judgment result, and sending a login request to a developer server so as to log in based on the login request;
and representing that a local storage area stores login information corresponding to the user information based on the first judgment result, judging that the login state of the user is effective based on the login information, and receiving service data fed back by a developer server.
The embodiment of the invention also provides a login method, which is applied to the developer server and comprises the following steps:
receiving a login request sent by a terminal, wherein the terminal runs a preset applet and the login request comprises user information;
judging whether the user is recorded or not based on the login request to obtain a third judgment result;
and characterizing that the user is not recorded based on a third judgment result, generating a user unique identifier, and sending the user unique identifier and the expiration time to the terminal.
The embodiment of the invention also provides a login device, which is applied to a terminal and comprises:
the system comprises a first receiving module, a second receiving module and a third receiving module, wherein the first receiving module is used for receiving a login request of a user, and the login request comprises user information;
the storage module is used for storing login information;
the first judgment module is used for judging whether the local storage module stores login information corresponding to the user information according to the user information of the login request to obtain a first judgment result; representing that a local storage module stores login information corresponding to the user information based on the first judgment result, and triggering a processing module; characterizing that a local storage module does not store login information corresponding to the user information or the login state of the user is invalid based on the first judgment result, and triggering a first sending module;
the processing module is used for judging that the login state of the user is valid based on the login information and logging in according to the login information;
the first sending module is used for sending a login request to a developer server so as to log in based on the login request.
A login device applied to a developer server comprises:
the second receiving module is used for receiving a login request sent by a terminal, wherein the terminal runs a preset applet, and the login request comprises user information;
the second judgment module is used for judging whether the user is recorded or not based on the login request to obtain a third judgment result;
the identification module is used for representing the user which is not recorded based on a third judgment result and generating a unique user identification;
and the second sending module is used for sending the unique user identifier and the expiration time to the terminal.
As can be seen from the above technical solutions, compared with the prior art, the present invention provides a login method, including: receiving a login request of a user, wherein the login request comprises user information; judging whether a local storage area stores login information corresponding to the user information or not according to the user information of the login request to obtain a first judgment result; representing that login information corresponding to the user information is not stored in a local storage area based on the first judgment result, and sending a login request to a developer server so as to log in based on the login request; and representing that a local storage area stores login information corresponding to the user information based on the first judgment result, judging that the login state of the user is valid based on the login information, sending a login request carrying the login state to a server, and receiving service data fed back by a developer server. In the scheme, in a terminal for running the applet, whether a user carrying out a login request logs in for the first time or not is judged based on login information corresponding to locally stored user information, and when the user does not log in for the first time, after the fact that the login state is effective is judged based on the stored login information, business data fed back by a developer server is received, the developer server does not need to request the applet server to obtain the user identity, the business does not need to call an applet interface to check the login state, the login mechanism is simplified, and the login efficiency is improved.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
FIG. 1 is a login mechanism for an applet provided by the present invention;
fig. 2 is a schematic structural diagram of a login system according to an embodiment of the present invention;
fig. 3 is a flowchart of a login method according to an embodiment of the present invention;
FIG. 4 is a flowchart of a login method according to an embodiment of the present invention;
fig. 5 is another flowchart of a login method according to an embodiment of the present invention;
fig. 6 is a flowchart of a login method according to an embodiment of the present invention;
FIG. 7 is a simplified timing diagram of a login method provided by an embodiment of the present invention;
FIG. 8 is a block diagram of a login device according to an embodiment of the present invention;
fig. 9 is a block diagram of a hardware structure of a login apparatus according to an embodiment of the present invention;
fig. 10 is another block diagram of a login device according to an embodiment of the present invention;
fig. 11 is a block diagram of a hardware structure of a login apparatus according to an embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The login referred to in this application is typically a login applied to an applet, which may be, for example, an applet in a WeChat.
Fig. 1 is a schematic diagram of an applet login mechanism, in this example, the applet is described as a Wechat applet, the login mechanism involves an applet (miniprogam), a developer server (developer service), and a Wechat Http Api, and the specific steps are as follows: s01, the WeChat applet calls a login interface (wx. login ()) of the WeChat to obtain a code (code), wherein the code is a certificate which is specifically applied to the exchange of user information of the WeChat open platform; s02, sending code to developer server by WeChat applet wx.request (); s03, the developer server calls the WeChat interface service, the login certificate check interface includes: application software number, appsect (application secret, also called private key), code, and the like; s04, the WeChat interface service feeds back information, such as session _ key (session unique identifier), openid (user unique identifier allocated for the user), etc.; s05, the developer server self-defines the login state and associates with session _ key and openid; s06, the developer server returns the user-defined login state to the applet; s07, the small program stores the user-defined login state into storage; when the login request is received again, the following steps are executed: s08, wx. request () initiates a service request, carrying a user-defined login state; s09, the developer server inquires openid and session _ key through the user-defined login state; s10, the developer server returns the business data to the applet.
However, in this scheme, the applet login mechanism must call a login interface of the applet, the applet server is requested by the developer server to obtain the user identity, and the applet interface must be called to check the login state when checking the login state. The login mechanism is complex and relies on a small program interface.
Therefore, the invention provides a login method, which comprises the following steps: receiving a login request of a user, wherein the login request comprises user information; judging whether a local storage area stores login information corresponding to the user information or not according to the user information of the login request to obtain a first judgment result; representing that login information corresponding to the user information is not stored in a local storage area based on the first judgment result, and sending a login request to a developer server so as to log in based on the login request; and representing that a local storage area stores login information corresponding to the user information based on the first judgment result, judging that the login state of the user is valid based on the login information, sending a login request carrying the login state to a server, and receiving service data fed back by a developer server. In the scheme, in a terminal for running the applet, whether a user carrying out a login request logs in for the first time or not is judged based on login information corresponding to locally stored user information, and when the user does not log in for the first time, after the fact that the login state is effective is judged based on the stored login information, business data fed back by a developer server is received, the developer server does not need to request the applet server to obtain the user identity, the business does not need to call an applet interface to check the login state, the login mechanism is simplified, and the login efficiency is improved.
Fig. 2 is a schematic structural diagram of a login system according to an embodiment of the present invention, where a login method according to an embodiment of the present invention may be implemented by the login system; referring to fig. 2, the login system may include: a terminal 10 and a developer server 20.
The terminal 10 may be a mobile phone, a tablet computer, or the like, and is installed with software such as a WeChat capable of running an applet.
The developer server 20 has a function of communicating with a terminal via a network.
Based on the login system shown in fig. 2, fig. 3 shows a flowchart of a login method provided in an embodiment of the present invention, where the method may be applied to a terminal installed with an applet, and referring to fig. 3, the flowchart may include:
step S301, receiving a login request of a user, wherein the login request comprises user information;
the user requests to log in through the terminal and receives the login request of the user.
Specifically, the login request includes user information, where the user information may include an account number, a mailbox, a mobile phone number, and the like of the user.
In a specific implementation, if the applet login requires a login password, the user information may further include the login password.
The login request may be the first login or the second login performed by the user for the applet.
In specific implementation, if the user logs in again, the login request may also carry a login state and user information/user unique identifier, where the login state indicates that the user has logged in the applet and is in a login state.
Step S302, judging whether a local storage area stores login information corresponding to the user information or not according to the user information of the login request, and obtaining a first judgment result;
when the first login is completed, the information required for the login is stored in the storage area of the terminal.
In a specific implementation, the storage area may be a local storage of the terminal.
The local storage is a method for storing data by the terminal, and has no automatic expiration mechanism, and can provide permanent storage.
Specifically, when the user logs in for the first time, the local storage area does not store login information corresponding to the login request; when the user logs in for the first time, the local storage area stores login information stored during the first login.
Specifically, when the local storage area does not store the login information corresponding to the login request, step S303 is executed; otherwise, step S304 is performed.
Step S303, characterizing that the local storage area does not store login information corresponding to the user information based on the first determination result, and sending a login request to a developer server, so as to log in based on the login request.
When the login information corresponding to the login request is not stored in the local storage area, the login is determined to be the first login, and then the login request is sent to the developer server so as to realize login based on the login request.
Wherein, this step S303 specifically includes:
step S3031, sending the login request to a developer server;
step S3032, receiving a unique user identifier, expiration time and service data fed back by the developer server, wherein the unique user identifier is generated according to the login request;
in a specific implementation, the service data is the service data related to the applet, which is fed back by the developer server after the login is completed. Characterizing that the applet has been logged in based on receiving the traffic data.
The developer server is preset with expiration time, when receiving a login request, the developer server generates a user unique identifier for a user according to the login request, and feeds back the user unique identifier and the expiration time to the user, so that when subsequently carrying out the login request again, whether the user has logged in the applet before is judged based on the user unique identifier.
Specifically, the expiration time may be set by a developer, such as 1 day, 10 days, 90 days, and the like, and the specific time is not limited.
In specific implementation, the unique user identifier is information representing the identity of the user, has uniqueness, and can be a set of numbers and/or characters randomly generated by a developer server, or a set of information related to the applet according to the time when the login request is received and the terminal ID address.
Step S3033, establishing a login state based on the received user unique identifier;
and determining to establish a login state based on the received unique user identification.
Specifically, the expiration time of the login state represents a time length for which the login state can be maintained to be valid, and the set time is a time set in the login state, i.e., a start time.
It should be noted that the valid login state proposed in the subsequent step means that the login state is not expired and the user is in the login state; the login state is invalid, which means that the user is in an unregistered state after the login state is expired.
In a specific implementation, the login establishing state may include a user unique identifier fed back by the developer server.
Step S3034, saving the login state, the expiration time and the set time as login information to a local storage area, where the set time is the time when the unique user identifier is received.
The established login state, the received expiration time and the set time are used as login information and stored in the local storage of the terminal.
It should be noted that, since the local storage can provide a permanent storage, it can permanently store the login status, the expiration time and the setting time, and the storage time can be longer than the expiration time, so that the login status failure of the applet can be set by the developer according to the needs of the developer.
It should be noted that, in the scheme, a user request is customized based on a developer, a request does not need to be sent to a wechat service interface to obtain a wechat user identifier, the storage and expiration of the login state are completely defined by the developer according to the requirements of the developer, the storage and expiration of the login state are completely transparent and sensible to the developer, and the developer does not need to call the wechat interface to inquire whether the login state is valid or not.
Step S304, representing that a local storage area stores login information corresponding to the user information based on the first judgment result, judging that the login state of the user is valid based on the login information, sending a login request carrying the login state to a developer server, and receiving service data fed back by the developer server.
When the local storage area stores the login information corresponding to the login request, the login is determined to be non-initial login, and then the applet can be directly logged in.
In specific implementation, it is further necessary to determine whether the login state of the user is valid according to the login information, and when the login state is valid, directly login the applet and receive the service data fed back by the server.
Specifically, the determining whether the login state of the user is valid based on the login information specifically includes:
step S3041: judging whether the login state of the user is valid according to the time of receiving the login request and the set time and the expiration time in the login information;
step S3042: sending a login request to a developer server based on the validity of the login state of the user, wherein the login request comprises the login state;
step S3043: sending a login request to a developer server based on the login state failure of the user;
specifically, whether the login state of the user is in the validity period, that is, whether the login state of the user is valid is determined by calculating the difference between the time (time1) when the login request is received and the set time (time2) and comparing the difference with the expiration time (expires).
Specifically, if the time1-time2 is greater than expires, the login state is considered to be invalid, the user needs to log in again, and the step S3043 is executed; if the time1-time2 < expires, the login state is considered to be valid, and the login request carrying the login state can be directly sent to the developer server, and the step S3042 is executed.
Step S3044: determining whether the login state is valid based on information fed back by the developer server.
After receiving the login request, the developer server may further verify whether the user corresponding to the login request is the first login according to the information in the login request, and feed back different information according to different situations.
It should be noted that, regardless of whether the user logs in for the first time, the developer server may log in to the applet based on the login request sent by the terminal.
The feedback information may include service data, or a user unique identifier, an expiration time, and the like.
Step S3044, determining whether the login status is valid based on the information fed back by the developer server, including:
step S30441: analyzing the feedback information to obtain service data, and determining that the login state is effective when the developer server judges;
in specific implementation, the feedback information can be analyzed to obtain whether the feedback information is service data or a unique user identifier, expiration time, and the like.
Specifically, even if the login status of the user is locally determined to be valid at the terminal, in order to be more accurate, the developer server needs to further perform verification determination, and the developer server determines whether the login status is valid based on the login status in the login request received by the developer server.
Specifically, the developer server analyzes the login request to determine whether the user is recorded or not by analyzing the login state of the user corresponding to the request, and if so, calculates according to the corresponding expiration time, the time of receiving the login request and the time of generating the unique identifier of the user.
Step S30442: analyzing the feedback information to obtain a unique user identifier and expiration time, and determining that the login state is invalid by the developer server.
Wherein, the time for generating the user unique identifier and the setting time can adopt the same time.
Specifically, whether the login state of the user is in the validity period, that is, whether the login state of the user is valid is determined by calculating the difference between the time (time1) when the login request is received and the set time (time2) and comparing the difference with the expiration time (expires).
Specifically, if the time1-time2 is greater than expires, the login state is considered to be invalid, and the user needs to log in again, the user unique identifier and the expiration time are generated again based on the login request and fed back to the terminal, the login is performed based on the login request, and then the corresponding service data can be obtained and fed back to the terminal, and the step S30442 is executed; and if the time1-time2 is less than expires, the login state is considered to be valid, the corresponding service data can be directly acquired and fed back to the terminal, and the step S30443 is executed.
In the scheme, the network requests of the single client and the single server also reduce the links of the whole request, and the whole application performance is improved from the network request level.
The login method provided by the embodiment of the invention comprises the following steps: receiving a login request of a user, wherein the login request comprises user information; judging whether a local storage area stores login information corresponding to the user information or not according to the user information of the login request to obtain a first judgment result; representing that login information corresponding to the user information is not stored in a local storage area based on the first judgment result, and sending a login request to a developer server so as to log in based on the login request; and representing that a local storage area stores login information corresponding to the user information based on the first judgment result, judging that the login state of the user is valid based on the login information, and logging in based on the login information. In the scheme, in a terminal for running the applet, whether a user carrying out a login request logs in for the first time or not is judged based on login information corresponding to locally stored user information, and when the user does not log in for the first time, after the fact that the login state is effective is judged based on the stored login information, the user logs in according to the login information, a developer server does not need to request the applet server to obtain the user identity, the service does not need to call an applet interface to check the login state, a login mechanism is simplified, and login efficiency is improved.
The following introduces a login method provided by an embodiment of the present invention from the perspective of a developer server, and the login method described below may be referred to in correspondence with the login method content described above at the terminal.
Fig. 4 is a flowchart of a login method provided in an embodiment of the present invention, where the method is applicable to a developer server operated by a developer, and referring to fig. 4, the method may include:
step S401: receiving a login request sent by a terminal;
the terminal runs a preset applet, and the login request comprises user information.
And the terminal generates a login request according to the operation and sends the login request to the developer server.
In specific implementation, the login request may carry information such as user information, a login password, and a login status.
Step S402: judging whether the user is recorded or not based on the login request to obtain a third judgment result;
wherein, according to the login request, whether the user is recorded is judged.
In specific implementation, if the login is the first login, the user information carried by the login request can be searched to judge whether the developer server has information corresponding to the user information, and if the developer server does not have the information, the user is judged not to be recorded. If the login request is not the first login, the login state and the user information/user unique identifier can be carried in the login request, and if the login request is carried as the user unique identifier, the user information corresponding to the login state can be determined based on the corresponding relation between the user information and the user unique identifier stored in the developer server; if the carried user information is the user information, judging whether the developer server has information corresponding to the user information, and if so, judging to record the user.
Step S403: and characterizing that the user is not recorded based on a third judgment result, generating a user unique identifier, and sending the user unique identifier and the expiration time to the terminal.
When the user is not recorded in the developer server, the user logs in for the first time, and the user unique identifier of the user is generated and fed back to the terminal together with the expiration time set in the developer server, so that the terminal can store the user unique identifier and the expiration time in a local storage area.
In a specific implementation, the user unique identifier is information representing the identity of the user, has uniqueness, and may be a set of numbers and/or characters randomly generated by the developer server.
Specifically, based on the login request, the developer server implements the user login applet.
And based on the user login applet, the condition that the user is in the login state needs to be fed back to the terminal.
Specifically, the unique user identifier and the expiration time are fed back to the terminal, so that the terminal can know that the applet is logged in, and a login state is established based on the unique user identifier and the expiration time, so that whether the applet is invalid or not can be determined based on the login state when the applet is logged in again later, a developer server does not need to request the applet server to obtain the user identity, an applet interface does not need to be called to check the login state, a login mechanism is simplified, and login efficiency is improved.
Fig. 5 is another flowchart of a login method provided in an embodiment of the present invention, where the method is applicable to a developer server operated by a developer, and the method may include:
step S501: receiving a login request sent by a terminal;
step S502: judging whether the user is recorded or not based on the login request to obtain a third judgment result;
step S503: characterizing that the user is not recorded based on a third judgment result, generating a user unique identifier, and sending the user unique identifier and the expiration time to the terminal;
steps S501 to 503 are the same as steps S401 to 403 in fig. 4, and are not described herein again.
Step S504: recording the user according to the representation of the third judgment result, and judging whether the login state of the user is valid or not to obtain a fourth judgment result;
and if the user is not logged in for the first time based on the fact that the user is recorded in the developer server, judging whether the login state of the user is valid.
Specifically, when the user logs in for a non-first time, and sends a login request to the developer server, the user carries the login state stored by the terminal, and whether the login state is valid or not is determined in the developer server.
In specific implementation, when the developer server sends the unique identifier and the expiration time to the terminal user, the developer server can also record the sending time, the sending time is close to the setting time, and the general time difference is very small; or the set time is carried in the login request sent by the terminal.
Specifically, whether the login state of the user is in the validity period, that is, whether the login state of the user is valid is determined by calculating the difference between the time (time1) when the login request is received and the set time (time2) and comparing the difference with the expiration time (expires).
Specifically, if the time1-time2 is greater than expires, the login state is considered to be invalid, the user needs to log in again, login is performed based on the login request, and then corresponding service data can be obtained and fed back to the terminal, and step S506 is executed; and if the time1-time2 is less than expires, the login state is considered to be valid, and corresponding service data can be directly acquired and fed back to the terminal to execute the step S505.
Specifically, if the login state of the user is valid, the applet is directly logged in, and the service data corresponding to the applet is obtained and sent to the terminal, and step S505 is executed;
step S505: representing that the user login state is effective based on the fourth judgment result, and sending service data to the terminal;
specifically, the service data refers to service-related data, such as page content, real-time data, and the like, related to the applet in the applet running process after the user logs in the applet.
Step S506: and characterizing that the user login state is invalid based on the fourth judgment result, generating a user unique identifier, and sending the user unique identifier and the expiration time to the terminal, so that the terminal can store the user unique identifier, the expiration time and the set time in a local storage area, wherein the set time is the time when the terminal receives the user unique identifier.
If the login state of the user is invalid, logging in again, generating a user unique identifier based on user information in the login request, retransmitting the user unique identifier and the expiration time to the terminal, storing the user unique identifier and the expiration time in a local storage area after the terminal receives the user unique identifier and the expiration time, and storing the time of receiving the user unique identifier as set time.
Subsequently, when the terminal receives the login request again, the terminal refers to step S304 for the process of processing the login request, which is not described in detail herein.
Fig. 6 is a further flowchart of a login method provided in an embodiment of the present invention, where the method is applicable to a developer server operated by a developer, and the method may include:
step S601: receiving a login request sent by a terminal;
step S602: judging whether the user is recorded or not based on the login request to obtain a third judgment result;
step S603: characterizing that the user is not recorded based on a third judgment result, generating a user unique identifier, and sending the user unique identifier and the expiration time to the terminal;
steps S601 to 603 are the same as steps S401 to 403 in fig. 4, and are not described herein again.
Step S604: the user is recorded according to the representation of the third judgment result, and the unique user identification and the expiration time of the user are obtained according to the user information;
when the server terminal loses the content such as the login status, the setting time, and the expiration time stored therein due to various reasons, and if the server terminal is mistakenly deleted by the user or the stored content is deleted due to a system failure, the server terminal generates a login request without information such as the login status if the login status, the setting time, and the expiration time of the user are not acquired in the local storage area of the terminal when the user requests to login the applet.
When a login request is received, the user is searched and recorded in the developer server, and if the login request has no login state, the unique identifier of the user and the expiration time before the moment are obtained from the developer server and fed back to the terminal.
Step S605: and sending the user unique identification and the expiration time to the terminal so that the terminal can store the user unique identification, the expiration time and the set time in a local storage area.
Specifically, the user unique identifier and the expiration time are sent to the terminal, and the terminal stores the user unique identifier, the expiration time and the set time in a local storage area so as to be used when a login request is performed next time.
When the developer server sends the unique identifier and the expiration time to the terminal user, the developer server can also record the sending time, the sending time is close to the setting time, and the time difference is small generally.
In specific implementation, when the developer server acquires the expiration time and sends the unique user identifier and the expiration time to the terminal for the first time, whether the login state of the user fails or not is judged, and if the login state of the user fails, a new unique user identifier and the expiration time can be generated and sent to the terminal; if valid, the previously generated user unique identifier and expiration time may be directly transmitted to the terminal.
Fig. 7 shows a simple sequence diagram of the login method provided by the present application, including an applet 01 running on the terminal and a developer server 02.
S701: the applet sends a login request to the developer server through wx.request ();
s702: the developer server generates a unique user identifier;
s703: the developer server returns the unique user identifier and the expiration time to the applet;
s704: the small program self-defines a login state, and the login state, the expiration time and the set time are stored in a local memory (localstorage);
s705: the applet sends a login request carrying a user-defined login state to the developer server through wx.request ();
s706: the developer server checks the validity of the login state;
s707 is executed on the premise that the login state is valid.
S707: and returning the service data.
In the following, the device for logging in an applet provided in the embodiments of the present invention is introduced, and the device for logging in an applet described below may be referred to the above login method.
Fig. 8 is a structural block diagram of a login apparatus according to an embodiment of the present invention, where the login apparatus may specifically be a terminal running an applet, and the login apparatus may include: a first receiving module 801, a storage module 802, a first judging module 803, a processing module 804 and a first sending module 805.
The first receiving module 801 is configured to receive a login request of a user, where the login request includes user information;
the storage module 802 is configured to store login information;
specifically, the storage module may be a local storage of the terminal.
The first determining module 803 is configured to determine, according to the user information of the login request, whether a local storage module stores login information corresponding to the user information, so as to obtain a first determination result; the local storage module is characterized to store login information corresponding to the user information based on the first judgment result, and the processing module 804 is triggered; based on the first judgment result, the local storage module is characterized that the login information corresponding to the user information is not stored or the login state of the user is invalid, and a first sending module 805 is triggered;
the processing module 804 is configured to determine that the login state of the user is valid based on the login information, send a login request carrying the login state to the developer server, and receive service data fed back by the developer server;
wherein the first sending module 805 is configured to send a login request to a developer server, so as to log in based on the login request.
Preferably, the sending a login request to a developer server, so that login is based on the login request, includes:
sending the login request to a developer server;
receiving a user unique identifier, expiration time and service data fed back by the developer server, wherein the user unique identifier is generated according to the login request;
establishing a login state based on the received user unique identifier;
and saving the login state, the expiration time and the set time as login information to a local storage area, wherein the set time is the time when the unique user identifier is received.
Preferably, the determining whether the login state of the user is valid based on the login information specifically includes:
judging whether the login state of the user is valid according to the time of receiving the login request and the set time and the expiration time in the login information;
sending a login request to a developer server based on the validity of the login state of the user, wherein the login request comprises the login state;
sending a login request to a developer server based on the login state failure of the user;
determining whether the login state is valid based on information fed back by the developer server.
Preferably, the determining whether the login status is valid based on the information fed back by the developer server includes:
analyzing the feedback information to obtain service data, and determining that the login state is effective when the developer server judges;
analyzing the feedback information to obtain a unique user identifier and expiration time, and determining that the login state is invalid by the developer server.
Alternatively, the login device may be a hardware device, and the modules and units described above may be provided in the functional module in the login device. Fig. 9 is a block diagram showing a hardware configuration of a login apparatus, and referring to fig. 9, the login apparatus may include: a processor 1, a communication interface 2, a memory 3 and a communication bus 4; wherein, the processor 1, the communication interface 2 and the memory 3 complete the communication with each other through the communication bus 4; optionally, the communication interface 2 may be an interface of a communication module, such as an interface of a GSM module;
a processor 1 for executing a program; a memory 3 for storing a program; the program may include program code comprising computer operating instructions;
the processor 1 may be a central processing unit CPU, or an application specific Integrated Circuit ASIC (application specific Integrated Circuit), or one or more Integrated circuits configured to implement embodiments of the present invention; the memory 3 is in particular a local storage.
Among them, the procedure can be specifically used for:
after the client is started, receiving a login request of a user, wherein the login request comprises user information;
judging whether a local storage area stores login information corresponding to the user information or not according to the user information of the login request to obtain a first judgment result;
representing that login information corresponding to the user information is not stored in a local storage area based on the first judgment result, and sending a login request to a developer server so as to log in based on the login request;
and representing that a local storage area stores login information corresponding to the user information based on the first judgment result, judging that the login state of the user is valid based on the login information, and logging in based on the login information.
Another login device provided in the embodiment of the present invention is described below, where the login device may specifically be a developer server, and the login device described below may be referred to in correspondence with the above signaling flow content and the login method described in terms of the developer server.
Fig. 10 is another structural block diagram of a login apparatus according to an embodiment of the present invention, where the login apparatus may specifically be a terminal running an applet, and the login apparatus may include: a second receiving module 1001, a second judging module 1002, an identifying module 1003 and a second sending module 1004.
The second receiving module 1001 is configured to receive a login request sent by a terminal, where the terminal runs a preset applet, and the login request includes user information;
the second determining module 1002 is configured to determine whether the user is recorded based on the login request, so as to obtain a third determination result;
the identification module 1003 is configured to characterize the unrecorded user based on a third determination result, and generate a unique user identification;
the second sending module 1004 is configured to send the user unique identifier and the expiration time to the terminal.
Preferably, the method further comprises the following steps:
recording the user according to the representation of the third judgment result, and judging whether the login state of the user is valid or not to obtain a fourth judgment result;
representing that the user login state is effective based on the fourth judgment result, and sending service data to the terminal;
and characterizing that the user login state is invalid based on the fourth judgment result, generating a user unique identifier, and sending the user unique identifier and the expiration time to the terminal, so that the terminal can store the user unique identifier, the expiration time and the set time in a local storage area, wherein the set time is the time when the terminal receives the user unique identifier.
Preferably, the method further comprises the following steps:
the user is recorded according to the representation of the third judgment result, and the unique user identification and the expiration time of the user are obtained according to the user information;
and sending the user unique identification and the expiration time to the terminal so that the terminal can store the user unique identification, the expiration time and the set time in a local storage area.
Optionally, the login device may be a hardware device, and the module described above may be a functional module disposed in the login device. Fig. 11 is a block diagram showing a hardware configuration of a login apparatus, and referring to fig. 11, the login apparatus may include: a processor 1 ', a communication interface 2', a memory 3 'and a communication bus 4'; the processor 1 ', the communication interface 2' and the memory 3 'are communicated with each other through a communication bus 4'; optionally, the communication interface 2' may be an interface of a communication module, such as an interface of a GSM module;
a processor 1' for executing a program; a memory 3' for storing a program; the program may include program code comprising computer operating instructions;
the processor 1' may be a central processing unit CPU, or an application specific Integrated Circuit ASIC, or one or more Integrated circuits configured to implement embodiments of the present invention; the memory 3' may comprise a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.
Among them, the procedure can be specifically used for:
receiving a login request sent by a terminal, wherein the terminal runs a preset applet and the login request comprises user information;
judging whether the user is recorded or not based on the login request to obtain a third judgment result;
and characterizing that the user is not recorded based on a third judgment result, generating a user unique identifier, and sending the user unique identifier and the expiration time to the terminal.
The embodiments in the present description are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other. The device disclosed by the embodiment corresponds to the method disclosed by the embodiment, so that the description is simple, and the relevant points can be referred to the method part for description.
Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative components and steps have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (10)
1. A login method, comprising:
receiving a login request of a user, wherein the login request comprises user information;
judging whether a local storage area stores login information corresponding to the user information or not according to the user information of the login request to obtain a first judgment result;
representing that login information corresponding to the user information is not stored in a local storage area based on the first judgment result, and sending a login request to a developer server so as to log in based on the login request;
and representing that a local storage area stores login information corresponding to the user information based on the first judgment result, judging that the login state of the user is valid based on the login information, sending a login request carrying the login state to a server, and receiving service data fed back by a developer server.
2. The method of claim 1, the sending a login request to a developer server to cause login based on the login request, comprising:
sending the login request to a developer server;
receiving a user unique identifier, expiration time and service data fed back by the developer server, wherein the user unique identifier is generated according to the login request;
establishing a login state based on the received user unique identifier;
and saving the login state, the expiration time and the set time as login information to a local storage area, wherein the set time is the time when the unique user identifier is received.
3. The method according to claim 1, wherein determining whether the login status of the user is valid based on the login information specifically comprises:
judging whether the login state of the user is valid according to the time of receiving the login request and the set time and the expiration time in the login information;
sending a login request to a developer server based on the validity of the login state of the user, wherein the login request comprises the login state;
sending a login request to a developer server based on the login state failure of the user;
determining whether the login state is valid based on information fed back by the developer server.
4. The method of claim 3, wherein determining whether the login state is valid based on information fed back by the developer server comprises:
analyzing the feedback information to obtain service data, and determining that the login state is effective when the developer server judges;
analyzing the feedback information to obtain a unique user identifier and expiration time, and determining that the login state is invalid by the developer server.
5. A login method, comprising:
receiving a login request sent by a terminal, wherein the terminal runs a preset applet and the login request comprises user information;
judging whether the user is recorded or not based on the login request to obtain a third judgment result;
and characterizing that the user is not recorded based on a third judgment result, generating a user unique identifier, and sending the user unique identifier and the expiration time to the terminal.
6. The method of claim 5, further comprising:
recording the user according to the representation of the third judgment result, and judging whether the login state of the user is valid or not to obtain a fourth judgment result;
representing that the user login state is effective based on the fourth judgment result, and sending service data to the terminal;
and characterizing that the user login state is invalid based on the fourth judgment result, generating a user unique identifier, and sending the user unique identifier and the expiration time to the terminal, so that the terminal can store the user unique identifier, the expiration time and the set time in a local storage area, wherein the set time is the time when the terminal receives the user unique identifier.
7. The method of claim 5, further comprising:
the user is recorded according to the representation of the third judgment result, and the unique user identification and the expiration time of the user are obtained according to the user information;
and sending the user unique identification and the expiration time to the terminal so that the terminal can store the user unique identification, the expiration time and the set time in a local storage area.
8. A login apparatus, comprising:
the system comprises a first receiving module, a second receiving module and a third receiving module, wherein the first receiving module is used for receiving a login request of a user, and the login request comprises user information;
the storage module is used for storing login information;
the first judgment module is used for judging whether the local storage module stores login information corresponding to the user information according to the user information of the login request to obtain a first judgment result; representing that a local storage module stores login information corresponding to the user information based on the first judgment result, and triggering a processing module; characterizing that a local storage module does not store login information corresponding to the user information or the login state of the user is invalid based on the first judgment result, and triggering a first sending module;
the processing module is used for judging that the login state of the user is valid based on the login information, sending a login request carrying the login state to the server, and receiving service data fed back by the developer server;
the first sending module is used for sending a login request to a developer server so as to log in based on the login request.
9. A login apparatus, comprising:
the second receiving module is used for receiving a login request sent by a terminal, wherein the terminal runs a preset applet, and the login request comprises user information;
the second judgment module is used for judging whether the user is recorded or not based on the login request to obtain a third judgment result;
the identification module is used for representing the user which is not recorded based on a third judgment result and generating a unique user identification;
and the second sending module is used for sending the unique user identifier and the expiration time to the terminal.
10. A storage medium for storing a program for instructing associated hardware to perform a method as claimed in any one of claims 1 to 4.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910718744.XA CN111181908B (en) | 2019-08-05 | 2019-08-05 | Applet login method, device and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910718744.XA CN111181908B (en) | 2019-08-05 | 2019-08-05 | Applet login method, device and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111181908A true CN111181908A (en) | 2020-05-19 |
| CN111181908B CN111181908B (en) | 2021-11-26 |
Family
ID=70657045
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910718744.XA Active CN111181908B (en) | 2019-08-05 | 2019-08-05 | Applet login method, device and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111181908B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113568543A (en) * | 2021-06-30 | 2021-10-29 | 北京达佳互联信息技术有限公司 | Information processing method, information processing device, electronic equipment and storage medium |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103037312A (en) * | 2011-10-08 | 2013-04-10 | 阿里巴巴集团控股有限公司 | Message push method and message push device |
| CN107294910A (en) * | 2016-03-31 | 2017-10-24 | 华为技术有限公司 | A kind of login method and server |
| CN107483418A (en) * | 2017-07-27 | 2017-12-15 | 阿里巴巴集团控股有限公司 | Login process method, method for processing business, device and server |
| CN109491721A (en) * | 2018-11-02 | 2019-03-19 | 百度在线网络技术（北京）有限公司 | Method and apparatus for load information |
| CN109936567A (en) * | 2019-02-01 | 2019-06-25 | 国美网安科技有限公司 | Detection method, device, electronic equipment and the storage medium of log-on message |
| CN109933367A (en) * | 2019-02-03 | 2019-06-25 | 广州视源电子科技股份有限公司 | Cookie implementation method, device and the computer equipment of small routine |
-
2019
- 2019-08-05 CN CN201910718744.XA patent/CN111181908B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103037312A (en) * | 2011-10-08 | 2013-04-10 | 阿里巴巴集团控股有限公司 | Message push method and message push device |
| CN107294910A (en) * | 2016-03-31 | 2017-10-24 | 华为技术有限公司 | A kind of login method and server |
| CN107483418A (en) * | 2017-07-27 | 2017-12-15 | 阿里巴巴集团控股有限公司 | Login process method, method for processing business, device and server |
| CN109491721A (en) * | 2018-11-02 | 2019-03-19 | 百度在线网络技术（北京）有限公司 | Method and apparatus for load information |
| CN109936567A (en) * | 2019-02-01 | 2019-06-25 | 国美网安科技有限公司 | Detection method, device, electronic equipment and the storage medium of log-on message |
| CN109933367A (en) * | 2019-02-03 | 2019-06-25 | 广州视源电子科技股份有限公司 | Cookie implementation method, device and the computer equipment of small routine |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113568543A (en) * | 2021-06-30 | 2021-10-29 | 北京达佳互联信息技术有限公司 | Information processing method, information processing device, electronic equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111181908B (en) | 2021-11-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11856132B2 (en) | Validating automatic number identification data | |
| US8649766B2 (en) | Authentication apparatus | |
| JP4880699B2 (en) | Method, system, and apparatus for protecting a service account | |
| CN105491001B (en) | Secure communication method and device | |
| KR100950894B1 (en) | Method and system for registering and automatically retrieving digital-certificates in voice over internet protocolVOIP communications | |
| CN109815656A (en) | Login authentication method, device, equipment and computer readable storage medium | |
| US8261336B2 (en) | System and method for making accessible a set of services to users | |
| CN107948204A (en) | One key login method and system, relevant device and computer-readable recording medium | |
| CN111355713B (en) | Proxy access method, device, proxy gateway and readable storage medium | |
| CN107086979B (en) | User terminal verification login method and device | |
| CN111010363B (en) | Information authentication method and system, authentication module and user terminal | |
| US10904243B2 (en) | Authenticate a first device based on a push message to a second device | |
| CN108076077A (en) | A kind of conversation controlling method and device | |
| US9680814B2 (en) | Method, device, and system for registering terminal application | |
| CN111181908B (en) | Applet login method, device and storage medium | |
| CN113761509B (en) | iframe verification login method and device | |
| CN110430062A (en) | Logging request processing method, device, equipment and medium | |
| CN109905394A (en) | Method for anti-counterfeit, base station, user terminal, user support system based on block chain | |
| CN103747423B (en) | A kind of register method of terminal applies, device and system | |
| CN112272093A (en) | Token management method, electronic equipment and readable storage medium | |
| EP2355028A1 (en) | Authentication apparatus | |
| US20210195418A1 (en) | A technique for authenticating data transmitted over a cellular network | |
| JP4671686B2 (en) | Network file system and authentication method | |
| CN114302349B (en) | Method and system for extracting number by client | |
| CN111404957B (en) | Method and system for improving security of CDN server based on SSH |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |