1031049 - Public calendar links look broken (give auth error) when they should not

Status: RESOLVED WONTFIX

(Infrastructure & Operations Graveyard :: Infrastructure: Zimbra, task)

Description

[Lukas Blakk [:lsblakk] use ?needinfo]

We have a public calendar that people are often pointed to, but internally folks will often hit an auth error because of something to do with cookies - this is very frustrating and hard to explain to people so help please :)

https://mail.mozilla.com/home/[e-mail]/Releases%20Scheduling.html is the example in question.

Comment 1

[:Atoll]

I can verify that this bug has been around for at least a few months. :limed, can we file this upstream?

Steps to reproduce.

0. Configure Zimbra to expire web UI sessions after 24 hours (or 1 hour, for testing).
1. Close all Zimbra tabs and delete all Zimbra cookies, then restart your browser.
2. Attempt to view a public calendar resource, it will work.
3. Login to Zimbra in a new tab, then wait until the web UI session expires. Do not re-login.
5. Go to mail.mozilla.com and confirm that it says 'Session expired'. Do not re-login.
6. BUG: Attempt to view a public calendar resource, it will fail.

Expected result:

The public resource should be displayed.

Actual result:

The expired auth cookie prevents access to the public resource, even though no auth cookie is required to view that resource.

Bug to be fixed:

Ignore expiration time of auth cookies when accessing public resources.

Comment 2

[:Atoll]

Notes:

This is an issue partly due to the UX when this failure occurs. Rather than displaying the 'Session expired, please re-login' page, it simply returns a blank white page with '401 Unauth' at the top.

While it is not correct to deny access based on any attribute of the auth cookie presented, the problem is made far worse due to the lack of explanation about why the user is denied access to a public resource.

Displaying the 'Session expired, please re-login' text would, at minimum, give users a chance to workaround the bug and go re-login as needed to view the resource.

(This is of no help for anyone using automation tools that fetch public resources using the main browser's cookie store, so the underlying bug remains -- auth cookie validity should not be considered when viewing public resources.)