My company uses a captive portal, Google IAP (Identity aware proxy) to protect its mattermost installation
This means i can't use the mattermost mobile app on Android. As part of its startup it asks you to enter a server name, which it then 'pings' (calls /ping). With my captive portal this ping gets redirected (302) to a login page.
Current behaviour: The redirect of ping makes it say "cannot connect to the server. Please check your server URL and internet connection"
My desired behaviour (this job!): Alter the client's code so that it pops up a browser window, following the redirect. When the user logs in the cookies that get set need to be persisted in the application and send with **all future HTTP requests for that server**
The mattermost desktop client (v4.1.3 - yes it's an old one) seems to do this, i've had some problems with later versions of the desktop client supporting this as well.
So i think this work consists of:
- Handle redirected /ping to handle the login flow
- Persist cookies from the end of the login flow to the app for the whole session
- When reauthentication is necessary (a request encounters a 302 again) do the same thing you did for /ping
- Doing it in a way that means the merge request gets accepted on to the appropriate mattermost project
As a suggestion, perhaps it's a matter of catching 302s globally and popping them up in a browser?
I am a (busy) developer and can review your code, but the main thing is that this gets merged into the mattermost project.
- I can enter my company's chat server in the server box (I will reveal this to the winning bidder)
- I can login with the Google IAP protecting it (unfortunately i can't give you a working login to this, if it's a massive blocker we can maybe setup a sample IAP on GCP)
- I can use it for the session and login again when my session expires
- The PR is accepted to the mattermost-mobile project (i.e. meets their standards)