Hi all I’ve been doing some work for a client who is still using LC5.0.2 ?(because it works and they don’t want to go to the subscription model) and needed to add in functionality with Adobe echoSign (now just Adobe Sign™). This has changed from a SOAP auth method over to OAuth2, rightly so. This was to be my first encounter with OAuth.
I looked at the docs and method used in the OAuth library in LC9 and realised an issue. It suggests using a redirect_url of 127.0.0.1 (or ‘localhost’ as it’s otherwise known). However, this cannot operate over https as no one would provide a security certificate for localhosts as that would be just crazy and, as I found, most sites are now making it a requirement to pass data via https. Adobe will not allow you to provide a redirect that does not start with https. So, right away this method was out of the question. But there is an easier method and one that I would very much recommend. Because the authorisation *HAS* to be done via a browser because the user must enter their sign in credentials, it is necessary to create a stack that contains a browser object. In LC8 and up it is nearer to use the browser widget in a modal stack you can open as a sheet. It is better to have a stack prepared with your OAuth and browser handler scripts already rather than the suggested LC library method of creating a stack with uuid number (which plays no advantage). In LC5 there is no widgets so the revBrowser should be used which doesn’t work on modal stacks so a standard substack (perhaps with no decorations) should be used. The clever bit is this. For your redirect you can direct it to almost ‘ANY’ https: site. It doesn’t even need to be your own! (Although I would recommend you only use one that you are happy to send these temporary details to like your own or your clients). Why? Because, when you are requesting at the outset of authorisation your Auth Code, once the user has entered their credentials and signed in to the ‘allow’ page, that page has within its htmltext the Auth Code written in as part of its JavaScript. And, better still, once the user has clicked the Allow button, it will move on to the redirect page with parameters in the URL containing the necessary Auth Code to collect the Access Token in the next stage (which will be done using a POST command rather than a browser - and ironically gets done over http rather than https :/! ). What this means is that you add a handler to your browser stack card that handles the message browserNavigationComplete which passes the instanceID of your browser (so you can now destroy it) and its URL, complete with its parameters in URL fashion (?code=[code] etc). So you can now pull to code parameter from this URL and use it in your POST to get your Access Token. Form there it’s plain sailing over POST or whatever using your ClientID, ClientSecret and this AccessToken. The upshot is that the OAuth library probably needs revising to avoid the use of localhost and probably recommend using something similar to this method. In a couple of days, once I’m finished on this project, I can move on to providing my feedback to LC and a pull request. I hope this is of help. All the best. Sean Cole Pi Digital _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
