Flickr oauth

[deg]

I am trying to use this library with Flickr. Slowly working through the snags and I hope to have it working soon.

Once I get things stable, are you interested in a PR of using this with Flickr, similar to what you have for Twitter in README.org?

Also, an interesting curiosity that hung me up for a few hours. I'm testing from the repl, using a server on localhost. Everything worked up to the call to oauth-access-token, which gave oauth_problem=signature_invalid. Turns out that the fix was to use a callback URL 127.0.0.1 rather than localhost.

[r0man]

@deg Yes, PR welcome!

[deg]

Ok, will do, though it will be at least a few days before this makes it off my back-burner.

I just hit a little surprise.. I had been testing on localhost, first from a server repl and then from my CLJS browser front-end. All good, so far.

Then, I tested from a browser on a different machine. The Flickr authentication window popped up in the browser on the server machine! After a moment's surprise, I realized that of course this happened, but I have no idea how the flow is supposed to work. Where/how am I supposed to call oauth.flickr/oauth-authorize to get the callback on the client machine?

[deg]

Later... I looked at the code in oauth.v1. Let me rephrase my question:

Looks likes this library assumes that the UI is running on the same machine as the Clojure code. I don't think it will be too hard to patch up a version that works client/server, but I suspect that I'll be moving beyond the spirit of what you intended for this library. Assuming that I'm not missing something, do you recommend that I:

1. Add this support and PR it back to you; or
2. Add the support in a personal fork for my own use (and maybe eventually clean it up enough to be publicly usable; or
3. Use some other existing oauth library which is more designed for client/server apps.

Background: My app is pretty vanilla, built on the Luminus template. I need to interact with Flickr and want to keep as much of the workload as possible on the client, except not exposing my oauth secrets to the client side.

[deg]

Sorry, ignore most of what I wrote. I later looked at the code more carefully, and realized that the difference between server-side and client-side is little more than replacing the call to ouath-authorize with a redirect of a the results of oauth-authorization-url.

I'm away for the next few days (which Is why I kept jumping the gun today) but I'll try to test and get you a PR of the docs late this week.

[deg]

Just an update... Looks like there is nothing useful left in this issue except for my offer to create a PR expanding the docs.

I still hope to do so, but am not 100% happy with the code I have, plus am drifting soon into a vacation until early November.

So, your call: you can keep this issue open as a nag reminder for me to deliver the PR, or close it if you want to keep your issue count low. Either way, I still hope to deliver the doc as soon as I can.

[r0man]

Hey David, if you plan to add the docs then let's keep this issue open. Roman

On 10 Oct 2016 09:03, "David Goldfarb" notifications@github.com wrote:

Just an update... Looks like there is nothing useful left in this issue except for my offer to create a PR expanding the docs.

I still hope to do so, but am not 100% happy with the code I have, plus am drifting soon into a vacation until early November.

So, your call: you can keep this issue open as a nag reminder for me to deliver the PR, or close it if you want to keep your issue count low. Either way, I still hope to deliver the doc as soon as I can.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/r0man/oauth-clj/issues/28#issuecomment-252547748, or mute the thread https://github.com/notifications/unsubscribe-auth/AABUPiVLoi5q_0VBUkQW2enk_9sjKZ3wks5qyeMjgaJpZM4KJvfz .

[deg]

https://github.com/r0man/oauth-clj/pull/29, but see my caveats there.