Cypht: Improve interface so user is warned about the need for App Password for Gmail-IMAP

[jeanpaulHamuli]

Improve interface so the user is warned about the need for App Password for Gmail-IMAP

Pullrequest

Issues

• fixes Authentication Failed #497
• relates https://avan.tech/item64974-Cypht-Improve-interface-so-user-is-warned-about-the-need-for-App-Password-for-Gmail-IMAP

Checklist

• None

How2Test

• Settings->Servers
• After adding an SMTP or an IMAP server then write in the username field an email address with a Gmail domain

Todo

• None

[marclaporte]

@jeanpaulHamuli Some have a Google-powered email that is not @gmail.com, so can you find a way to cover this use case?

[jeanpaulHamuli]

Yes, I'm looking for other possible forms of Gmail address, then implementing a general solution.
Better if I find a google API to check if it's for them or not

[marclaporte]

When users are adding an email via https://github.com/jasonmunro/cypht/tree/master/modules/nux we know which provider it is. And if the email is set up manually, we can compare IMAP/SMTP settings: https://github.com/jasonmunro/cypht/blob/master/modules/nux/services.php

[jeanpaulHamuli]

Okay, I'm working on it @marclaporte

[jasonmunro]

Appreciate the work on this, couple things:

• One of the URLs has a long odd argument that looks like some sort of tracking id, likely should be removed
• These notices need to be wrapped in ->trans() otherwise they can't be translated from English (note you have to deal with any embeded HTML like links by substituting them in after the trans() otherwise they are not long HTML)

Happy to add more details if you need guidance. Thanks again!

[jeanpaulHamuli]

Thank you for your comment @jasonmunro,
I'm done with what you asked, only I'm not sure I fully understand this (note that you have to handle any embedded HTML like links by replacing them after the trans() otherwise they're not long HTML)

[jasonmunro]

Thank you for your comment @jasonmunro, I'm done with what you asked, only I'm not sure I fully understand this (note that you have to handle any embedded HTML like links by replacing them after the trans() otherwise they're not long HTML)

sorry should have said "no longer HTML". The trans() call also applies htmlsafe, so any embeded html will end being rendered as text. I see you made multiple trans() calls as a way to work around that but the problem there is that is not easy to translate as it is bits of text that may not line up in other languages. The correct way to do this is to use %s placeholders and sprintf():

sprintf($mod->trans("long string to translate with a link here %s"), link)

[jeanpaulHamuli]

Ok, I understand the idea, but the implementation is not too clear to me.
You mean like that taking my case?
sprintf($mod->trans("long string to translate with a link %s"), <a href="https://developers.google.com/gmail/imap/imap-smtp" target="_blank">here</a>)

[jasonmunro]

Ok, I understand the idea, but the implementation is not too clear to me. You mean like that taking my case? sprintf($mod->trans("long string to translate with a link %s"), <a href="https://developers.google.com/gmail/imap/imap-smtp" target="_blank">here</a>)

Almost, I would go with this:

return '<div class="warning_message">'.
    sprintf($mod->trans('Make sure your %s less secure app access %s '.
    'and your App password are enabled. For more details about the '.
    'configuration of IMAP, POP and SMTP click %s here %s'),
    '<a href="https://myaccount.google.com/lesssecureapps" target="_blank">', '</a>',
    '<a href="https://developers.google.com/gmail/imap/imap-smtp" target="_blank">', '</a>').
    '</div>';
    ```

[jeanpaulHamuli]

It's done.
Thanks @jasonmunro!

[jeanpaulHamuli]

Is there anything else or a fix we need to add to this PR to make it more perfect to be merged?

[marclaporte]

@jeanpaulHamuli GitHub says: "This branch cannot be rebased due to conflicts"

[jeanpaulHamuli]

I don't understand why they say that, there is no conflict in this branch @marclaporte

[marclaporte]

@jeanpaulHamuli ok, we'll see what @jasonmunro says

[marclaporte]

Big picture about "On May 30, 2022, you may lose access to apps that are using less secure sign-in technology"
https://www.reddit.com/r/google/comments/t5q0f4/on_may_30_you_may_lose_access_to_apps_that_are/

[jeanpaulHamuli]

The removing of the less secure app access feature puts this PR at a serious disadvantage

[dumblob]

Disadvantage? You mean this PR becomes kind of void as the less secure access does not work any more, right?

[jeanpaulHamuli]

Yes, but since we still have Gmail in the app, we can improve and warn the user that they cannot use gmail account in less secure app

[dumblob]

Oh yeah, that is true. But I do not see any disadvantage there - it is as it is (because Google mandates how things will be).

[marclaporte]

I have a Google for domains account, and it still works. But one of my Gmail accounts stopped working and I discovered this issue: #573

[marclaporte]

@adrienmaloba Please revisit this, evaluate and make a recommendation.

[marclaporte]

We are going to put this (and all Cypht-Gmail related work) on hold for a few months, as we focus on the release of Cypht 1.4 and improving Cypht for standard IMAP and SMTP.

This being said, I welcome anyone in the community to contribute code, bug reports or documentation with respect to Gmail and Cypht. There are a lot of Gmail accounts out there.

I use Cypht for a Gmail account (via IMAP) and it works fine. The only issue is that I need to sort by "Arrival Date" instead of "Sent Date".

[marclaporte]

You mean this PR becomes kind of void as the less secure access does not work any more, right?

Indeed. Closing this.

Let's focus on "Review the whole process/code/documentation for Cypht to work for Google and Microsoft's email offerings" here: #776