Ha!

> automated syndication often sucks. The content ownership part is the truly important part. You can most definitely consider syndicating manually, in optimal form per social network

Each content type + channel has unique requirements. Clojure composition FTW?

Ah yes, indieweb stuff... An issue with automated syndication is that a lot of platforms don't even have open APIs, e.g. twitter's basically that way now, and the new substack notes thing has never had an API (and I'll be surprised if it ever does). But maybe could still be useful to have platypub support a copy&paste workflow

Also I discovered from that thread that I'm not the only person to think of the platypus pun! https://platypush.tech/

Haha, I saw that!

I might even try to script a copy/past flow with etaion or such. The main thing is it’s hard to wrap your head around a creative/content flow if all the production spots are scattered to all the walled gardens. I know that’s the way it is though. I’ve never used the social media schuler apps though, so not very experienced in this space. (still living in a web2.0 rss+api fantasy :face_in_clouds:)

Our journey begins, like all journeys, in the middleware. Here's what I wrap around all the routes that should require a log-in:

(defn wrap-sign-in-required [handler]
  (fn [{:keys [biff/db] {:keys [uid]} :session :as req}]
      (if (some? uid)
          (handler (assoc req :user (xt/entity db uid)))
        {:status 303
        :headers {"location" (str "/signin?return=" (:uri req))}})))

(defn wrap-record-redirect
  [handler]
  (fn [{db :biff/db {:keys [return email]} :params :as req}]
      (if (and return email)
          (let [r-id (biff/lookup-id db :auth.redirect/email email)]
            (biff/submit-tx
             req
             [{:db/op :merge
                      :db/doc-type :auth.redirect
                      :xt/id (or r-id :)
                      :auth.redirect/email email
                      :auth.redirect/url return}])
            (handler req))
        (handler req))))

(update (biff/authentication-plugin {:biff.auth/app-path "/signed-in"
                                    :biff.auth/new-user-tx new-user-tx})
        :routes #(into ["" {:middleware [mid/wrap-record-redirect]}] %))

(defn signed-in
  [{:keys [biff/db user]}]
  (if-let [redirect (biff/lookup db :auth.redirect/email (:user/email user))]
      (ring.util.response/redirect (str (:auth.redirect/url redirect)))
    (ring.util.response/redirect "/")))

Nice! FYI you may have had an easier time by copy and pasting the https://github.com/jacobobryant/biff/blob/master/src/com/biffweb/impl/auth.clj into a new namespace in your project and then make any changes there. e.g. then instead of creating a new redirect document you can just add the redirect URL to the :biff.auth/code document: https://github.com/jacobobryant/biff/blob/master/src/com/biffweb/impl/auth.clj#L178. also could make handling the actual redirect simpler. (Actually for signing in via code, maybe no need to store the redirect URL in the DB at all? I think you can just keep it in the form params, similar to how the user's email address is stored.) Also FYI: there is a small vulnerability here since the signin page takes an arbitrary redirect URL. e.g. someone could do , so after the user signs in they get taken to a different website. Realistically it's unlikely that would become an issue for a small app, but at a minimum it wouldn't hurt to check the redirect URL with something like (= (:host (lambdaisland.uri/uri redirect-url)) (:biff/base-url ctx))

(see https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html)

Oh, that's good to know. Checking the redirect URL should be easy enough.

I'm going to bask in the glory of this success for a little bit longer and then probably do that copy and paste trick, because that seems a bit more clean and maintainable.