Re: [Evolution] Evolution-ews and VPN-connection

[Milan Crha <mcrha redhat com>]

On Wed, 2020-01-15 at 08:48 +0100, Wiethoff, Helge via evolution-list
wrote:
> "Source 'helge...@...' doesn't support prompt for credentials"

        Hi,
the error usually means that the provider wants to connect to the
server, but the server rejects connection and asks for credentials.
That makes sense for accounts configured in GNOME Online Accounts
(GOA), because GOA is responsible to provide the credentials.

I'm only guessing here, but I'd think that the running connection to
the Exchange server terminated, possible due to inactivity, when the
server disconnects. Later on, when you sent the message, evo-ews tries
to use this stale connection and it failed. It didn't try to reconnect
silently, it possible looked like an issue with credentials, thus evo
wanted to ask for the credentials, but it failed. The failure
invalidated the connection also on the evo-ews side. The new attempt to
send the message resulted in a clean connect, just like right after
start (which tries stored password first).

I do not know which part is faulty here. It can be evolution-data-
server or evolution-ews itself. Or maybe evolution. Hard to guess. That
would need more testing.

Maybe there could be a workaround, to keep the connection alive you
might need to set "Check for new messages" interval to a value, which
is lower than "automatic disconnect timeout due to inactivity" set on
the server.

> Should i try to find this error with EWS_DEBUG=2 or CAMEL_DEBUG=all ?

Definitely do *not* use CAMEL_DEBUG=all. I do not know anyone wanting
to read all of that output. I'm not sure whether it would be shown in
the EWS_DEBUG=2 log.

In any case, I agree that this is a bug and should be fixed. Would you
mind to file it, please? I'd start in evolution-ews [1] and move it to
the right place once it'll be known where the actual error is. The
thing is that you see this error when using Mail, but other parts
(calendars/books) are/can-be affected as well.

By the way, are you really able to reproduce this reliably when you
connect or disconnect VPN? If only with the disconnect of the VPN, then
it can be that evo-ews connected to the server through the VPN, thus
the VPN disconnect invalidated that connection, similarly as the
inactivity timeout, though not exactly the same.

        Bye,
        Milan

[1] https://gitlab.gnome.org/GNOME/evolution-ews/issues/new