Closed SMillerDev closed 5 months ago
webview =! opening a browser. I don't know much about swift but https://developer.apple.com/documentation/webkit/wkwebview should be the right component. Create a https://developer.apple.com/documentation/foundation/urlrequest object, set OCS-APIREQUEST as header and call wkwebview load with the urlrequest object.
Not sure if above logic is used for login flow but its a webview with OCS-APIREQUEST :sunglasses:
cc @marinofaggiana
While this is a possible way to work around the issue it's not a very sound technical solution. Apple/Swift has specific frameworks for web authentication, as a webview is meant to display a site instead of handling credentials, and those don't accept executing of random requests.
cc @rullzer
Thanks for thinking along by the way. It's appreciated.
While not ideal it is currently what we have as there was no sane spec (that wasn't already deprecated). As linked by @kesselb our iOS files and talk apps already use it so indeed maybe borrow from there.
It is still on my list to look into PKCE for auth of the clients. But I do not see that happening in the near future.
Is there any chance of a pull request allowing a get parameter for a redirect in addition to the header getting accepted?
Just for clarification, I'm proposing to allow login.url/flow?redirect=true
in addition to the setting of the header. But would such a pull request have any chance @rullzer ? Or will it be closed on ?security? reasons immediately?
I think that should be possible with https://docs.nextcloud.com/server/latest/developer_manual/client_apis/LoginFlow/index.html#login-flow-v2 now.
Reading that document, is the polling required while authenticating? Or would polling once when the user closed the browser be enough?
is the polling required while authenticating? Or would polling once when the user closed the browser be enough?
cc @rullzer
Reading that document, is the polling required while authenticating? Or would polling once when the user closed the browser be enough?
Once is enough
Yeah this one doesn't work with the iOS authentication flow because it isn't able to redirect anywhere so it never closes the UI. Theoretically you could poll in the backcround and cancel the authentication flow but that's really just a hack. @nextcloud/ios how do you solve this? Or do you just use a browser instead of the official way?
Is this Issue still valid? If not, please close this issue. Thanks! :)
As far as I know the iOS team still uses the old unsupported iOS components because that is the only way to complete the login flow.
Duplicate of nextcloud/ios#2890
This is somewhere between a bugreport and a feature request.
https://docs.nextcloud.com/server/16/developer_manual/client_apis/LoginFlow/index.html#opening-the-webview documents that a header should be send when opening the browser that requests the token. This is highly unusual behaviour afaik and frankly impossible on iOS if you want to use newer authentication methods.
Steps to reproduce
Expected behaviour
Nextcloud should allow for a seperate flow that always redirects to the authentication uri without setting headers.
Actual behaviour
<server>/index.php/login/flow
works the same as<server>
Server configuration
Operating system: Any (but Ubuntu 18.04)
Web server: Nginx
Database: MariaDB 10.3
PHP version: 7.2
Nextcloud version: 15
Updated from an older Nextcloud/ownCloud or fresh install: Update and fresh
Where did you install Nextcloud from: web?
Signing status:
Signing status
not relevant (but will fill if needed)List of activated apps:
App list
not relevant (but will fill if needed)Nextcloud configuration:
Config report
not relevant (but will fill if needed)Are you using external storage, if yes which one: local
Are you using encryption: no
Are you using an external user-backend, if yes which one: no
Client configuration
Browser: Safari
Operating system: iOS 12
Logs
Web server error log
Web server error log
not relevant (but will fill if needed)Nextcloud log (data/nextcloud.log)
Nextcloud log
not relevant (but will fill if needed)Browser log
Browser log
not relevant (but will fill if needed)