I’ve downgraded to 6.0.21372.0 and everything works fine. The big difference is that I can enter my corporate email address AND the GoogleApps password, and with the 6.0.21372.0 version, emClient finds all configurations INCLUDING calendar and chat.
With the latest versions (6.0.22328 and previous two) one only has the option of entering one’s email address, but not the GoogleApps password UNLESS one configures it as “Other Email”…in which case the configuration does not find Calendar or Chat. Without entering a GoogleApp password, the authentication screen comes up with a blank web page window.
If I configure it to use my domain credentials, it does hit the corporate mail address, but authentication is denied, likely because our corporate setup uses ADFS, not OAuth.
Hello Michael, please make sure to use the latest version of eM Client, as the old authentication method will be deprecated from Google’s settings soon and you may not be able to authenticate with the account using any other option. Unfortunately it is no longer possible to setup a Gmail account using both your email address and password. Gmail has introduced a new option to authenticate with the server using OAuth, this will be serving as the authentication method with the server from now on.
If you want to setup a POP3 account, you can do so using the Other settings or in case you’re using a branded version of Google Apps (e.g. Virgin media email), you will be forced to setup the account using this option as the autodiscover preferences will always bring up the OAuth option to setup your other services.
As I’ve mentioned there’s no other option to authenticate with synchronization services on your gmail account than the OAuth option.
Thank your for your attention Paul.
I have not received any notice from Google or our internal administration that https://support.google.com/accounts/answer/72709?hl=en Google Apps (for business) will change its authentication options for devices to connect to internal user accounts, which up to now has all been with a Google Apps password issued by Google themselves: https://support.google.com/accounts/answer/185833
Given that for now, Google requires a Google App password, and given that Google Apps are administered by the internal infrastructure of the enterprise, for which non-OAuth options are still available, I am disappointed that emClient is not supporting the identity/authentication dialog found in the 6.0.21372 version.
Also, as I mentioned in my post, using the “Other Setting” option does work with the Google Apps password, but only for email, not for calendar or chat. The identity options for calandar and chat do not even come up when using the “Other Settings”…and yet the authentication for those services is one and the same.
I will continue to use the previous version until it breaks, at which point my premium, lifetime license will be wasted and emClient will have lost another customer that was very happy with the product until now.
Hello Michael, as I previously suggested it is unfortunately not our decision to adjust our settings to Gmail’s, Gmail has switched the authentication method and in order to authenticate with the server and support the use of this service, we had to include this option too.
Sorry about the inconvenience, however this is a standard set by the provider not eM Client.
Paul, I know it is not your fault. I understand that the emClient team is reacting to a protocol change issued by Google. As a .Net developer, I understand this can be challenging.
I cannot write a definitive summary of what is happening without doing a lot of research into oAuth, which I do not have the bandwidth to do right now. But from the little I have researched, it seems to me that there are two problems here:
-
emClient must talk to the Google Api to retrieve and send email. The Google Api now only allows the oAuth protocol for passing in credentials. You can no longer use a password to get authorized by the Google Api.
-
emClient needs to have the user log in to GMail in order to obtain the credentials/token that it can pass to the oAuth service. A user still logs in with his password. A user does not “log in” with oAuth".
So problem #1 is an application-to-application problem that ought to be transparent to the user. Just like when I log into StackOverflow and it says “Log in with your GMail account” and I click the button and “poof” I am logged into SO.
Problem #2 is what is affecting your client base. It seems your team has chosen to bring up a web page for users to log into their GMail account as part of the identity/authentication setup. While this will work for mainstream GMail accounts, it will not meet other scenarios, such as Google Apps for Business where the users login page will be behind an intranet wall, and perhaps be customized by a local infrastructure.
For such scenarios, I believe the Google Apps password is still a legitimate login protocol that is not going away. Perhaps the team does not yet know how to get a credential they can pass to the Google Api from a user logging in with the Google Apps password, but the log in scenario is still legitimate.
I hope the final take is that you communicate to the development team the need to obtain user credentials from a login scenario “other” than a web page. Or…perhaps you allow the user to specify their intranet login page so they are not restricted to the emClient “best guess” logic.
Best of luck.