Greetings, Evolution users and devs.
Suddenly I have begun getting errors when trying to create events on my EWS office calendar, both with and without Attendees. The error says “Failed to create an event…” and then:
Cannot create calendar object: InvalidAuthenticationToken: Access token is empty.
I’m using Evolution 3.52.4 (by Flathub.org) on PopOS 22.04 LTS.
Thanks in advance for any suggestions for how I can further diagnose or resolve this issue.
Hi,
it looks like some problem with the OAuth2 token, but I cannot tell
whether when storing it (or better reading it from the libsecret store)
or when renewing it. I do not see it myself that often, but it strikes
from time to time. As soon as I try to debug it it cures itself. I
suspect the token expired and there failed to get the new token, but
the error was not propagated properly to the GUI and it was just tried
with no OAuth2 authorization information, which the server rejects.
Does it help if you switch to the Calendar view, right-click the EWS
calendar and pick Refresh from the context menu, please? It should
reconnect and eventually refresh the OAuth2 token. Maybe try it twice,
as the first try will disconnect from the server and the second try
will connect with a new token. Alternatively, does it help if you’ll
try to save the event again?
It can be different if you create an Online Meeting (because it uses a
Microsoft Graph API connection, instead of EWS connection), but as you
said it does this also when you create a regular event, not a meeting,
then we can skip this for now.
If you are able to reproduce this reliably, please try to run these
commands:
flatpak kill org.gnome.Evolution
OAUTH2_DEBUG=1 flatpak run org.gnome.Evolution
from a terminal and then just use Evolution. It’ll show what it does
when accessing the OAuth2 server. Do not share the output anywhere, it
contains private information in a form of the tokens, which can be used
to access your account data, just check whether there will be any error
message around the time you’ll face this failure in the Evolution. It
might not be necessary the last line in the log, it can be several
lines above.
Bye,
Milan
Thanks so much for your reply. It’s indeed strange. The error is occurring on only 1/3 computers where I use Evolution with EWS.
When I try to refresh the EWS calendar on the calendar screen, I get this error up top:
The calendar backend servicing “Calendar” encountered an error.
The reported error was “InvalidAuthenticationToken: Access token is empty.”.
I tried this multiple times, including after restarting the app.
Running in debug mode as you recommend, I got continual errors (appearing constantly, seemingly many times a second):
[BEARER] 2024-09-23 21:29:53.558 - e_soup_auth_bearer_get_authorization: bearer: [REDACTED] token: [REDACTED] expired: 0 authenticated: 1
That alternates with a similar message with e_soup_auth_bearer_get_authorization and some different vales.
Hi,
that is not an error, it’s a debug message. It shows the chosen token
is not expired and it is properly authenticated, thus it should work
when passed to the server.
I’ve not much idea what could go wrong. Maybe open the EWS mail account
Properties and set it to use HTTP/1 on the Receiving Options tab. Then
close evolution and run the two flatpak commands from my previous
comment, to restart Evolution and its background processes, to ensure
they’ll use the new setting.
You mentioned it’s one machine of three, do they all use the same
Flatpak version of the Evolution and the GNOME runtime? Something like
the following command can list what you’ve installed:
flatpak list --columns=application,version,branch,runtime,active |
egrep "org.gnome.Evolution|org.gnome.Platform"
where the line with org.gnome.Evolution hows you which runtime it uses
and at which commit it is, and there is also a corresponding
org.gnome.Platform line with the referenced platform version (branch)
and its current commit. The commits are at the last column and they
should match between the machines.
Bye,
Milan
Yep, they’re all on current flatpak, 1.11.0 stable. Hopefully it will resolve itself somehow.
Let me know if you can think of any other ideas for diagnosis. I really appreciate your support and your work on this important project!
Yep, they’re all on current flatpak, 1.11.0 stable.
Hi,
it was not about the flatpak version, but about the version (and
commit) of the app and its runtime you’ve installed in that flatpak.
They might not differ if you keep them all up-to-date, it’s to check
just in case they differ.
Let me know if you can think of any other ideas for diagnosis.
Did you try the HTTP/1 setting on the affected machine?
There used to be a problem with libsecret not passing changes in the
keyring from one process to another. It had been worked around in the
Flatpak by building an older version of the libsecret, which did not
suffer of this problem. It might not be the problem here, especially if
you’ve the same app version and the runtime versions on all the
machines.
I do not think the host system and the libraries versions matter here,
though the libsecret can talk to the host-system gnome-keyring-daemon
through D-Bus.
Bye,
Milan
Oh gosh, I’m so sorry. I just pasted the wrong value. Yes, v.3.52.4 on all the machines.
I don’t see where to do the HTTP/1 option:
But as we’ve discussed might happen, the problem just resolved itself. I’m sorry not to be able to provide more info on it!
It does not look like options for an EWS account (server type “Exchange Web Services”), the EWS accounts have there many more options. I suppose you’ve it configured as a “Microsoft 365” account instead.
That changes things a bit. The problem is not fixed, I see it from time to time, mostly for the Microsoft 365 Tasks. I did not get to debug it yet, also because it’s only sporadic and because the reproducer takes hours. I’d appreciate a bug report at Issues · GNOME / evolution-ews · GitLab , thus, once I get to it, a future fix could reference it.
Oh gosh—apologies again. I can never keep these MSFT systems straight! Thank you for your patience with me.
I’ve just posted an issue here.
Thanks again for all your work on Evolution.
