vidakovic commented on code in PR #2752: URL: https://github.com/apache/fineract/pull/2752#discussion_r1030519369
########## fineract-provider/src/main/java/org/apache/fineract/infrastructure/documentmanagement/contentrepository/FileSystemContentPathSanitizer.java: ########## @@ -0,0 +1,138 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.fineract.infrastructure.documentmanagement.contentrepository; + +import java.io.BufferedInputStream; +import java.nio.file.Path; +import java.util.List; +import java.util.regex.Pattern; +import javax.annotation.PostConstruct; +import lombok.RequiredArgsConstructor; +import lombok.extern.slf4j.Slf4j; +import org.apache.commons.io.FilenameUtils; +import org.apache.commons.lang3.StringUtils; +import org.apache.fineract.infrastructure.core.config.FineractProperties; +import org.apache.fineract.infrastructure.core.service.ThreadLocalContextUtil; +import org.apache.fineract.infrastructure.documentmanagement.exception.ContentManagementException; +import org.apache.tika.Tika; +import org.apache.tika.io.TikaInputStream; +import org.apache.tika.metadata.Metadata; +import org.apache.tika.parser.AutoDetectParser; +import org.apache.tika.sax.BodyContentHandler; +import org.springframework.stereotype.Component; + +@Slf4j +@RequiredArgsConstructor +@Component +public class FileSystemContentPathSanitizer implements ContentPathSanitizer { + + private final FineractProperties fineractProperties; + + private List<Pattern> regexWhitelist; + + private static Pattern OVERWRITE_SIBLING_IMAGE = Pattern.compile(".*\\.\\./+[0-9]+/+.*"); + + @PostConstruct + public void init() { + regexWhitelist = fineractProperties.getContent().getRegexWhitelist().stream().map(Pattern::compile).toList(); + } + + @Override + public String sanitize(String path) { + return sanitize(path, null); + } + + @Override + public String sanitize(String path, BufferedInputStream is) { Review Comment: Good catch... not possible to sneak anything around you :wink: ... as you can see I didn't include the sanitizer in S3, because it's not really needed there (now). To get this improvement over the finish line I've arranged things as you see them here, including the buffered input stream... which - kind of - forces everyone who uses this function to pay attention. In too many places the use of InputStream is just not done the right way (streams are copied into byte arrays which are immediately wrapped in ByteArrayInputStreams... and multiple times with the same data). None of the places where I had to make changes for this improvement paid attention - at all - if streams are still open or closed. If the authors were in doubt then they just took the byte array again and created a new stream. Obviously that defeats they whole idea of streams on not holding all the data in memory. I intend to generalize this part of the system even further to make contributions (like this one https://issues.apache.org/jira/browse/FINERACT-1814) easier and cleanup the whole implementation: - why do we have a distinction between images and other files... - actually images can only be associated - for whatever reason with clients and staff... - why do we have to replicate something like a file path and not just use a flat structure with UUIDs for the physical file names... we can attach any kind of metadata in the database structure if really needed Just to say: let's leave it like this for a moment. I just didn't want to introduce too many changes at once (I already moved the configuration from the database to application.properties... which is the better way to do it nowadays with reloadable configurations etc.). I'll mark this one as resolved for now, but expect more next week. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
