You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficcontrol.apache.org by GitBox <gi...@apache.org> on 2019/02/07 18:36:12 UTC

[GitHub] rob05c commented on issue #3063: Verbose JSON errors from DS regex endpoints

rob05c commented on issue #3063: Verbose JSON errors from DS regex endpoints
URL: https://github.com/apache/trafficcontrol/pull/3063#issuecomment-461545440
 
 
   >I believe we already are returning those errors for many other endpoints.
   
   I wasn't aware of that. Yeah, it looks like the "CRUDer" stuff returns the internal JSON error. We need to be more careful about that. We need to be careful about returning any error to the user that contains internal information about the server behavior, which can be an attack vector. Likewise, returning data posted by the user can be used for XSS.
   
   >we should be able to tell a client _why_ their JSON is invalid
   
   I agree. Though it isn't that difficult to run it through e.g. `jq` or `jsonlint.com`. But we need to make sure we're not creating security vulnerabilities too.
   
   I'd also think returning the Go types isn't a great user experience, e.g. `json: cannot unmarshal number 4200000000000 into Go struct field DeliveryService.FooBar.Baz of type int` should really be more like `json error: delivery service "foo_bar/baz" must be an integer between 0 and 2,147,483,647`.
   
   Maybe we should write a function to translate Go encoding/json error strings to a safe and user-friendly error? That kind of string parsing isn't ideal, but it's probably the only way. We already do that for Postgres errors anyway, for the same reason.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services