oAuth2 seems to log in successfully but the oAuth2 dialog/browser does not disappear, have to click cancel

[Martin Koob]

Hi Brian

Thanks for the explanation of the process.  That seems to be what is happening.  I assume that the difficulty implementing it is that the native app would not have a recognized SSL certificate for the https connection.  Is that right?

I don’t fully understand the oAuth2 process so this is an uneducated workaround idea so please excuse me if the following idea/question is totally off base. 

If the application was not a native Desktop app but a web app would requiring an https redirect URI not be a problem since the website  site the web app was hosted on could have a SSL certificate so you could have a https redirect URI?

 My application has a cloud backend API written in LiveCode server.  The site  has an SSL certificate so https URIs could point to it.  
- If I had to use an https redirect URI could it point to my website and then have the listener there?  There still would need to be a way to identify the user’s request with the server’s response and I am not sure how that would work.

- could I make a HTML5 standalone in LiveCode server on my cloud site. backend that I would open in a browser window in the desktop that would then, on loading, just  connect to the oAuth2 URI where the user would enter their credentials, The authorization would take place between the HTML5 app and the oAuth2 site with the URI being the on my cloud site.   Then the token could be returned to the native app from the HTML5 app.

Again these questions are based on a limited understanding of how this kind of authorization works so don’t laugh too hard. ;-)

Martin



> On Aug 28, 2020, at 9:37 AM, Brian Milby via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> The way the library works is that it sets up a listener on the IP/port.  It does not have any way to handle an encrypted (https) response/connection currently (and I’m not sure how that would even be implemented).
> 
> The code that handles the response is what closes the browser window that was created.  If it is not getting closed, then the response isn’t coming through.
> 
> Sent from my iPhone
> 
>> On Aug 28, 2020, at 12:31 AM, Martin Koob via use-livecode <use-livecode at lists.runrev.com> wrote:
>> 
>> Hi 
>> 
>> In my project to make a library for connecting to an LMS I am trying to use oAuth2 to authorize with a Brightspace LMS  instance from a Mac Desktop App.   The oAuth2 dialog/browser appears I enter the credentials and then the login appears to succeed i.e. the LMS's home page opens in the dialog/browser.  However the dialog does not  close so I have to click the ‘Cancel’ button.  So the result returned by the oAuth2 command is “cancel’ and there is nothing in the ‘it’ variable.
>> 
>> My redirect URI is https://127.0.0.1:54256 <https://127.0.0.1:54256/>.  The LMS service requires https.  LiveCode’s oAuth only allows http for the redirect URI.  Could that be the issue?
>> 
>> My guess is that once a response is received at the redirect URI then LiveCode’s oAuth2 dialog would close. 
>> Then the value of the token would be in the ‘it’ variable.
>> Is that the case?
>> 
>> The other issue may be that I don’t have the correct token URL parameter for the oAuth2 command.  I am still checking into that.
>> 
>> Any suggestions on how to get this working?
>> 
>> Martin Koob
>> 
>> VideoLinkwell, a service of
>> Koob SourceText Solutions Inc.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode