Use either a browser or sailfish webview for logging in. #20
Conversation
…-sailslack from ssh.
b100dian
force-pushed
the
sailfish-webview
branch
from
e212dbb to
5dbc38e
Compare
b100dian
changed the title
qml/pages/LoginPage.qml
Outdated
| onClicked: { | ||
| // Closing the 3000 port as even though the webview would successfully connect to it, the timing it navigates away from this page makes | ||
| // the webview crash (at onResultUrlAvailable signal). | ||
| server.close(); |
There was a problem hiding this comment.
Without the server running, the login via webview never finishes for me.
To avoid the crash, you should close the client socket after sending the response HTML in AuthServer, then the webview no longer crashes, because the connection is terminated before the webview is destroyed by the pagestack pop.
There was a problem hiding this comment.
I'll investigate this more. The first commit of this branch there wass no problem with the webivew connecting locally (it was actually the only way to get back the token)
There was a problem hiding this comment.
I think I got this: the webview was a bit more picky about my "http" response, and it was still 'loading' when destroyed. Adding Content-Length to the response seems to have fixed that. Let me know if this works on your end.
qml/pages/LoginPage.qml
Outdated
| switch (status) { | ||
| case PageStatus.Active: | ||
| server.listen(3000); | ||
| Qt.openUrlExternally(page.startUrl + "&state=" + page.processId); |
There was a problem hiding this comment.
This causes the web browser to be automatically opened when the page is first shown. Is that intended as default behaviour, where the alternative options are just for "advanced" users? Or would it be better to let the user to choose the right method for themselves?
There was a problem hiding this comment.
What would be your preference?
I actually have more than one browser so this pops a dialog to let me chose the browser. But now I realize that fresh installs will directly start the login sequence in the browser (while I am still able to dismiss that dialog).
This was a last minute 'great idea' that maybe this new screen is not user friendly. I am open to suggestions if this should be enabled or removed.
There was a problem hiding this comment.
Hmm I would say let's keep the screen (for debugging purposes if nothing else) and go to webview by default (feels like a better flow). Regarding the browser, have you tried whether this works when the user users an Android browser, like Firefox?
There was a problem hiding this comment.
No, I havent yet tried with an AD browser (can you register one as url handler?)
I will try to show the webview first and offer an "Advanced" pull-down menu
There was a problem hiding this comment.
Done, see latest commit @danvratil
Also closed the socket after sending the HTTP response. The webview now has a header because I noticed that swipong may be disabled before a connection is made and this would mean losing the ability to access Advanced pulley in the future / in some cases.
Added an auth-server that actually listens on port 3000 and if you do connect with the browser it displays "You can now switch back to Sailslack".
Moved the sailfish webview to a lazy-loaded component as it still crashes if not run from terminal \o/Crash is worked around, webview is still lazy loaded but now we can use it in WebViewPage which makes for better virtual keyboard support.
The sailfish webview redirect actually works, I left the comment for reference from my initial impressions..
Here's the stack of the crash.. sailfishos/sailfish-components-webview#26 (comment)
(The link actually has the fix for the crash now!)
To be able to build this, you need to tick the webview in Qt's Sailfish IDE Tools -> Options -> Sailfish OS -> Build Engine -> Manage Build Targets -> search for "webview" and tick sailfish-components-webview-qt5
