redbaron
commented
4 years ago from client side, IAP is quite similar to captive portals many free WiFi hotspots use: upon request redirect occurs, where user must do some actions on a page before redirected to originally requested URL.
Difference is that captive portals register MAC address, so it is possible to "complete" them using another app (like browser), but for IAP there must be shared cookie storage between app and IAP login window. It is unlikely that MM app can share cookies with installed browser, so login page should be displayed in-app.
matthewtckr
amyblais
Summary
When a mattermost instance is located behind Google's Identity-aware proxy the 'ping' endpoint gets redirected to a Google login page.
Expected: User sees a popup / open browser window to Google authenticate and enable transparent communication through the proxy
Actual: Ping fails, mattermost mobile claims the server is unconnectable
Environment Information
Steps to reproduce
Our mattermost is behind IAP, a random example of an IAP URL is: https://zzz.qa.g.nakhoda.ai/
When you go to zzz.qa.g.nakhoda.ai you're redirected to a login page on accounts.google.com - once authenticated with a permitted google account you're returned to https://zzz.qa.g.nakhoda.ai/ with no indications a proxy is in place
Expected behavior
The mobile app says "cannot connect to the server. Please check your server URL and internet connection"
Possible fixes
In the core library where the ping is happening, handle a redirect and show it to the user in case it's for authentication, then follow login redirects and resume looking for the ping response