The most frustrating part of maintaining a third-party system is when it throws an error you can’t debug. Case in point, I’m working with DNN 9 and a user is trying to change their password and they get this error:
Your new password was not accepted for security reasons. Please enter a password that you haven’t used before and is long and complex enough to meet the site’s password complexity requirements.
DNN Resource File
I did what any good programmer does and hit the search engines with the exact text and found out the error was logged and fixed.
Next step, upgrade to the latest stable DNN.
I still got the error. So much for “logged and fixed.”
This next part is for anyone who wants to dig in and get a real answer on what’s causing this problem, but if you just need to know how I fixed it, skip to the last section.
DNN Source Code
I dug through the DNN source code, which is no easy task because I still haven’t figured out how to debug the code. All I can do is search for keywords and hope I stumble on the answer. I found the full text of the error in the SharedResources.resx file. I used the key name to find out where it was used in the code.
What I found in the UserController.cs is that this particular error is the “give up” error. At least, that’s what I call it. The “give up” error is the final response when the code determines there is definitely something wrong, but can’t figure out exactly what’s wrong.
The previous errors are the password includes invalid characters, the password isn’t long enough, the password isn’t complex enough, the password has been used recently. Until finally the code throws up its digital hands and replies with all of them. Basically saying, “It’s got to be one of these.”
Multifactor
We’re using a third party multifactor from Brandon Haynes. It’s an old, but I’ve upgraded it for the newer DNN code. I have one site using the same DNN code base that changes passwords just fine and isn’t using the multifactor. I have another site using a more recently updated version of the two factor that would also change passwords without a problem
So, I upgraded the multifactor on the offending site.
Still the same error.
Web.Config
After a great deal of frustration, I realized it must not be the code base, or the multifactor, or even the database given that I had upgraded DNN. I turned to the web.config file. Comparing the whole thing was daunting, so I narrowed it down to just the ASPNet Membership provider sections.
I discovered in the ASPNetSqlMembershipProvider section that “enablePasswordRetrieval” and “passwordFormat” had different values. I changed these values and now I can change passwords.
This leads to my new question:
Why does it work?
I don’t know. It hasn’t had a detrimental impact on any other password related functions. Although I didn’t create a new user. I’ll have to figure all that out later unless someone else knows why this worked and the ramifications. Let me know in the comments.
The Solution that Worked for Some Reason
In the web.config file, find the ASPNetSqlMembershipProvider section.
Change the following parameters to these values:
enablePasswordRetrieval="false" passwordFormat="Hashed"
On the Server page of the PersonaBar; clear cache and restart the site.
You should be able to change passwords now.