Fork me on GitHub
#off-topic
<
2021-03-30
>
vemv00:03:23

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

dharrigan03:03:20

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

dharrigan04:03:24

noice! thank you!

👍 3
raspasov04:03:31

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 🙂

seancorfield05:03:12

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 🙂

seancorfield05:03:45

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

dharrigan05:03:14

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

seancorfield05:03:14

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

simongray09:03:56

I’m also a fan of pen & paper, but these days I do that (and scribble programming notes) on an e-ink tablet. It helps to reduce paper clutter.

dharrigan09:03:30

Maybe I should break out my remarkable2...

simongray11:03:43

That's would I would do. Supposedly, Remarkable is the best one to write on too. I use a Max Lumi.

flightcubs12:03:25

Also a fan of starting with pen & paper to explore ideas and diverge. When converging, I really like https://www.figma.com/ for both design and prototyping. It’s free (unless you need collaborative features) and simple to use. Of course it’s easy to get bogged down in pixel perfect designs. You could use a https://www.figma.com/file/2fkn66F1J3H594BhgcLlsY template to keep things at high level.

👍 3
Stefan13:03:39

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!

borkdude14:03:22

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

Stefan14:03:48

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

dharrigan14:03:50

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

borkdude14:03:56

The sub-libraries have more recent updates

borkdude14:03:10

like buddy-hashers, buddy-auth

Stefan14:03:56

Ah right, should have seen that myself, thanks 😅

Stefan14:03:38

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

Stefan14:03:07

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

dharrigan14:03:26

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

dharrigan14:03:39

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

dharrigan14:03:43

and all they use is basic auth

dharrigan14:03:49

good enough for them....

Stefan14:03:00

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.

dharrigan14:03:26

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

mpenet14:03:32

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

dharrigan14:03:40

they just use basic auth

mpenet14:03:45

at least to prevent replay attacks and whatnot

dharrigan14:03:01

their api is mostly form url encoded

dharrigan14:03:09

they must be doing something right

dharrigan14:03:21

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

dharrigan14:03:26

(or compromisedc)

dharrigan14:03:10

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

dharrigan14:03:21

however, their login is just basic auth

mpenet14:03:24

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

dharrigan14:03:35

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

dharrigan14:03:15

security is hard. I favour the very simple approach.

dpsutton14:03:41

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

Stefan14:03:04

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.

dharrigan14:03:07

absolutely, security is like an onion

🥲 3
mpenet14:03:19

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

dharrigan14:03:46

I have an opposing view 😉

Stefan14:03:11

That’s what makes it an interesting conversation 🙂

mpenet14:03:53

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

dharrigan14:03:23

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

dharrigan14:03:34

It's just one of many options

mpenet14:03:36

depends on the use case

mpenet14:03:51

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"

dharrigan15:03:03

Yeah, maybe something like keycloak?

mpenet15:03:43

then again depends on use case

dharrigan15:03:13

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 🙂

dharrigan15:03:21

There is even a library to help out

mpenet15:03:22

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

dharrigan15:03:46

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

Stefan15:03:59

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…

dharrigan15:03:21

basic auth is a standard

Stefan15:03:37

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

Stefan15:03:12

It’s just a basic standard 😜

dharrigan15:03:17

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

dharrigan15:03:35

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

Stefan15:03:56

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!

dharrigan15:03:37

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 🙂

dharrigan15:03:19

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!

Stefan15:03:57

Thanks for your thoughts guys!

KJO15:03:16

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.

🙏 3
flightcubs16:03:14

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

emilaasa17:03:37

@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

emilaasa17:03:04

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