OBPIH-6083 Add custom MultipartResolver

[drodzewicz]

No description provided.

[alannadolny]

I think it is not a good decision looking from the security context. Without a maximum request size, someone could send excessively large requests, overwhelming the server. This could lead to performance degradation or temporal server unavailability.

[drodzewicz]

Thanks for pointing that out, I had to check/test few things so...
The new CommonsMultipartResolver that I have implemented here receives a parameter maxUploadSize that checks the size of all of the uploaded files as a whole.

The standard multipart resolver (default one) receives parameters maxFileSize maxRequestSize and works a little differently.
the maxFileSize refers to the individual file size and maxRequestSize to the whole request size.

So in the end specifying maxFileSize: 2097152 and maxRequestSize: 2097152 is almost equivalent to maxUploadSize = 2097152

Note that maxRequestSize only sets this limit on multipart request and not all of the API calls, so if we want to secure our API a bit better we need to look for additional property that would handle this validation.

[jmiranda]

Also, there's probably a default value for maxRequestSize that is much smaller than what we've set it to.

https://guides.grails.org/grails3/grails-upload-file/guide/index.html#:~:text=Grails%203's%20default%20file%20size,to%20allow%2025MB%20files%20uploads.

[jmiranda]

Like I said before, I would prefer to either rethrow MaxUploadSizeExceededException or follow the similar approach i.e. returning

Here's an example from a Grails 3 app

https://github.com/UNCake/UNCake/blob/037c4d7c638a61a99a47d0388caf266fe3582faa/UNCake/grails-app/utils/uncake/CustomMultipartResolver.java#L4

If we cannot get it working this way then I'd suggest we go with the command object with contraints apporach for now.

return new DefaultMultipartHttpServletRequest(request, new LinkedMultiValueMap<>(), new LinkedHashMap<>(), new LinkedHashMap<>());

There are other Spring approaches (@ExceptionHandler, @ControllerAdvice) that we might be able to take advantage of but some of them are supported in Spring 5 (we're using Spring 4), so we'll need to wait a bit until we can use them.

[jmiranda]

Remove this class.

[awalkowiak]

As discussed on the tech huddle, iceboxing and closing