Hmm, I'm trying to use edge to debug my issue with uri-for not being set on the ctx. But it's giving me

[{:type java.lang.NullPointerException
   :message nil
   :at [yada.redirect$redirect$fn__29953 invoke "redirect.clj" 15]}]

Let me check, I pushed to edge yesterday

It's working OK for me at / - which URI are you going to that yields that error?

Yes, yada.redirect should really check that (:uri ctx) is not nil before calling it

which version of bidi are you using ?

I think this is a regression in a later version of bidi (my fault!)

I recently changed (:uri-for) to (:uri-info) in bidi without remembering yada uses that key. So if your version of bidi is too recent it will break. I'll update yada to fix the nil error on redirect and to being in the later version of bidi

The rationale for my change was that it's really unintuitive that uri-for returns a map not a string.

Is there not room for a (defn url helper fn?) something like:

(defn url
  ([ctx route]
   (:path (uri-for ctx route)))
  ([ctx route params]
   (:path (uri-for ctx route {:route-params params}))))

Or is that outside scope?

@malcolmsparks for edge I am just running the latest master, for my own try at oauth (following example in yada repo) I am using 2.0.11

The url is http://localhost:3000, the one recommended as the step after boot dev.

Getting a step further with bidi 2.0.10 🙂, now 403 on the callback url.

403: Forbidden

The request was a legal request but the server is refusing to respond to it.

Nice. Got the access token! Things wrong were: needed to hash the secret to satisfy buddy, needed to return a map from the callback response.