Using the download_endpoint plugin, files can be accessed via /attachments/eyJpZCI6ImFkdzlyeTM.... As far as I understand, eyJpZCI6ImFkdzlyeTM... is some base64 encoded data.
However, when a client calls the app with some invalid url like /attachments/dontwork, /attachments/dont%20work etc., Base64 or even JSON exceptions would happen, causing in the end a HTTP 500 response.
Expected behavior
Since it's the client's fault to provide the invalid url, response code should be in the 4xx range, e.g. 400 or 404.
constraints(AttachmentConstraint) do
mount Shrine::DownloadEndpoint => "/attachments"
end
copy the code from UrlsafeSerialization into AttachmentConstraint, catch the exception, and prevent the route matching.
This doesn't look like a good solution.
Using the
download_endpointplugin, files can be accessed via/attachments/eyJpZCI6ImFkdzlyeTM.... As far as I understand,eyJpZCI6ImFkdzlyeTM...is somebase64encoded data.However, when a client calls the app with some invalid url like
/attachments/dontwork,/attachments/dont%20worketc.,Base64or evenJSONexceptions would happen, causing in the end a HTTP500response.Expected behavior
Since it's the client's fault to provide the invalid url, response code should be in the
4xxrange, e.g.400or404.Workaround
Similar to https://github.com/shrinerb/shrine/issues/145#issuecomment-284223082, you could wrap
mountin aconstraintsblock likecopy the code from
UrlsafeSerializationintoAttachmentConstraint, catch the exception, and prevent the route matching. This doesn't look like a good solution.