Possible MacOS Sonoma/Safari client connection issue with OOD 2.0.32?

[cjh (Chris)]

Hello,

We’re currently running OOD 2.0.32 on RHEL 8 (though I’m hoping to upgrade soon) and I’ve now received two complaints so far from MacOS users being unable to make a connection to our OOD server with Safari.

The first reported connections freezing when using Sonoma 14.1 and Safari 17.1 on a newly provisioned system. Eventually we determined that they had no problem at all when connecting with Chrome. Upgrading to Sonoma 14.4 and Safari 17.4 made no difference, Safari hung, Chrome worked…

At that time a coworker running Sonoma 14.3 and Safari 17.3 was able to connect to our OOD page without any problem.

Entries from the httpd log at the time the user tried to log in with Safari showed only request timeout entries:

146.189.60.182 - - [06/Mar/2024:11:12:28 -0500] “-” 408 - “-” “-”
146.189.60.182 - - [06/Mar/2024:11:18:14 -0500] “-” 408 - “-” “-”
146.189.60.182 - - [06/Mar/2024:11:19:03 -0500] “-” 408 - “-” “-”

My first thought was that there was some 3rd party software trying to protect against malicious websites that was dropping packets after the connection started being established, but the fact that Chrome from the same system makes me doubt that as a possible source.

I put out a warning message in several places, as the issue was preventing the user from even getting the authentication prompt (we use OIDC with Azure AD), so impacted users wouldn’t see the warning when trying to connect directly.

Today I received an email from a different user unable to connect using Safari 17.4.1 on Sonoma 14.4.1, but could with Chrome on the same system. Their issue seems a little different, “Safari DOES allow me to login to OOD and request an RStudio session. But the RStudio tab never opens or gives a server error.”

My first thought was that there was some 3rd party software on the system trying to block malicious websites might be dropping packets after the connection started being established, but the fact that Chrome from the same system works fine seems to suggest that wouldn’t be the case.

I’m hoping that upgrading to OOD 3 may resolve the problem, but given how odd the issue seemed, I thought it might be worth putting this out to see if anyone had encountered similar issues?

Thank you!

[hrandquist]

Hello! I am currently working on attempting to reproduce your issue(s). We do have a bit of history having issues with auth in Safari, however, I haven’t heard of this specific issue myself. Will update you when I know more or decide this warrants a GitHub issue. In the mean time, something to look into, perhaps it’s possible there are conflicts with browser extensions?

[hrandquist]

So after running through a few attempts to reproduce any of these problems, I haven’t been able to, but I have some questions and suggestions.

1. For the issues with RStudio either not opening or giving an error, it would be useful to know what the error is or if these users might have attempted to connect to RStudio in a different tab or browser without closing that before receiving this error. We do get server crashes, white screens, or session errors in situations like that, so it’s a possibility.

2. I was not able to get a 2.0 OOD instance running yesterday, and quite frankly don’t think this has to do with your OOD version anyway. Do you have anymore Apache configs on top of or different than what OOD provides?

3. It’s a long shot, but asking users to clear their cache could be a helpful sanity check.

[cjh (Chris)]

Hello, thanks for looking into this, and my apologies for the delay in responding.

Regarding #1, I’ve emailed to ask if they remember the server error, or if they could try and reproduce it and let us know.

Regarding #2, we aren’t making any changes to the apache config ourselves, I believe all the customization is handled through the /etc/ood/config/ood_portal.yml file.

Regarding #3, I’ll suggest clearing the cache if/when we have someone encounter with an issue next.

I appreciate the efforts, thank you very much!