🙋设定密码类型未clear后，同步用户正常，但用户自行更改密码后又恢复ssha了
huangjun0910 opened this issue · comments
设定密码类型未clear后，同步用户正常，但用户自行更改密码后又恢复ssha了
您好 @huangjun0910👋，我已收到您的反馈，我将安排时间考虑您提交的信息并进行回复。-- 这条信息是由自动回复的机器人发出的。
Hello @huangjun0910. I have received your feedback, and I will arrange time to consider the information you submitted and reply. -- This message is sent by an automatic reply robot.
按说应该不会，ssha只在创建用户的时候才会有这个逻辑，更改密码这块儿没有这个逻辑
修改密码以后F5刷新openldap后变成ssha了
经测试发现的确会这样。
变成ssha不是项目里的逻辑，看了下应该是依赖库默认的逻辑，依赖库调用的原生接口，似乎也是这个逻辑。
回头来说，你这边是想让逻辑始终保持clear吗，这种考虑的原因是什么呢
我是在测试WIFI对接freeradius时通过本系统从钉钉获取用户登录，使用ssha就会验证失败，使用clear就可以成功，对这个逻辑不是很了解，所以就问下，我们的用户在钉钉上，所以这个项目对后期作用还比较大的
你之前是否有使用过openldap，有没有更改密码的场景，我忽然想到，好像以前使用ldap老的那个改密码组件，貌似没有变，这个晚些时候，我有时间会再看看
你之前是否有使用过openldap，有没有更改密码的场景，我忽然想到，好像以前使用ldap老的那个改密码组件，貌似没有变，这个晚些时候，我有时间会再看看
没有，我们之前并未使用ldap作为认证，最近新想的需求
这个问题，我在这里咨询过：go-ldap/ldap#517 但是没有得到什么有帮助的回复，自己也尝试研究了一下，尝试过两次，花了好几个小时，都没有什么进展(主要是没有看懂这块儿的逻辑)。暂时只能搁置。
好吧，改密码得时候系统没法再传一个clear给openldap嘛，就类似第一次同步时一样
此处调用的是三方包的方法，他的封装暂时我没看懂。
后续我会尝试看看其他地方有没有更灵活的实现吧