COPluginHost limitations
Experimenting with a publishing plugin for Flickr which uses OAuth1 and requres showing a web page to the user so they can "authorize" the plugin to publish/upload pics to their photostream. Unfortunately, it seems there's no hooks in the CO plugin API for extending the host NSApplication (for the purpose of installing a custom URL handler for the redirects that happen in the OAuth workflow) nor getting a handle to the main window or ViewController (if there even is one) in order to install a temporary WKWebView or similar to handle this step in the Flickr authorization process. This makes getting signedin with Flickr either very cumbersome if not impossible or non-compliant with their Ts&Cs. Any confirmation of the above or a pointer in the right direction if such a thing is possible would be appreciated.
-
This python example of Flickr authentication might be helpful.
https://stuvel.eu/flickrapi-doc/3-auth.html
They discuss an 'oob' (out of band) grant of permission. You pop open a browser for the user authentication and authorization and Flickr presents them an access code. The user then copy-pastes that code into a field in your plugin authentication form. The OAuth process wants to use a callback URL. Given you don't have one it may require using the browser.
I don't know how Lightroom does this. Does it present a browser inside the plugin authentication window? Does it scrape the output of that to grab the code?
This Ruby example seems to do just what I said. It seems to scrape the web output using 'oob'.
0 -
The 'oob' trick is an interesting approach I wasn't aware of. I think I may just launch the browser standalone and start a tiny webserver for the amount of time needed (which I was hoping to avoid) to handle the redirect coming back that has the auth token. I have a toy app I wrote that already has all of the authentication, authorization and file upload working. It's just that making it fit into the C1 plug-in workflow is not super straighforward.
0 -
What if the user's system sits behind a firewall or some other service that doesn't allow the callback? Starting a captive browser where you can scrape the output might be more reliable if you don't want the user to copy-paste the authorization code in a plugin field.
Users sitting in a commercial office are probably working on a network that is protected from the internet by firewalls. It would be great if Flickr supported a more modern authentication and authorization method. OAuth1 is very dated and considered untrustworthy in most IT security guides.
0 -
Here is another example of Flickr API via Flickr SDK from SmugMug. Perhaps there is some code there you can mimic.
0 -
The firewall isn't a factor because the user's browser is telling Flickr, "Here's some credentials, after you're done, use the redirect URL I'm sending you to send me a 3xx redirect code to that URL with the credentials" So then Flickr goes, "You're good, 3xx over to (where my private webserver is listening) your tokens are in the payload I'm sending with the redirect http://localhost:port/flickr?oauth_token=foo&oauth_secret=bar" and that's pretty much it. The only incoming connection is from the user's own computer.
0 -
Ooohhh. Gotcha. Thanks! I didn't realize that.
0 -
Did you make any progress with your Flickr plugin?
0 -
I did in fact. I have an implementation that can successfully authenticate and publish pics. I need to clean up a couple of things and I’ll put it on GitHub. MacOS only though.
0 -
Let me know if you'd like a tester. I'd be glad to try it and offer feedback.
0
Please sign in to leave a comment.
Comments
9 comments