Clojurians Log v2

Maybe I am dense, but what does this mean?

::http/join?	
If false, do not block the thread that starts the web server. Passed to the container.

When running the server from a repl, you wouldn’t want to block the repl so you’d use ::http/join? false during development.

@ddeaguiar Thank you. Is there any reason to not just use ::http/join? false all the time?

Hrm, good question. I don’t recall off hand. Will look into it!

your main thread will exit, right? The JVM will probably keep going (is the Jetty thread daemon?)

In production we actually have this:

(defn join-server-thread [system]
  (let [^org.eclipse.jetty.server.Server jetty-server (get-in system [:pedestal :service :io.pedestal.http/server])]
    (.join jetty-server)))

Think @orestis is right.

And our -main looks like this:

(defn -main [& args]
  (println "Starting...")
  (java.security.Security/setProperty "networkaddress.cache.ttl" "30")
  (nosco.util.repl/try-start-nrepl 6666)
  (let [conf (prod-config dev-config)
        system (try (start-system nosco.http.service/prod-service-map conf)
                    (catch Exception e
                      (shutdown-agents)
                      (throw e)))]
    (join-server-thread system)
    (shutdown-agents)))

I think the point was to be able to cleanly shutdown agents when the jetty thread terminates. If you let it go off you won’t be able to know when it shut down…

@orestis That makes sense, although I don’t have any shutdown-specific code in my case (yet). And then in addition to that, if I don’t join I will have to make up some other artificial way to keep the main process running?

I’m not quite sure if the Jetty thread is Daemon (will not prevent JVM from exiting) or not -> https://www.geeksforgeeks.org/daemon-thread-java/

But in general you should keep a handle on threads, so I think not auto-joining and manually joining as I pasted above is sane. Bonus, it’s the same configuration between REPL and production, with the difference that in REPL you never join 🙂

(Sorry if you already knew about daemon threads 🙂 )

No I don’t, so thank you for that. 🙂 I guess I will simply cargo-cult whatever everyone else is doing for now :)

I think that for REPL you never want to join as then you wan’t be able to keep the REPL going. You can always test what happens in production if you don’t join, it’s just annoying because you have to keep re-starting the JVM…

yeah, I just tried it out in the REPL, but that’s why I was curious when it made sense to join.

BTW @ddeaguiar I actually got a working SAML 2.0 auth solution up and running pretty quickly. I’ve deliberately architected it in such a way that the relevant namespaces can eventually be put inside their own a library. The basic idea is that the library consumer (just myself for now) supplies a small configuration map, joins their routes with a set of ready-made SAML routes, and then prepends a SAML-session auth interceptor chain to any route endpoints that require controlled access. That seemed the most logical way to do it to me. Would you say this is the idiomatic way to do things in Pedestal?

@simongray It’s worth reviewing the benefit the library consumer gets by having the library manage routes as well. Routing and auth are different responsibilities. Sure, with SAML a service will have to participate in some sort of back-and-forth but the routes are just bindings to some implementation. I also suggest looking at prior art (even beyond Clojure). For example, I’ve not used https://github.com/propan/geheimtur in a long time but that lib did make the explicit choice to avoid dealing with routing.

The exact routes required for the SAML flow are all configurable in the config, but I set some defaults when left unconfigured.

Unfortunately, I don’t think there is much prior art in the Clojure space. The primary reason I’m rolling my own is that the go-to solution in the Java space, Shibboleth-sp, is incredibly terse and I figured I would be better served by isolating the functionality I need in a small library and then re-using that for the various web services I need to make (they all require some form of SAML login). Thank you for the geheimtur link though. I didn’t know about that (and I don’t really how much OAuth 2.0 and SAML 2.0 resemble one another), but it’s useful to learn from anyway.

And you can of course just use the various interceptors in a an isolated way too. I just thought that an assembled set of routes would be quite illustrative 🙂

Oh I’d love to see a new SAML implementation- it’s an area full of dangers and pitfalls. I assume @simongray you’re delegating the core logic to another library?

Yeah, I am using the metabase fork of the saml20-clj lib (which wraps the same core lib used by Shibboleth-sp)

@orestis current state https://github.com/kuhumcst/louis-hjelmslev/blob/development/src/dk/cst/pedestal_sp.clj and helper namespaces: https://github.com/kuhumcst/louis-hjelmslev/tree/development/src/dk/cst/pedestal_sp

and some kind of explanation of what I am doing which will eventually become the README of whatever repo I’m putting this in once I’m done with it: https://github.com/kuhumcst/louis-hjelmslev/blob/development/pedestal-sp.md