This may be a known issue, but my searches didn’t turn up anything definitive. I have a user that is trying to use his iPad to access OOD. He is able to login and navigate the main OOD portal fine, but when he launches JupyterLab, it prompts him to login again after it starts up, and again each time he opens a notebook. I’ve found that Safari has issues with websockets, but I could replicate the issue with Firefox and Chrome on iPad. Everything works fine on a PC or Mac desktop using FF or Chrome.
We are still using Apache basic auth with an LDAP backend since Dex doesn’t provide the failed login attempt info (username + IP address) that we need to integrate with fail2ban. The OOD is version 3.0.1 and our websockify is version 0.9.0. Let me know if there is any other info needed.
I wanted to make sure this wasn’t a known issue or if there was a simple fix before I spend too much time troubleshooting it.
I’ve not heard anything yet about Ipad specific issues, but we have had some users run into connection issues using OOD 3.0 with websockify versions < 0.10.0.
That might be the first step to see if this fixes the issue, and if not we can start to look into it more.
Just tried using websockify 0.10.0. It didn’t seem to make a difference. I used Chrome and Firefox on iPad to test with. Continued to work fine on PC/Mac using Chrome or FF.
Interesting. I just used an iPad pro with OOD 3.0 and was able to launch a Jupyter Lab and connect. I only tested on FF at the moment.
The iPad itself was on iPad OS 16.6. Do you know what version the iPad that is not working is on?
Also, when the login shows up for them in Jupyter, are you able to enter the information to get in? Or are they always locked out with this login page?
I think my iPad is too old to support 16 and higher. I’m running iPadOS 15.7.8.
I tried on my iPhone 13 too with the most up-to-date iOS (16.6), and it did the same thing.
Are you using Apache httpd basic authentication or something else like Dex? I think it is related to the basic auth since it seems that whenever I open something new … new app, new notebook in Jupyter … it reprompts for my credentials.
Do you know if that logs username and IP address on failures? That is the reason we didn’t use Dex because it only logs usernames on authentication failure. We use fail2ban to block IPs with too many failed logins.
It looks like someone has made the community request to Dex to have this, but at this time it does not:
Interestingly, it’s another OOD user that made the request. I’m sure they would like to hear from you as someone that wants to use this, but who has a policy that won’t allow it because they don’t integrate with fail2ban yet. It might provide some motivation.
If the policy is worded such that you just need to log failed attempts after so many tries and block, I believe Keycloak has those features built-in. But, you would not directly be using fail2ban, so if you must use fail2ban it may not be any better. Depends how the policy is worded I’d say.
Yeah, gshamov filed that feature request on my behalf . I had brought up that issue when Dex was added to OOD 1.8. I’ll try one of the other authentication mechanisms like Keycloak, etc. again.
I have taken to recommending Keycloak as I use it myself locally and think it’s pretty simple, but it also gives you an ability to impersonate a user. This can be huge for admins to troubleshoot issues. There’s been requests to have OOD offer this functionality, but I believe this belongs with the authentication service and not OOD for many reasons I’ll not dive into.
I am not sure anything has changed since the last post, but I am experiencing the same problem with the HPC OpenOnDemand service from an university I collaborate. Any idea on how to solve this issue from the user side?
We ended up implementing OpenID (without Keycloak) directly to our identity provider. It took a bit to get it to work, but once we did, it provides single sign-on with our other apps that use that identity provider. It solved the iPhone/iPad reauthentication issue that basic auth method had.
I see. I understand that this is not something I could do as an user of the service but rather suggest to the maintainers. I wish there was an easy solution…
Safari/webkit maintainers? Safari doesn’t like you running Basic authentication scheme. You can either use a different authentication (you really should! basic authentication is very insecure) or use a different browser like Chrome or firefox.
Sorry - as you aren’t the OP I’m not sure what your setup is. What’s the authentication you use? I don’t think there’s a solution on your side save for using a different browser. And as you indicate it may not even work then (though that’s surprising, i thought it was just a Mac/Safari thing).
In any case - if you use Basic authentication I would definitely suggest you lobby your administrators to upgrade to OIDC or similar (Shibboleth, CAS, etc) as it’s not just this bug, but Basic authentication is very insecure.
. I had brought up that issue when Dex was added to OOD 1.8. I’ll try one of the other authentication mechanisms like Keycloak, etc. again.