Fork me on GitHub
#yada
<
2017-09-29
>
mikepjb08:09:31

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

malcolmsparks08:09:36

Are you accepting html in your [email protected]

mikepjb08:09:01

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

macroz14:09:35

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

macroz14:09:25

doesn't matter that it is URL encoded

dominicm14:09:07

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

macroz14:09:53

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

macroz14:09:29

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

malcolmsparks14:09:06

@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

macroz14:09:24

ok was looking for an answer in yada docs

macroz14:09:36

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

malcolmsparks14:09:04

It piggy backs on bidi's path parameter logic

malcolmsparks14:09:49

All strings? Careful with those injection attacks...

malcolmsparks14:09:19

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

macroz14:09:49

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

malcolmsparks14:09:45

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

malcolmsparks14:09:01

Just be careful with inputs from requests

macroz14:09:05

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

malcolmsparks14:09:34

Sure. I agree. Just be careful

macroz14:09:26

most libraries these days encode and protect by default

macroz14:09:43

which is good

malcolmsparks14:09:05

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

macroz14:09:30

well this is SPA and React does

delitescere02:10:02

That is no great use if the backend isn't also cleaning input.

macroz14:09:59

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

macroz14:09:13

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

malcolmsparks14:09:32

Great. Yes I will

dominicm14:09:26

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.