Openfire Integrated User Password Change Verification Method

I want to talk about a solution to change the openfire password authentication method. The situation is as follows: the default authentication method in openfire is mainly used by defaauthauthprovider. the login operation is used as an example, the blowfish class provides encryption and decryption solutions and the authfactory manages the call to blowfish to complete the password verification process, however, it is certain that the openfire server starts verification after receiving the message in the <AUTH/> section.

I have read some information about user integration on the Internet. This is the official openfire documentation. My goal is to change the password encryption method to MD5 encryption. My idea is to use jdbcauthprovider to verify logon and inherit the jdbcuserprovider to override the createuser and deleteuser methods to create and delete users. The reason for choosing inheritance is to follow the closure principle and maintain the completeness of the original openfire. You can write the inheritance class in the plug-in, as long as the provider is configured. user. specify the full path name of the classname parameter. Note that the new isreadonly () must return
False indicates that the external caller can modify the data.

The specific operations are similar to those described in the above link. However, since I did not use group data during development, provider. Group. classname still takes the default value. I personally feel that this should be fine. Note that the value of jdbcprovider. connectionstring is incorrect. If you add data directly to the ofproperty table, you can directly write the data, such as JDBC: mysql: // localhost/dbname? User = user & Password = PASSWORD & useunicode = true & characterencoding = UTF-8. However, if you configure it in the XML document, write & As & amp. Jdbcauthprovider is also specified. passwordtype is MD5 (the desired encryption method). However, you can see that jdbcauthprovider class annotations only support plain, MD5, sha1, sha256, and sha512 encryption methods. If they are not in this range, write your own authprovider.

If you do not understand the above, you must check the Code, including the Business Code and various annotations. Trace the specific execution process through the stack. I paste the stack call in the defaultauthprovider and jdbcauthprovider Authentication mode, which is the code execution process of the login operation.

The above is default, and the following is JDBC. Pay attention to the processing of digestmd5server and saslserverplainimpl, which will be handed over to xmppcallbackhandler. The first one starts when you receive the content in the <response/> section, and the other one starts after you receive the <AUTH/> section.