Perspective session iOS redirect issue

Hello,

We’re having an issue with using default identity provider only on iOS devices. On all other devices when clicking “Continue to sign in” we’re redirected to a page where we can enter a username.

On an iPhone running iOS 13.1.2 in both the Perspective app as well as in safari / chrome when clicking “Continue to sign in” we’re redirected to a blank page.

Working with support they determined that for some reason in the safari / chrome apps, and i’m assuming in the perspective app, the url is being truncated and removing everything after the .html (all the redirect data)

I found a colleague with an older iPhone running 12.4.1 and the authentication redirects work perfectly fine on his phone in both the browser as well as in the app.

I found a hacky way to get passed the blank login page by emailing myself the direct link to the login page and using iOS link previews to enter my user and password.

Has anyone else running iOS 13.1.2 ran into this issue?

-Matthew

Hi @Matthew.gaitan
I believe this was fixed in the latest iOS release.

I am still seeing this issue on iOS.

Hi @Matthew.gaitan and @jpark -

Do requests between your phone and Ignition go through any proxies?

Mine goes through an AWS load balancer. It works on pc browser and Android browser/native app.

Ours goes through a load balancer. It also works perfectly via the pc and android browser / app.

We were told it had to do with our configuration and to get back to support after updating our load balancer to see if that fixed the issue.

Hi -

The pattern I have seen many times is a mishandling or misconfiguration of redirects by SSL offloading proxies. This is what I have seen:

1. Browser ---(https)---> Proxy ---(http)---> Ignition
2. Browser <---(3xx)--- Proxy <---(3xx)--- Ignition
3. Browser ---(http)---> Proxy
4. Browser <---(3xx)--- Proxy
5. Browser ---(https)---> Proxy ---(http)---> Ignition
...

Numbers 3 and 4 above can be avoided if 2 were to redirect straight to 5. We use hash params for carrying state from our OIDC authorization endpoint to our Authentication UI and while most browser engines carry along this state across multiple redirects, Safari (iOS and macOS) does not.

We’ll look into other strategies for carrying state across these endpoints in a secure way, but for now, look into fixing the proxy redirect issue first (since this is something you’ll want to fix anyway). I’ll bet it will fix the problem.

The latest nightly build should fix the redirect issue mentioned in this thread, even if a proxy adds unnecessary redirects.