Enforce upload size limit on putResourceFromUrl api

[tylerjmchugh]

Currently the putResourceFromURL api does not enforce the maximum upload size limit. This means that you can upload files larger than the limit if you provide a URL to that resource rather than uploading the file directly.

This PR aims to fix this issue by checking the InputStream's available bytes against the configured maxUploadSize.

Checklist

• I have read the contribution guidelines
• Pull request provided for main branch, backports managed with label
• Good housekeeping of code, cleaning up comments, tests, and documentation
• Clean commit history broken into understandable chucks, avoiding big commits with hundreds of files, cautious of reformatting and whitespace changes
• Clean commit messages, longer verbose messages are encouraged
• API Changes are identified in commit messages
• Testing provided for features or enhancements using automatic tests
• User documentation provided for new features or enhancements in manual
• Build documentation provided for development instructions in README.md files
• Library management using pom.xml dependency management. Update build documentation with intended library use and library tutorials or documentation

[CLAassistant]

All committers have signed the CLA.

[josegar74]

I've tested the PR and is.available() seems depending on the remote server. I found different cases: returning 0, the size and also less size.

It doesn't seem totally reliable.

For the FileSystemStore I see it's copied to a file here:

core-geonetwork/core/src/main/java/org/fao/geonet/api/records/attachments/FilesystemStore.java

Line 205 in da294f7

Files.copy(is, filePath, StandardCopyOption.REPLACE_EXISTING);

Maybe an option can be to updated that method (similar for other datastorages), to copy the file first to a temporal folder to calculate the size and throw the exception if it's bigger than the size allowed. Otherwise copy the file to the store.

[ianwallen]

I don't like having to copy the file to temporary locations. It is best to keep them as streams.

I wonder if it is possible to control the bytes uploaded to the stream - i.e. specify the max bytes in the file copy. If so we could specify max+1 and it the number of bytes uploaded is greater than max then we can rollback the upload.

We could use is.available() as a quick way to fail but if the value is less than the max then we could proceed to the second method (if possible).

[tylerjmchugh]

@ianwallen Looks like I misunderstood your suggestion. I will look into avoiding the temp file altogether and figure out how to rollback the upload to the store when the limit is reached.