More configurability for state cookies and better defaults for unathenticated actions with respects to state cookies

[studersi]

The state cookie does not expire until the end of the session. However, generally the state cookies are only needed for a few seconds, until the login workflow has completed. There are cases where state cookies are accumulated in the current session. Once the limit of 7 is reached, the website becomes unavailable for the user-agent until the session is terminated, because requests are answered with 503. This can be mitigated to an extent with OIDCStateMaxNumberOfCookies 7 true. However, this can create loops of very quick infinite retries.

This behavior can be quite jarring to the user experience.

In our estimation this is mostly due to background requests that are incorrectly being redirected to the login page instead of returning 401. This case often occurs because applications do not declare that the background requests are XHR requests and add */* to the Accept header.

A default behavior along the lines of the following configuration, taking the Sec-Fetch-Mode header into account, would likely mitigate a lot of problem cases automatically because the Sec-Fetch-Mode header is set automatically by the browser.
OIDCUnAuthAction 401 "%{HTTP:Sec-Fetch-Mode} != 'navigate' || %{HTTP:X-Requested-With} == 'XMLHttpRequest' || ( ( %{HTTP_ACCEPT} !~ m#text/html# ) && ( %{HTTP_ACCEPT} !~ m#application/xhtml\+xml# ) && ( %{HTTP_ACCEPT} !~ m#\*/\*# ) )"
Currently, this has to be configured explicitly.

Further, it would be great to have additional options to configure the behavior when the limit of state cookies is exceeded. For example it would be helpful to configure the status code and to configure the expiration of the state cookies in order to lessen the impact of the problems described above.

[zandbelt]

I agree with changing the default auto-detect algorithm and the Sec-Fetch-Mode header suggestion was added in ee891b1

[zandbelt]

ah, but reading the docs more closely it seems indeed covered by no-cors...

[studersi]

I was not aware that for iframes, the Sec-Fetch-Mode is also navigate. In that case I agree that it would make sense to check also if Sec-Fetch-Dest is not document if the header is set.

[studersi]

In fact, I just checked here: https://www.w3schools.com/html/html_iframe.asp. For loading the page, there is a request that has the following combination of headers:

Sec-Fetch-Dest: iframe
Sec-Fetch-Mode: navigate

[zandbelt]

thanks for confirming; since this is a potentially breaking change it will be part of the upcoming 2.4.10, see: 143b63b

[studersi]

Ok, thanks.