Bugzilla

Otherwise, this is the same as the patch in bug 1593122, still with the username message, but with one important change:

Based on Magnus feedback here, I moved the username field check to after all config methods fail. So, if the provider config.xml or ISPDB comes back with a result, we will not show the username field anymore.

I think that's *WRONG*, because we *know* that the config as given does not work. Even if the ISPDB or config.xml with automatic placeholders comes back, the config will still not work. We will show "wrong password etc.", but in reality, the username is in the wrong format. The user will try other passwords, because we do not even show a username field! This is not only a UX disaster, but also a security disaster, because the user will give multiple different passwords.

I don't know a single server in the world that puts in the concrete username here, is an Exchange server, uses HTTPS etc.. If you know any, please show me. For all cases I know, this will do the wrong thing.

Otherwise, this is the same as the patch in bug 1593122, still with the username message, but with one important change:

Based on Magnus feedback here, I moved the username field check to after all config methods fail. So, if the provider config.xml or ISPDB comes back with a result, we will not show the username field anymore. Based on what Magnus asked, this is technically the right implementation.

But that's still *WRONG*, because we *know* that the config as given does not work. Even if the ISPDB or config.xml with automatic placeholders comes back, the config will still not work. We will show "wrong password etc.", but in reality, the username is in the wrong format. The user will try other passwords, because we do not even show a username field! This is not only a UX disaster, but also a security disaster, because the user will give multiple different passwords.

I don't know a single server in the world that puts in the concrete username here, is an Exchange server, uses HTTPS etc.. If you know any, please show me. For all cases I know, this will do the wrong thing.

Otherwise, this is the same as the patch in bug 1593122, still with the username message, but with one important change:

Based on Magnus feedback here, I moved the username field check to after all config methods fail. So, if the provider config.xml or ISPDB comes back with a result, we will not show the username field anymore. This implements exactly what Magnus asked for.

But that's still **WRONG**, because we **know** that the config as given does not work. Even if the ISPDB or config.xml with automatic placeholders comes back, the config will still not work. We will show "wrong password etc.", but in reality, the username is in the wrong format. The user will try other passwords, because we do not even show a username field! This is not only a UX disaster, but also a security disaster, because the user will give multiple different passwords.

I don't know a single server in the world that puts in the concrete username here, is an Exchange server, uses HTTPS etc.. If you know any, please show me. For all cases I know, this will do the wrong thing.

This is the same as the patch in bug 1593122, still with the username message, but with one important change:

Based on Magnus feedback here, I moved the username field check to after all config methods fail. So, if the provider config.xml or ISPDB comes back with a result, we will not show the username field anymore. This implements exactly what Magnus asked for.

But that's still **WRONG**, because we **know** that the config as given does not work. Even if the ISPDB or config.xml with automatic placeholders comes back, the config will still not work. We will show "wrong password etc.", but in reality, the username is in the wrong format. The user will try other passwords, because we do not even show a username field! This is not only a UX disaster, but also a security disaster, because the user will give multiple different passwords.

I don't know a single server in the world that puts in the concrete username here, is an Exchange server, uses HTTPS etc.. If you know any, please show me. For all cases I know, this will do the wrong thing.