Fork me on GitHub
#clojure-europe
<
2021-05-12
>
dharrigan05:05:03

Good Morning!

djm06:05:38

šŸ‘‹

pez06:05:40

ā˜€ļø

anthony-galea12:05:44

Iā€™m currently working on a Clojure codebase that makes quite heavy use of spec. Today the app crashes on me during a demo because I use brackets in a text field whose contents are used in an HTTP request to the backend. The regex doesnā€™t allow ā€˜(ā€™

(def url-regex
  (re-pattern "(http|ftp|https)://[\\w-]+(\\.[\\w-]+)*([\\w.,@?^=%&:/~+#-]*[\\w@?^=%&/~+#-])?"))

(s/def ::url (s/and string? #(re-matches url-regex %)))
Now if Iā€™m reading the spec correctly brackets are allowed:

anthony-galea12:05:54

So now I could revise the regex to allow brackets, but is there value in keeping this spec at all?

anthony-galea12:05:02

And perhaps more generally, has anyone had the experience that overspeccing ends up making a system more brittle than it has to be?

pez12:05:48

As I work with the same project, I might add that the Uri component is first escaped using js/encodeURIComponent , then checked with that spec. šŸ˜ƒ

otfrom12:05:21

I would struggle to write a regexp that covered all valid URIs

anthony-galea14:05:05

Indeed, but also, given how the URL is being built it would be redundant to validate it anyways.

pez12:05:00

Seems like the URL spec there could help with it, but indeed, it is daunting anyway.

slipset12:05:00

Expert answer is that ā€œit dependsā€

slipset12:05:17

What are the ramifications of someone fatfingering here?

jkxyz12:05:42

My version of a URI spec would be using java.net.URI or JSā€™s URL classes to parse the string, catch the error and return nil such that the spec fails when itā€™s unparseable

šŸ™ 2
slipset12:05:24

And what do you actually care about? Seems like you care about limiting your protocols to http(s) and ftp?

pez12:05:50

@slipset Thing is that all that is provided by us, the user only provides a query string. We encode that string and build the URL. The result is then spec checked. I think it feels like we are specing js/encodeUriComponent, and also donā€™t feel like that is our responsibility.

slipset12:05:52

I guess yā€™all seen the complete regex for emails? How much value does it bring to the table over just checking for a string that contains an @?

pez12:05:48

We have had failures to register with our app because our email-regex was stopping valid email addresses too. šŸ˜ƒ

slipset13:05:36

So the user provides ā€œ/foo/bar/baz?lolā€ and based on that you create ā€œhttp://wahtever.com/foo/bar/baz?lolā€ then I wouldnā€™t bother with the spec.

šŸ™ 2
pez13:05:14

The user provides lol, but yeah. šŸ˜ƒ

pez13:05:55

A perhaps stupid questions, regarding specsā€¦ Is anyone using fdefs in their unit test namespaces to instrument the functions under test there, instead of doing it where the functions are defined?

borkdude14:05:43

@pez Iā€™ve got a library for this, called re-speced

3
pez14:05:45

Ah, that looks nice!

anthony-galea14:05:54

Thanks for the feedback, Iā€™ve seen a couple of situations were an app crashes unnecessarily because of a spec being too narrow, and so Iā€™m questioning the very liberal use of specs throughout a codebase. I have found the guideline to ā€œonly spec what is necessaryā€ useful. Wondering if other people have had similar experiences

ordnungswidrig14:05:15

Regarding mails: Iā€™d verify for @ and a single dot in the host part. You maybe donā€™t want to support bang paths but who cares? #"\s.+@[^.]+\.[^.]+\s"

šŸ™ 2
dharrigan15:05:39

This reminded me of something that popped up on hacker news, I found the article

dharrigan15:05:02

There is a lot to email validation

šŸ‘ 2
šŸ™ 2
RAMart16:05:49

@anthony-galea My rule of thumb: Spec vulnerable points of your system: E.g. where data enters or leaves (the outer shell), untrusted sources and the like. Loosen it for (core) layers which highly benefit from data flexibility.

šŸ“ 2
šŸ‘ 4
šŸ™ 2