Clojurians Log v2

when a POST goes wrong and a 500 is returned, is it possible to view a stack trace in the response? Currently I am changing the post to a get because yada will print the stack trace that way

Are you accepting html in your request?@

I wasn't! Including --header 'Accept: text/html' shows the stack trace now

thanks @malcolmsparks

interesting, I can't get route to match with path param like AQMkADU4YmQ0ZDU0LTJkNzUtNGE5MS1hNmIwLTZjNzkyNmVhNGI2NABGAAADgLxKILUg8UycUESZkpzxuQcAX74XcER4HUqZ4ZShQm7AgAAAAgENAAAAX74XcER4HUqZ4ZShQm7AgAABoA7_-QAAAA== but if I remove the last two equal signs it does match

doesn't matter that it is URL encoded

@macroz I think there's a fairly strict regex in place in bidi to reduce the chance of exploits.

Microsoft Graph API contains IDs like that and this is a DELETE request so makes sense to use a path parameter

I was reading the source code but yada is a complex piece of machinery

@macroz that is because the default bidi regex doesn't match on =, but you can declare the regex explicitly in your path param. See bidi's README

ok was looking for an answer in yada docs

if I declare a path parameter with String schema I would expect it accepts all Strings

It piggy backs on bidi's path parameter logic

All strings? Careful with those injection attacks...

But yes, it does seem like something that needs a better solution

it parses/matches the path so it does have some format, it comes in a Java (/Clojure) String so where is your injection possibility?

If you go on to use that string in html output, sql concatenation, etc.

Just be careful with inputs from requests

yes, but that is in my view an altogether different concern that is mostly solved by the other library where you pass the String into, i.e. PreparedStatement

Sure. I agree. Just be careful

yeah

most libraries these days encode and protect by default

which is good

hiccup v1 is one that doesn't There are others...

well this is SPA and React does

I think I got it to work so thanks for the tip

this would be useful to mention in the yada side as well

Great. Yes I will

I agree with @macroz that each component should assume dangerous data as input. However, I also think that it's useful to have bidi provide a little bit of extra protection for 99% of cases.