Hi,

1. Its not a good idea to change password formats frequently, yes it works but you should decide up front what you will use and then change it but don't change it back and forth.

Clear Text and Encrypted passwords can be recovered using the password recovery from the profile page (assuming smtp is properly configured so it can send the password by email.

Hashed passwords can not be decrypted, so password recovery is not possible, a password reset feature is needed for hashed passwords but is not currently implemented unfortunately.

So when you change from clear text to encrypted the existing password is encrypted, if you change back to clear text it would be decrypted, but once you have changed to hashed decrypting is not possible so if you change back to clear text a random password is generated and you would have to recover it or look it up directly in the db in mp_Users. If you change from hashed to encypted a random password will be generated then encrypted and stored in the db, it can be recovered by the recovery email but you can't look it up in the db because its encrypted there.

Since you manually changed back to clear text in the db, then you need to manually put a clear text password on the user in mp_Users in order to login again.

Be aware (since I know your other post is about ldap) that when using ldap with version 2.2.7.9 you need to leave password format as clear text. We do not store the ldap password in the db at all, we only pass it to the ldap server for authentication, if it passes authentication we assign a login cookie and the user is logged in. There is a minor bug in 2.2.7.9 where if password format is set to encrypted or hashed and using ldap, then it gets encrypted or hashed before it is passed to the ldap server and therefore login fails at the ldap server.

2. Sounds like the IIS site is configured for Basic or Digest Authentication and it throws this popup before any mojoportal code is executed. For an internet site you should configure it for Integrated Windows and Anonymous and not use digest or basic. Basic particularly is very insecure and its dangerous becuase you enter domain credentials and they are not encrypted across the wire fromthe client to the server. I would not use the anonymous user for the db connection. I would use a sql user and remove the anonymous user from the dbo group.

Hope it helps,

Joe

I will see if I can replicate the problem.

I left out one step, after you changed it back to clear text in the db, it was still cached in sitesettings in memory so it still thought it was configured as encrypted and therefore login failed. To clear the cache, you can touch Web.config by type a space in it and save. This will recycle the app and clear the cache.

Are you sure your web server is not behind some kind of proxy server that may be imposing the extra login dialog? Its also possible if the web server is a member of a domain that some settings are being pushed down by group policy.

Best,

Joe