No such flow exception help

[Wessel, Keith]

We're charging ahead on this, for better or worse, starting with a default for the sameSite condition of shibboleth.Conditions.TRUE based on the fact that, according to our research, browsers have at least partially implemented same site functionality since 2018, and if you have a 4-year-old browser, you probably have other problems. We're doing some log analysis to see how many users this could potentially impact, of course.

Suspecting that we'll be shooting ourselves in the foot with this decision, I want to be ready to start coding a condition bean that keys off of the user agent string to not enable the same site servlet filter for older browsers.

So, here's my dumb question: how do I obtain the user agent? Do I get it from the headers passed in by the client using HTTPServletRequest.getHeader()? Or is there a cleaner way?

Thanks,
Keith




-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu> 
Sent: Tuesday, August 9, 2022 2:31 PM
To: Shib Users <users at shibboleth.net>
Cc: Wessel, Keith <kwessel at illinois.edu>
Subject: Re: No such flow exception help

On 8/9/22, 3:26 PM, "users on behalf of Wessel, Keith via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:

>    I'm not sure why this isn't happening with our proxying to ADFS but 
> it is to AzureAD. Different headers from Microsoft's cloud servers, perhaps?

Common domain.

> For proxying situations like this, the only solution is to enable the 
> samesite filter, correct?

Or get people to dump Chrome and Edge, because this isn't the last time they're going to pull this. It's still not an RFC, last time I checked. That should scare everyone.

> And if we don't want to make users with older browser suffer, we'll 
> need to come up with the user agents for which we want it to fire? 
> Just making sure there's no other option before I go down this road.

None I know of.

-- Scott