Skip to main content

⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

COPluginHost limitations

Comments

9 comments

  • Walter Rowe
    Moderator
    Top Commenter

    Brett Funderburg

    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'.

    https://github.com/janko/flickr-objects

    0
  • Brett Funderburg

    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
  • Walter Rowe
    Moderator
    Top Commenter

    Brett Funderburg

    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
  • Walter Rowe
    Moderator
    Top Commenter

    Brett Funderburg

    Here is another example of Flickr API via Flickr SDK from SmugMug. Perhaps there is some code there you can mimic.

    https://github.com/flickr/flickr-sdk/tree/main

    0
  • Brett Funderburg

    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
  • Walter Rowe
    Moderator
    Top Commenter

    Brett Funderburg

    Ooohhh. Gotcha. Thanks! I didn't realize that.

    0
  • Walter Rowe
    Moderator
    Top Commenter

    Brett Funderburg

    Did you make any progress with your Flickr plugin?

    0
  • Brett Funderburg

    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
  • Walter Rowe
    Moderator
    Top Commenter

    Brett Funderburg

    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.