Clojurians Log v2

UBM's relationship with Clojure seems weird. He's occasionally advocated for it for 10+ years (https://news.ycombinator.com/item?id=1700588) but I've never had the impression that we actually uses it. Of course one cannot keep tabs on individual people, but you'd think that someone with his name would leave some memorable evidence of using it... e.g. a talk given in a Clojure conf, an issue opened in github, a library, etc Like other people, I have the vague impression that some of these big-name consultants can pull off making a living out of fluff, using only past knowledge/experience and not necessarily keeping up to date with the realities of modern software engineering

He could have saved a lot of time by just posting the second last paragraph of his rant.

Any recommendations for a ui/mobile online mockup tool? To help me visualise an app idea.

https://excalidraw.com

noice! thank you!

I haven’t used it much myself, but a friend recommended it and it looks pretty good; recently I’ve been preferring … pen & paper! Often I find that the most productive 🙂

I’ve always been a massive fan of Balsamiq https://balsamiq.com/wireframes/ and not just because it was created by a bunch of my ex-colleagues from Macromedia 🙂

I genuinely think that this deliberately “lo-fi” approach helps stop folks getting distracted by pixel-perfect design issues.

oh, I used to use that, I recall. I see they are charging now

There’s a free cloud trial — might cover your immediate needs? 🙂

Hi all, we want to add OAuth2 “authorization server” support to our (ring-based) web server, so that clients can integrate with our server. I’m wondering how to best do that in a Clojure project? I found things like “friend” and “buddy”, but that all seems quite old so I’m not sure if that’s the right direction. Any recommendations? Thanks!

I would prefer using buddy over friend, as friend isn't really maintained

Is buddy though? Four years since last release seems quite long for a security-focused library…

buddy is built upon bouncycastle, which currently, in buddy core is 1.67, came out in November 2020 (i.e., 4 months ago).

The sub-libraries have more recent updates

like buddy-hashers, buddy-auth

Ah right, should have seen that myself, thanks 😅

Doesn’t seem to support oauth2 authorization code flows though it seems…

Not sure about the trade-offs between that and simpler token-based flows.

You know what. I've designing an API too, and I'm taking the stripe approach

They are a multi-billion dollar company, working with money

and all they use is basic auth

good enough for them....

Yeah makes you think indeed. But I’m not sure if it’s the same use case. In my case it’s not server-server communication, it’s about a user of one system accessing another without having to explicitly login.

surely the user would be using a client of sorts to delegate on their behalf

basic auth alone is dangerous, I'd suspect they do a bit more than that

nope

they just use basic auth

at least to prevent replay attacks and whatnot

their api is mostly form url encoded

with GETs

they must be doing something right

they are hugely successful, and I have yet to hear of their api being hacked

(or compromisedc)

yes, there are mitigation strategies you can do at the service layer, network layer, for deflecting those side channel attacks

however, their login is just basic auth

that's what I am saying, it's not "just" basic auth and done

agreed 🙂

@stefan.van.den.oord their client libraries, i.e., javascript etc., all use basic auth too.

security is hard. I favour the very simple approach.

i bet there's a lot of ancillary stuff to that: quick account lockdown, ip recognition and clamping down from suspected ips with otherwise valid credentials. perhaps pending transactions if they aren't sure, insurance to cover transactions that end up fraudulent, etc. I don't think i would just look at basic auth and think its a single layer of approach

But then there are maybe also different security trade-offs for them? It’s just a financial decision: accepting that sometimes things may go wrong a bit (as a financial risk), versus the cost of making more advanced things. I’m wondering if they would use the same approach for securing medical health record data.

absolutely, security is like an onion

yeah imho you're better off using oauth & the like ultimately 🙂

I have an opposing view 😉

That’s what makes it an interesting conversation 🙂

sure, I guess it works if you have a team dedicated to security that ensures everything is locked down around it. Otherwise stg like oauth is quite easy to use

I believe we shouldn't default reach to oauth, simply because others are doing it.

sure

It's just one of many options

depends on the use case

I had some success with auth0 in the past too if you want to fully externalise the thing and get integration with a lot of stuff for "free"

Yeah, maybe something like keycloak?

then again depends on use case

perhaps if you can hand off the complexities of security to something that is designed to be all about security (and have developers working totally on that aspect), that could be a quick way to move on and let it become someone else's headache 🙂

There is even a library to help out <https://github.com/jgrodziski/keycloak-clojure>

yes, that. Implementing oauth flow with all its little variations from service to service can be a pita when you have to do it for multiple providers

totally

throw it over the wall, make it someone else's problem 🙂

I feel I’m a bit more with @mpenet on this: keeping this data safe is a big responsibility, and we’re just a couple of devs. Relying on standards gives some sense of security, false or not…

basic auth is a standard

yeah of course, I think you know what I mean right 😉

It’s just a basic standard 😜

not really. if you are basing your decision on something that is simple, easy to maintain and proveably secure, with a small team of devs, then basic auth would be higher on my list

if you want to go down the oauth rabbit hole, then you'll need to devote more time and energy on it

Yeah I do get your point and I think there’s a lot of merit to it. You definitely made me think and I will seriously consider it!

on the other hand, if you can delegate the security to a product (that can be run on-prem, and is free) and let it do all the work for you, with a straight-forward way of providing auth/authz, then something else to consider 🙂

in the end, it's still very commendable to at least consider all the options to give your users the best, secure experience possible! so kudos!

Thanks for your thoughts guys!

FWIW. I’d be inclined to go with oauth. What’s expedient now might be a point of weakness in 6 months, or 12 months. I’ve had success with buddy and ouath (Okta). It’s a bit of a pita to get going as others have pointed out, but I sleep a little better.

Speaking of auth, has anyone experience with Ory Kratos (https://github.com/ory/kratos)? If so, what’s your impression of working with it?

@stefan.van.den.oord I've used Keycloak and it's alright, can be a lot to learn tho. And redhat / ibm might do something weird eventually

Also depending on what clients you have you might not get a whole lot more than basic auth security anyway.