Open mvriel opened 1 year ago
Hi @mvriel ,
I was not aware of this issue. Maybe I can add an abstraction layer for http client implementation; so users can implement their http client.
Please give me some time to think about it.
Sure! I have been working on a way to make it work, perhaps you can use that as inspiration.
The following lines and files are meant as a WebGLBrowser (as opposed to the Standalone browser) to circumvent the use of HTTPListener for WebGL:
This doesn't address the HTTPClient, I am now working on an alternate AuthorizationCodeFlow that uses UnityWebRequest. Though admittedly, I am not well-versed in how CancellationTokens work; meaning that I am somewhat struggling how to reconnect the error handling and abort flow. I will probably push these changes during today
@mvriel Have you managed to implement this functionality. Are there any chances to make PR for that?
While reviewing this package for a project that uses WebGL; I found that it works splendidly on Desktop, but when in WebGL it won't work.
After some digging, I found two main culprits: HTTPListener and HTTPClient.
HTTPListener won't work; but I managed to find a way around that by opening a popup with the authorization screen, and sending a message back to the Unity client when it returns. This was inspired by https://developer.okta.com/blog/2021/02/26/unity-webgl-playfab-authorization.
The HTTPClient bit is a bit trickier; this is used in the AuthorizationCodeFlow and UserInfoParser. And at this point I am not sure whether it could be replaced by Unity's
UnityWebRequest
. It would mean a change in all Clients, as they are based on the AuthorizationCodeFlow.Have you ever got this to work? Would UnityWebRequest be a viable alternative?