Failed to start the session because headers..

Also having the same issue when upgrading from 3.x to 5.0.7

I have been able to consistently reproduce it by having a destination parameter in the url, once you press on the login with o365 button you will already get it before even returning from the azure login.

If you would remove that the error is not present.

I'm encountering the same issue where some requests are being redirected to "/o365/login?destination=":

The normal link in the main menu, "https://foo/example," is being redirected to "https://foo/o365/login?destination=example." As a result, the browser is triggering the ERR_TOO_MANY_REDIRECTS error for the users.

This case is really ambiguous. At this point, I'm not 100% sure if the problem described in the last comment was caused by the o365 module.

Here's what I did to track the problem:

1. Uninstalled the o365 sub-modules.
2. Uninstalled the o365 main module.

However, the error persisted.

3. Uninstalled all the contrib modules.

The error still persisted with just the core module. :(

4. Restarted all the app containers.

After this, the issue was no longer present.

5. Restored a backup of the database with all modules, including the o365 modules.

The problem is not present any more.

Given these findings, I have some theories to share:

1. The issue might have been caused by an error during login, creating a "mid part login" state where some components had an active cached session while others did not. This could explain why some links were redirecting to the ?destination URL parameter.

2. Could there be a session cache at the backend level affecting default routing after logout? Perhaps the "mid part login" occurred during logout and persisted through subsequent logins.

3. Other cache layers such as WPA, Varnish, or Big Pipe might also be involved.

In my situation Big Pipe is involved indeed.

I attached a patch and MR to solve the issue that worked for me. It was caused by the "Automatically redirect users to the SSO login page" on the page /admin/config/system/o365/settings/sso which does a redirect on the login form.

My solution is based on https://www.drupal.org/project/redirect_after_login/issues/3214949#comme... 🐛 Headers have already been sent after upgrade to Drupal 9.2 (can't login) Fixed where it states you should avoid redirect in hooks.
If you don't want to introduce the service there are also options to alter the url::formRoute on https://git.drupalcode.org/project/o365/-/blob/5.0.x/modules/o365_sso/o3...
to add options like excluding big pipe.

HTT:
1. Enable o365_sso & big_pipe
2. Configure o365 with azure like usual.
3. Go to /admin/config/system/o365/settings/sso and enable "Automatically redirect users to the SSO login page"
4. Click on the login link (or go to the /user/login) and get redirected to Microsoft.
5. Notice that even without actually logging in it already logs the "headers have already been sent"

For me the MR works. I've asked @batigolix to have a check as well.

Drupal Core = 10.2.6
0365 = 5.0.12

I tried both the headers-already-sent-3422331-10.patch and the MR diff and still have errors in the logs. I can confirm the this is how to replicate the issue, but seems like it still needs work.

HTT:
1. Enable o365_sso & big_pipe
2. Configure o365 with azure like usual.
3. Go to /admin/config/system/o365/settings/sso and enable "Automatically redirect users to the SSO login page"
(switch to an incognito browser)
4. Click on the login link (or go to the /user/login) and get redirected to Microsoft.
5. Notice that even without actually logging in it already logs the "headers have already been sent"

I've just tested this again with Drupal 10.3.6 and the dev branch of the module. I don't see the error message anymore with the provided steps. Can anyone confirm that is is now (somehow) fixed?

I'm not sure about Drupal 10, but FWIW I'm still experiencing the issue consistently in Drupal 9.5.11 with o365 5.0.13.