modify server_plugin.md and server_plugin.zh-cn.md

Max-zs · Oct 22, 2024 · 43da333 · 43da333
1 parent f25feca
commit 43da333
Show file tree

Hide file tree

Showing 8 changed files with 18 additions and 38 deletions.
diff --git a/docs/images/plugin_image10.png b/docs/images/plugin_image10.png
diff --git a/docs/images/plugin_image5.png b/docs/images/plugin_image5.png
diff --git a/docs/images/plugin_image6.png b/docs/images/plugin_image6.png
diff --git a/docs/images/plugin_image7.png b/docs/images/plugin_image7.png
diff --git a/docs/images/plugin_image8.png b/docs/images/plugin_image8.png
diff --git a/docs/images/plugin_image9.png b/docs/images/plugin_image9.png
diff --git a/docs/server_plugin.md b/docs/server_plugin.md
@@ -162,19 +162,13 @@ In the plugin function design phase, the following core points need to be clarif
 
 For example, the main functionality to be implemented by the "example" plugin is as follows:
 
-1. When the identity authentication platform of a province receives a user-submitted form containing the user's ID and password, the NHP-Server receives the ticket attached to the redirect URL from the provincial authentication platform;
+1. After submitting a form containing the user's identity and password on the H5 page;
 
-2. Call the ticket verification interface of the provincial identity authentication platform, receive the response message, and extract the Token information included in the message;
+2. The NHP-Server server receives the form for verification. After the verification is successful, it initiates a knock on the NHP-AC server;
 
-3. The NHP-Server sends a POST request to the provincial identity authentication platform to verify the validity of the Token, with the request format referring to the interface signature scheme and parameter information in the integration document;
+3. After NHP-AC successfully opens the door, it returns the application server address to the client;
 
-4. After successful Token verification, the NHP-Server sends an open door request to the NHP-AC access control server, and after a successful opening, redirects to the application proxy server with a 302 response.
-
-The sequence diagram for the entire functionality process is as follows:
-
-![Plugin Function Sequence Diagram Example](/images/plugin_image5.png) 
-
-***Figure 4 Plugin Function Sequence Diagram Example***
+4. Access application server resources.
 
 ## 3.4 Core Code Development
 
@@ -188,19 +182,15 @@ The steps for developing the plugin for the NHP server are as follows:
 
 4. Import your plugin in the main application. In the main application file (main.go), import your plugin package and call your plugin functions as needed.
 
-Following the plugin function design, taking the "example" plugin as an example, the AuthWithHttp function receives HTTP requests, the authRegular function processes URL parameter information, and you need to design auxiliary functions such as ValidateTicket for ticket verification, ValidateToken for Token validity verification, fetchToken for constructing POST requests with Token, and signDemo for generating signature schemes to achieve functionality. Development can be extended according to specific functional requirements.
+Refer to the plug-in function design for code development. Taking the "example" plug-in as an example, the AuthWithHttp function is designed to receive and process HTTP requests, the authRegular function verifies the user name and password and knocks on the door, the authAndShowLogin function loads login page resources, etc., and verification auxiliary functions need to be designed to implement the functions. Expansion and development can be carried out according to specific functional requirements.
 
 ![Example Plugin Core Code and Auxiliary Code Function Example](/images/plugin_image6.png) 
 
 ![Example Plugin Core Code and Auxiliary Code Function Example](/images/plugin_image7.png) 
 
 ![Example Plugin Core Code and Auxiliary Code Function Example](/images/plugin_image8.png) 
 
-![Example Plugin Core Code and Auxiliary Code Function Example](/images/plugin_image9.png) 
-
-![Example Plugin Core Code and Auxiliary Code Function Example](/images/plugin_image10.png) 
-
-***Figures 5, 6, 7, 8, 9 Example Plugin Core Code and Auxiliary Code Function Example***
+***Figures 4, 5, 6 Example Plugin Core Code and Auxiliary Code Function Example***
 
 ## 3.5 Plugin Compilation Testing and Deployment
 
@@ -214,21 +204,21 @@ The compilation process ensures that the plugin's code is consistent with the ma
 
 ![Define Plugin Directory](/images/plugin_image11.png) 
 
-***Figure 10 Define Plugin Directory***
+***Figure 7 Define Plugin Directory***
 
 This line of code specifies the storage location of the plugin, which is the server/plugins directory. All plugin source codes and configuration files will be placed in this directory. When starting the NHP service, to ensure the plugin loads correctly, the plugin file path needs to be configured in the NHP-Server's etc/resource.toml configuration file.
 
 ![Plugin File Path Configuration](/images/plugin_image12.png) 
 
-***Figure 11 Plugin File Path Configuration***
+***Figure 8 Plugin File Path Configuration***
 
 ***Generate Version Information and Start Build***: The generate-version-and-build task includes a series of steps to generate version numbers, commit IDs, build times, and other information. This information is helpful for tracking the version and build status of the plugin.
 
 ***Plugin Compilation Logic***: In the Makefile, the plugins: task is responsible for executing the plugin compilation, as shown in the image below:
 
 ![Plugin Compilation Task plugins](/images/plugin_image13.png) 
 
-***Figure 12 Plugin Compilation Task plugins***
+***Figure 9 Plugin Compilation Task plugins***
 
 Plugin Directory Check: test -d $(NHP_PLUGINS) checks if the defined plugin directory (server/plugins) exists.
 

diff --git a/docs/zh-cn/server_plugin.zh-cn.md b/docs/zh-cn/server_plugin.zh-cn.md
@@ -164,19 +164,13 @@ NHP 服务器中的每个插件通常都结构化为一个单独的 Go 包。例
 
 例如“example”插件所要实现的功能主体为：
 
-1. 在某省身份认证平台接收到用户所提交的包含用户民、密码的表单后，NHP-Server服务器接收来自某省认证平台跳转URL中所附带的ticket；
+1. 在H5页面提交包含用户民、密码的表单后；
 
-2. 调用某省身份认证平台验证ticket接口，接收响应报文，并提取报文信息中附带的Token信息；
+2. NHP-Server服务器接收表单进行验证，验证成功后向NHP-AC服务器发起敲门；
 
-3. NHP-Server服务器向某省身份认证平台发送POST请求，验证Token有效性，请求格式参照对接文档中的接口签名方案与参数信息；
+3. NHP-AC开门成功后返回应用服务器地址给客户端；
 
-4. Token验证成功后，NHP-Server服务器向NHP-AC门禁服务器发送开门请求，开门成功后302跳转到应用代理服务器。
-
-整个功能流程时序图如下：
-
-![插件功能时序图示例](/images/plugin_image5.png) 
-
-***图四 插件功能时序图示例***
+4. 访问应用服务器资源。
 
 ### 3.4 核心代码开发
 
@@ -190,19 +184,15 @@ NHP 服务器中的每个插件通常都结构化为一个单独的 Go 包。例
 
 4. 在主应用程序中导入您的插件。在主应用程序文件 (main.go) 中，导入您的插件包并根据需要调用您的插件函数。
 
-参照插件功能设计进行代码开发，以“example”插件为例，AuthWithHttp函数接收HTTP请求，authRegular函数处理URL参数信息，并且需要设计验证ticket函数（ValidateTicket）、验证token有效性函数（ValidateToken）、构造带有token的POST请求函数（fetchToken）以及生成签名方案函数（signDemo）等辅助函数来实现功能。按照具体功能要求可进行拓展开发。
+参照插件功能设计进行代码开发，以“example”插件为例，设计AuthWithHttp函数接收处理HTTP请求，authRegular函数验证用户名密码并进行敲门，authAndShowLogin函数加载登录页面资源等，并且需要设计验辅助函数来实现功能。按照具体功能要求可进行拓展开发。
 
 ![example插件核心代码以及辅助代码函数示例](/images/plugin_image6.png) 
 
 ![example插件核心代码以及辅助代码函数示例](/images/plugin_image7.png) 
 
 ![example插件核心代码以及辅助代码函数示例](/images/plugin_image8.png) 
 
-![example插件核心代码以及辅助代码函数示例](/images/plugin_image9.png) 
-
-![example插件核心代码以及辅助代码函数示例](/images/plugin_image10.png) 
-
-***图五、六、七、八、九 example插件核心代码以及辅助代码函数示例***
+***图四、五、六 example插件核心代码以及辅助代码函数示例***
 
 ### 3.5 插件的编译测试与部署
 
@@ -216,21 +206,21 @@ NHP 服务器中的每个插件通常都结构化为一个单独的 Go 包。例
 
 ![定义插件目录](/images/plugin_image11.png) 
 
-***图十 定义插件目录***
+***图七 定义插件目录***
 
 这行代码指定了插件的存放位置，即 server/plugins 目录。所有插件的源码和配置文件将会放在这个目录下，在启动NHP服务时，要确保插件能够正常加载，需要在NHP-Server的etc/resource.toml配置文件中配置插件文件路径。
 
 ![插件文件路径配置](/images/plugin_image12.png) 
 
-***图十一 插件文件路径配置***
+***图八 插件文件路径配置***
 
 ***生成版本信息并开始构建***: 在 generate-version-and-build 任务中，包含了一系列步骤用于生成版本号、提交 ID、构建时间等信息。这些信息有助于跟踪插件的版本和构建状态。
 
 ***插件的编译逻辑***: 在 Makefile 中的 plugins: 任务负责执行插件的编译，如下图：
 
 ![插件编译任务plugins](/images/plugin_image13.png) 
 
-***图十二 插件编译任务plugins***
+***图九 插件编译任务plugins***
 
 插件目录检查: test -d $(NHP_PLUGINS) 用于检查是否存在定义好的插件目录 (server/plugins)。