Implementation method for user authentication and nailing notification of graph database document site

Abstract

The invention discloses a method for realizing user authentication and nailing notification of a graph database document site, which belongs to the technical field of computer security, and comprises the following steps of: integrating an Oauth2 authentication module into a reverse proxy server, and docking with an identity authentication service; the external request for accessing the graph database document site is redirected to the identity authentication service for user authentication; after the user authentication is passed, the Oauth2 authentication module executes authentication operation; the identity authentication service captures a user registration event in real time, and when the registration event is monitored, user information corresponding to the registration event is extracted; filling a preset notification template according to the user information to obtain a notification message, and pushing the notification message to a management terminal through a configurable message notification interface; and the reverse proxy server dynamically controls the access authority of the user to the content of the graph database document site based on the authentication result. According to the application, user authentication can be carried out on the graph database document site, and meanwhile, an administrator can be notified of a user registration event through the nailing robot Webhook.

Description

Technical Field

[0001] The present invention relates to the field of computer security technology, and in particular to a method for implementing user authentication and DingTalk notification for a graph database document site. Background Art

[0002] In modern information systems, the user registration function is a key link to improve user experience and enhance system management efficiency. To ensure that new users can receive timely services and support, enterprises and organizations usually expect to notify relevant staff or system administrators immediately after users complete the registration process, so as to quickly respond to and process new user requests.

[0003] In traditional solutions, enterprises usually need to independently develop a user authentication (Auth) module to implement access control. For example, in the permission management scenario of a graph database document site, developers need to build a complete user authentication system, resulting in an extended development cycle and increased maintenance costs. To solve this problem, existing technologies tend to integrate mature third-party identity verification services such as Keycloak into the graph database document site. Through standardized protocols provided by Keycloak such as OAuth2.0 and OpenID Connect, unified user authentication can be quickly achieved, and the login process can be redirected to the Keycloak server for execution, thus significantly reducing the system coupling degree and simplifying the development process.

[0004] However, although Keycloak provides powerful user management and authentication services, it does not support a notification mechanism triggered by registration events itself. This means that administrators cannot obtain new user information in real time, resulting in delays in subsequent operations such as user review and permission allocation. In addition, in the domestic enterprise environment, DingTalk, as a mainstream collaborative office platform, has high real-time performance and strong compatibility in its message push interface, while Keycloak natively does not support deep integration with the DingTalk system. If a registration notification module is independently developed in the graph database document site, additional components such as event listening, message queues, and interface adaptation need to be processed, which not only increases the complexity of the system architecture but also raises the risks and difficulties of operation and maintenance.

[0005] In summary, although using Keycloak for user authentication and management can significantly reduce the development workload and improve system security, its lack of support for registration event notifications and direct integration capabilities with domestic common tools such as DingTalk limits its practicality. Summary of the Invention

[0006] The purpose of the present invention is to provide a method for implementing user authentication and DingTalk notification for a graph database document site, so as to solve the problem in the prior art that after a customer registers a user for a graph database document site, the system does not notify the administrator of the registration event, resulting in untimely processing of customer requirements.

[0007] To achieve the above object, the present application adopts the following technical solutions:

[0008] A method for implementing user authentication and DingTalk notification of a graph database document site in the present application includes the following steps:

[0009] Integrate the Oauth2 authentication module into the reverse proxy server and interface with the identity authentication service to redirect external requests for accessing the graph database document site to the identity authentication service for user authentication;

[0010] After the user authentication is passed, the Oauth2 authentication module performs an authentication operation according to the locally pre-configured authentication rules and the access token generated by the identity authentication service;

[0011] Utilize the event listening mechanism of the identity authentication service to capture user registration events in real time. When the registration event is monitored, extract the user information corresponding to the registration event;

[0012] Fill a preset notification template according to the user information to obtain a notification message, and push the notification message to the management terminal through a configurable message notification interface;

[0013] The reverse proxy server dynamically controls the access rights of users to the content of the graph database document site based on the authentication result returned by the Oauth2 authentication module.

[0014] Preferably, integrating the Oauth2 authentication module into the reverse proxy server and interfacing with the identity authentication service includes:

[0015] Configure the Nginx server as the reverse proxy server of the graph database document site;

[0016] Connect the Oauth2 authentication module to the Nginx server and configure Keycloak client parameters in the Oauth2 authentication module, including client ID, secret key, and OpenID Connect issuer address.

[0017] Preferably, the authentication rules include:

[0018] A user has the right to access the graph database document site if and only if the user has a specified role or belongs to a specific group in the Keycloak client.

[0019] Preferably, performing the authentication operation according to the locally pre-configured authentication rules and the access token generated by the identity authentication service includes:

[0020] Parse the access token generated by the identity authentication service to obtain user role and group information, and match the user role and group information with the authentication rules. If there is a successful match, the authentication is successful and the access token is valid.

[0021] Preferably, the user registration event includes a user self-registration event and an administrator user creation event.

[0022] Preferably, extracting the user information corresponding to the registration event includes:

[0023] Extract the user ID, email, username, and name fields from the UserModel object of the Keycloak client.

[0024] Preferably, the configurable message notification interface includes the DingTalk robot Webhook interface.

[0025] Preferably, after pushing the notification message to the management terminal through the configurable message notification interface, it further includes:

[0026] Receive the response from DingTalk, and verify whether the Webhook notification is successful according to the status code and response body contained in the DingTalk response. The response body contains an errorcode field;

[0027] Record the notification result in the log, trigger an alarm when it fails, and retain the exception stack information.

[0028] Preferably, based on the authentication result returned by the Oauth2 authentication module, dynamically controlling the user's access rights to the content of the graph database document site includes:

[0029] If the authentication is successful, forward the external request to the graph database document site and inject user authentication information into the request header;

[0030] If the authentication fails, return a 403 error and redirect the external request to the Oauth2 authentication module.

[0031] Preferably, the method further includes:

[0032] Match the path of the external request through a regular expression, and dynamically load the custom error page in the corresponding directory when the requested resource does not exist or an error occurs on the server side;

[0033] Force the response returned by the Nginx server to the Keycloak client to use the HTTPS protocol and inject custom security headers, where the custom security headers include X-Frame-Options, X-XSS-Protection, and X-Content-Type-Options.

[0034] The present invention has the following beneficial effects:

[0035] Based on the Nginx server, Oauth2 Proxy, and Keycloak, the service construction and docking of the graph database document site are carried out, and user authentication can be performed on the graph database document site. At the same time, the administrator user registration event is notified through the DingTalk robot Webhook, solving the pain point that the system does not prompt the administrator after the customer registers the graph database document site, and realizing the timely processing of external users accessing the graph database document site. Description of the Drawings

[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0037] Figure 1 It is a flowchart of a method for implementing user authentication and DingTalk notification of a graph database document site provided by an embodiment of the present application;

[0038] Figure 2 It is a flowchart of a method for integrating a reverse proxy server provided by an embodiment of the present application;

[0039] Figure 3 It is a flowchart of a method for processing DingTalk responses provided by an embodiment of the present application;

[0040] Figure 4 It is a flowchart of a method for dynamically controlling access permissions provided by an embodiment of the present application. Detailed Embodiments

[0041] To make the technical solution of this application clearer, the following further describes the present invention in detail with reference to the accompanying drawings and specific embodiments. The terms "first", "second", etc. in the claims and the specification of this application are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence. It should be understood that such terms can be interchanged under appropriate circumstances. This is only a way of distinguishing when describing objects with the same attributes in the embodiments of this application. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, so that a process, method, system, product or device comprising a series of units does not have to be limited to those units, but may include other units not clearly listed or inherent to these processes, methods, products or devices.

[0042] An implementation method for user authentication of a graph database document site and DingTalk notification, as Figure 1 shown, includes the following steps:

[0043] S110. Integrate the Oauth2 authentication module into the reverse proxy server and dock with the identity authentication service to redirect external requests for accessing the graph database document site to the identity authentication service for user authentication;

[0044] S120. After the user authentication is passed, the Oauth2 authentication module performs an authentication operation according to the pre-configured authentication rules locally and the access token generated by the identity authentication service;

[0045] S130. Use the event listening mechanism of the identity authentication service to capture user registration events in real time. When a registration event is monitored, extract the user information corresponding to the registration event;

[0046] S140. Fill a preset notification template according to the user information to obtain a notification message, and push the notification message to the management terminal through a configurable message notification interface;

[0047] S150. The reverse proxy server dynamically controls the access rights of users to the content of the graph database document site based on the authentication result returned by the Oauth2 authentication module.

[0048] The Oauth2 authentication module generally refers to a software component or service used to implement the OAuth 2.0 protocol, which allows third-party applications to obtain limited access rights to user resources without directly handling user passwords. Among them, the OAuth2.0 protocol defines how to securely grant third-party applications access rights to user resources without directly handling user credentials (such as usernames and passwords). The Oauth2 authentication module can be a component on the server side, an independent service, or even a series of libraries and tools to help developers quickly integrate the OAuth2 authentication function into their applications.

[0049] The Oauth2 authentication module applied in this embodiment is the Oauth2 Proxy container. The Oauth2 Proxy container is a reverse proxy server specifically designed to protect web applications and services from unauthenticated user access. It implements the authentication function by supporting multiple OAuth 2.0 providers (such as GitHub, Google, and Keycloak, etc.), and can forward requests to the backend service after the user is successfully authenticated. In this embodiment, the OAuth 2.0 provider is Keycloak, that is to say, the identity authentication service is Keycloak.

[0050] In this embodiment, the Oauth2 Proxy container is integrated into the Nginx server that serves as the reverse proxy for the graph database documentation site, and then connected to Keycloak to jointly complete user authentication.

[0051] In one embodiment, as Figure 2 shown, integrating the Oauth2 authentication module into the reverse proxy server and docking with the identity authentication service includes:

[0052] S112. Configure the Nginx server as the reverse proxy server for the graph database documentation site;

[0053] S114. Connect the Oauth2 authentication module to the Nginx server and configure the Keycloak client parameters in the Oauth2 authentication module, including the client ID, secret key, and OpenID Connect issuer address.

[0054] Before integrating the Oauth2 Proxy container into the Nginx server, first set the Nginx server as the reverse proxy server for the graph database documentation site through the configuration file of the Nginx server, and at the same time configure the reverse proxy rules. For example, specify the address listened by the Nginx server as the local loopback address 127.0.0.1, the listening port number as 3000, and limit that only requests from the local host (127.0.0.1) can access the documentation site, and specify the root directory of the documentation site as / var / www / ent-docs / , where all static files such as HTML, CSS, and JS are stored. That is, when a user accesses a certain path, the Nginx server will look for the corresponding file in this directory, and at the same time specify the default index file as index.html, that is, when the user accesses the root directory, the Nginx server will first look for and load the index.html file in it.

[0055] Then, connect the Oauth2 Proxy container to the configured Nginx server and interface with Keycloak. Here, you can first install the Oauth2 Proxy container locally. Depending on the local system, you can choose to install it through binary files, Docker, package managers, or configuration files (oauth2-proxy.cfg). This is prior art and will not be elaborated here. You can also first create a new client, auth-doc, in the Keycloak system, including filling in the basic information of the client, such as the client ID and secret. Then, edit the configuration file for deploying the oauth2 proxy container. Configure the used image as quay.io / oauth2-proxy / oauth2-proxy:latest, the container name as oauth2, and set environment variables. This is the core configuration of the Oauth2 Proxy container, used to define its behavior and interaction with external systems, including specifying the connected provider as Keycloak OIDC, that is, the OpenID Connect issuer address. In other words, the Oauth2 Proxy container is responsible for redirecting external requests sent to it by the Nginx server to the Keycloak login page, configuring the client ID, secret, and callback address created in Keycloak. The callback address here refers to the redirect address of the external request after the user logs in successfully. After the user logs in successfully, the external request will be redirected to the login page of the Oauth2 Proxy container for authentication. The HTTP address and port listened by the Oauth2 Proxy container, that is, the backend service, etc. Here, it is necessary to ensure that the backend service set in the Nginx server configuration file is consistent with it. Some command parameters are also configured to further define the behavior of the Oauth2 Proxy container, which can also be understood as configuring the authentication rules, such as the user realms, client roles, and groups allowed to access the document site. In this embodiment, the allowed realm is public, the allowed client is auth-doc, the allowed client role is doc-user, and the allowed group is / doc-viewer. Finally, conduct tests and verifications. If both tests and verifications pass, it indicates that the Oauth2 Proxy container has been successfully integrated into the Nginx server and a connection with the Keycloak client has been established. Thus, it can be ensured that only authenticated users can access protected resources.

[0056] It should be noted here that in Keycloak, a realm is an independent user management unit. Multiple realms can be created for different applications or organizations, such as public, internal, or customer. Each realm can have its own user database, authentication process, role, and permission management. When configuring the Oauth2 Proxy container, specifying the allowed realm as public serves to tell the Oauth2 Proxy container to only allow users from the public realm to access protected resources.

[0057] After all configurations are completed, when there is an external request to access the graph database documentation site, the Nginx server configured with the Oauth2Proxy container will intercept the external request and check whether the request contains a valid session cookie. If so, the authentication operation will be directly performed. If there is no valid session cookie, the external request will be redirected to the login page of the Keycloak client. The request initiator, i.e., the user, enters their credentials, namely the client ID and secret, on this page. Keycloak verifies whether the credentials provided by the user are correct. If the verification passes, Keycloak will generate an access token and send the access token back to the callback address configured in the Oauth2 Proxy container. The Oauth2 Proxy container parses the access token to obtain detailed user information such as the username, user role, and group, etc., and then performs the authentication operation based on the locally pre-configured authentication operations such as allowed roles, groups, etc., and the obtained user information. By controlling the user access permissions, it has high scalability. And when the user registers for access to the documentation site, they can be redirected to Keycloak for registration, which is convenient for access and use.

[0058] In this embodiment, Keycloak is also configured through the event configuration page of the Keycloak management console to listen for user registration events, which include the user self-registration event Event.REGISTER and the administrator create user event AdminEvent.CREATE, and the method of sending notification messages is set to the DingTalk robot Webhook interface. When the event listener of Keycloak captures a registration event, it will obtain the corresponding UserModel object according to the userId in the event, and extract user information from it, such as user ID, email, username, and user name. Then, these user information will be filled into a pre-set notification template, which is a JSON template defined using a multi-line string and can be filled with user information through the formatted method. Among them, the formatted method is a new method introduced in Java 15. It accepts a variable number of parameters and replaces these parameters in order into the placeholders %s, %d, etc. in the calling string, which is especially suitable for use with text blocks, making the formatting of multi-line strings easier and clearer. Finally, the notification message is sent to the DingTalk administrator through the DingTalk robot Webhook interface.

[0059] Among them, the implementation code example for obtaining the DingTalk robot Webhook interface, that is, WEBHOOK_URL, is as follows:

[0060] @Override

[0061] private static String getWebhookUrl() {

[0062] / / First, try to obtain WEBHOOK_URL from the environment variable.

[0063] String url = System.getenv("WEBHOOK_URL");

[0064] / / If it is not set in the environment variable, then try to obtain it from the system property.

[0065] if (url == null) {

[0066] url = System.getProperty("WEBHOOK_URL");

[0067] }

[0068] / / If neither is set, record the error log, prompt the user that WEBHOOK_URL is not set, and throw a runtime exception to terminate the program execution and give an error message at the same time.

[0069] if (url == null) {

[0070] log.error("WEBHOOK_URL environment variable or systemproperty is not set!");

[0071] throw new RuntimeException("WEBHOOK_URL is not set");

[0072] }

[0073] / / Return the obtained URL.

[0074] return url;

[0075] }

[0076] After receiving the notification message, the DingTalk administrator will return an HTTP response, based on which the success of the Webhook notification can be verified.

[0077] Among them, the code example for implementing the listener for the user self-registration event Event.REGISTE is as follows:

[0078] @Override

[0079] public void onEvent(Event event) {

[0080] / / Receive an object of type Event as input.

[0081] log.debug("=====================================")

[0082] / / Print the separator.

[0083] log.debugf("New %s Event", event.getType());

[0084] / / Record the event type for easy understanding of the current event being processed during debugging; the currently recorded is the Event event.

[0085] log.debugf("onEvent-> %s", toString(event));

[0086] / / Print the detailed information of the event, and call the toString method to convert the event object into a string form.

[0087] if (EventType.REGISTER.equals(event.getType())) {

[0088] / / Determine whether the event type is REGISTER (user self-registration event).

[0089] log.debug("Processing REGISTER event");

[0090] / / Record the log indicating the start of processing the user self-registration event.

[0091] event.getDetails().forEach((key, value)->log.debugf("%s :%s", key, value));

[0092] / / Traverse the detailed information (key-value pairs) of the event and record each item in the log.

[0093] RealmModel realm = this.model.getRealm(event.getRealmId());

[0094] / / Obtain the corresponding RealmModel object according to the realmId in the event.

[0095] UserModel user = this.session.users().getUserById(realm,event.getUserId());

[0096] / / Obtain the corresponding UserModel object according to the userId in the event.

[0097] WebhookResult result = sendUserData(user);

[0098] / / Check whether the Webhook call is successful.

[0099] if (result.isSuccess()) {

[0100] log.infof("Webhook sent successfully for user %s.Response: %s", user.getUsername(), result.getMessage());

[0101] / / If successful, record a success log including the username and the returned message.

[0102] } else {

[0103] log.errorf("Webhook failed for user %s. Error: %s",user.getUsername(), result.getMessage());

[0104] / / If failed, record an error log including the username and the error message.

[0105] }

[0106] }

[0107] log.debug("=====================================");

[0108] }

[0109] The code for implementing the listener for the AdminEvent.CREATE event when an administrator creates a user is essentially the same as the code for implementing the listener for the Event.REGISTE event when a user self-registers, except that it processes the AdminEvent.CREATE event, the corresponding resource type is USER, the operation type is CREATE (user creation event), and at the same time, the methods for obtaining and sending user information are also different. The example is as follows:

[0110] UserModel user = this.session.users().getUserById(realm,adminEvent.getResourcePath().substring(6));

[0111] / / Extract the user ID from the resource path (assuming the resource path format is "users / {id}", then intercept the part after the 6th character).

[0112] WebhookResult result = sendUserData(user);

[0113] / / Call the sendUserData method to send user data to the Webhook and obtain the return result.

[0114] In one embodiment, as Figure 3As shown, after pushing the notification message to the management terminal through the configurable message notification interface, a method for implementing user authentication and DingTalk notification of a graph database document site further includes:

[0115] S210. Receive the response from DingTalk, and verify whether the Webhook notification is successful according to the status code and response experience included in the DingTalk response. The response body includes an errorcode field.

[0116] S220. Record the notification result in the log, trigger an alarm when it fails, and retain the exception stack information.

[0117] Specifically, after receiving the HTTP response sent by the DingTalk administrator, check whether the status code of the response is between 200 and 299. If it is, it is considered that the request is successful, and a successful result object is returned. If not, a failed result object is returned. Whether it is successful or not, the result object includes the status code and response data, and the response data also includes the errorcode field. When the request is successful, the errorcode field is 0. When the request fails, the errorcode field is 300005, and 300005 is the content returned when an error occurs in the DingTalk robot.

[0118] When the user registers a Keycloak account, the administrator can be notified in real time through the DingTalk robot Webhook for review, making up for the deficiencies of the native Keycloak.

[0119] This embodiment also records logs in key steps such as sending requests and receiving responses, which is convenient for debugging and problem troubleshooting. For example, when capturing network-related exceptions, that is, IOException such as connection timeouts and DNS resolution failures, error logs will be recorded and a failed result will be returned; when capturing the thread interruption exception InterruptedException, the interrupt status of the thread will be restored using the Thread.currentThread().interrupt() method so that the calling party can perceive the interruption.

[0120] In one embodiment, as Figure 4 shown, based on the authentication result returned by the Oauth2 authentication module, dynamically control the user's access rights to the content of the graph database document site, including:

[0121] S152. If the authentication is successful, forward the external request to the graph database document site and inject user authentication information into the request header.

[0122] S154. If the authentication fails, return a 403 error and redirect the external request to the Oauth2 authentication module.

[0123] After the authentication of the Oauth2 Proxy container is completed, the authentication result will be notified to the Nginx server. If the authentication is successful, it means that the user is allowed to access the resource of its original request, that is, the document site. At this time, the Nginx server will forward the external request to the graph database document site and add the user authentication information obtained from the access token to the request header. At the same time, the Oauth2 Proxy container can also set a session Cookie on the user's browser, indicating that the user has passed the authentication. This Cookie is used for automatic authentication in subsequent requests to avoid the need to log in again for each request.

[0124] If the authentication fails, it means that the user is denied access to the resource of its original request. The Nginx server will return a 403 error, view the error content, and can also redirect the external request to the login page of the Oauth2 Proxy container. However, if logging in again in a short period of time, the Cookie session and cache need to be cleared.

[0125] In one embodiment, the reverse proxy rule further includes:

[0126] Match the path of the external request through regular expressions, and dynamically load the custom error page in the corresponding directory when the requested resource does not exist or an error occurs on the server side;

[0127] Force the response returned by the Nginx server to the Keycloak client to use the HTTPS protocol and inject custom security headers. The custom security headers include X-Frame-Options, X-XSS-Protection, and X-Content-Type-Options.

[0128] In this embodiment, all external requests for accessing the graph database documentation site will be redirected by the Nginx server to the Keycloak client for user authentication. After successful authentication, the external request will then be redirected to the documentation site. At this time, the Nginx server will first extract the first path segment of the external request through the regular expression ^ / (?<first_path>[^ / ]+) / , and then check whether this first path segment corresponds to a file or a directory. If neither is the case, it will jump to the internal naming missing block, namely the `@error` naming position, which is usually used to handle error pages or other internal redirection logics. When the external request ends with a slash, such as ` / docs / `, it will be rewritten to the specified error page ` / <first_path> / 403.html`; when the external request does not end with a slash, such as ` / docs`, it will be rewritten to the specified error page ` / <first_path> / 404.html`. If a specified HTTP error occurs on the server side, such as 500, 502, 503, and 504, the external request will be redirected to the custom error page / 50x.html, where 500 indicates an internal server error, 502 indicates that the upstream server returns an invalid response, 503 indicates that the server is temporarily unavailable (such as due to high load), and 504 indicates a gateway timeout (usually because the upstream server fails to respond in a timely manner). Here, the server refers to all servers involved in the entire process. At the same time, all error pages are configured to be usable only during internal jumps in Nginx, avoiding direct external access.

[0129] After the documentation site processes the external request, it will generate the corresponding HTTP response and return it to the initiator of the external request. During this process, the Nginx server will force the HTTP response to use the HTTPS protocol to prevent man-in-the-middle attacks and protocol downgrade attacks, ensure the security of data transmission, and add custom security headers, such as X-Frame-Options, X-XSS-Protection, and X-Content-Type-Options, etc. Among them, X-Frame-Options is used to prevent the page from being nested into <iframe>to avoid clickjacking attacks; X-XSS-Protection indicates enabling the built-in XSS protection mechanism of the browser to prevent cross-site scripting attacks (XSS); X-Content-Type-Options is used to prevent the browser from guessing the MIME type of resources, i.e., MIME type sniffing, and avoid security issues caused by incorrect MIME types. For example, a non-script file may be misinterpreted as an executable script. These security headers can be added to the headers of the response body in their entirety or only a part can be added, determined according to actual requirements, so as to significantly improve the security of the Web application and reduce the potential attack surface.

[0130] This embodiment is based on the Nginx server, the Oauth2 Proxy container, and Keycloak to build and dock the service for the graph database document site, which can perform user authentication for the graph database document site. At the same time, the administrator user registration event is notified through the DingTalk robot Webhook interface, solving the pain point that the system does not prompt the administrator after the customer registers for the graph database document site in the existing solution, and realizing the timely processing of the needs of external users accessing the graph database document site.

[0131] The above-described embodiments only represent several implementation manners of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the patent of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present invention, several modifications and improvements can still be made, and these all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention should be subject to the appended claims.< / iframe>

Claims

1. A method for implementing user authentication and DingTalk notification for a graph database document site, characterized in that: The following steps are involved: Integrate the Oauth2 authentication module into the reverse proxy server and connect it to the identity authentication service to redirect external requests to access the graph database document site to the identity authentication service for user authentication; After the user authentication is passed, the Oauth2 authentication module performs authentication operations according to the local pre-configured authentication rules and the access token generated by the identity authentication service; Utilize the event monitoring mechanism of the identity authentication service to capture user registration events in real time, and when the registration event is monitored, extract the user information corresponding to the registration event; Filling a preset notification template according to the user information to obtain a notification message, and pushing the notification message to a management terminal through a configurable message notification interface; The reverse proxy server dynamically controls the user's access rights to the content of the graph database document site based on the authentication result returned by the Oauth2 authentication module.

2. According to claim 1, a method for implementing user authentication and DingTalk notification for a graph database document site, characterized in that: The Oauth2 authentication module is integrated into the reverse proxy server and connected to the identity authentication service, including: Configure the Nginx server as a reverse proxy server for the graph database document site; Connect the Oauth2 authentication module to the Nginx server and configure the Keycloak client parameters in the Oauth2 authentication module, including the client ID, key, and OpenID Connect issuer address.

3. A method for implementing user authentication and DingTalk notification for a graph database document site according to claim 2, characterized in that: The authentication rules include: A user has access to the graph database documentation site if and only if the user has a specified role in the Keycloak client or belongs to a specific group.

4. A method for implementing user authentication and DingTalk notification for a graph database document site according to claim 3, characterized in that: The performing of the authentication operation according to the locally pre-configured authentication rules and the access token generated by the identity authentication service includes: The access token generated by the identity authentication service is parsed to obtain user role and group information, and the user role and group information are matched with the authentication rule. If there is a successful match, the authentication is successful and the access token is valid.

5. According to claim 2, a method for implementing user authentication and DingTalk notification for a graph database document site, characterized in that: The user registration event includes a user self-registration event and an administrator creating a user event.

6. A method for implementing user authentication and DingTalk notification for a graph database document site according to claim 5, characterized in that: The extracting user information corresponding to the registration event includes: Extract the user ID, email address, username, and name fields from the UserModel object of the Keycloak client.

7. A method for implementing user authentication and DingTalk notification for a graph database document site according to claim 1, characterized in that: The configurable message notification interface includes the DingTalk robot Webhook interface.

8. A method for implementing user authentication and DingTalk notification for a graph database document site according to claim 7, characterized in that: After pushing the notification message to the management terminal through the configurable message notification interface, the method further includes: Receive the response from DingTalk, and verify whether the Webhook notification is successful based on the status code and response body contained in the DingTalk response, where the response body contains an errorcode field; The notification result is recorded in the log, and an alarm is triggered in case of failure and the exception stack information is retained.

9. A method for implementing user authentication and DingTalk notification for a graph database document site according to claim 2, characterized in that: The method of dynamically controlling the user's access rights to the content of the graph database document site based on the authentication result returned by the Oauth2 authentication module includes: If the authentication is successful, the external request is forwarded to the graph database document site, and the user authentication information is injected into the request header; If the authentication fails, a 403 error is returned and the external request is redirected to the Oauth2 authentication module.

10. A method for implementing user authentication and DingTalk notification for a graph database document site according to claim 9, characterized in that: The method further comprises: Match the path of the external request through a regular expression, and dynamically load the custom error page in the corresponding directory when the requested resource does not exist or an error occurs on the server side; Force the Nginx server to use the HTTPS protocol for all responses returned to the Keycloak client, and inject a custom security header, which includes X-Frame-Options, X-XSS-Protection, and X-Content-Type-Options.

Images