Re: Chunk size error after upgrading JRE
>On 07/11/2023 14:05, Tuukka Ilomäki wrote: >> We have a very old application running on Tomcat 8.5.90. After upgrading >> from JRE 8.0.252.09 from AdoptOpenJDK to 8u302b08 from Temurin (both pretty >> old, I know, also newer JREs exhibit the same issue) we started having >> NS_ERROR_NET_PARTIAL_TRANSFER in FireFox and ERR_INCOMPLETE_CHUNKED_ENCODING >> in Chrome. I suspect this has something to do with UTF-8 conversion but I >> have troubles figuring out what and why. The application has a filter that >> sets response character encoding as UTF-8. Truncated content looks like is >> has UTF-8 content but truncated to length calculated for ANSI. Naturally, I >> could be completely wrong in the assumption. >> >> As JREs are old, it is hard to fathom what could have changed between those >> versions. Apparently there is some configuration or default that has changed >> but I have difficulties in trying to figure out where to start searching. >> >> Any advice greatly appreciated. >Can you recreate the issue with a simple Servlet? Trying to do so may >shed some light on what is going on and if it doesn't you'll have a >reproducible test case for a bug report. >Mark Hi, Thank you for your comments. Recreating the issue with a simple Servlet might be difficult. If this was a simple issue, someone else would probably have encountered it already. The app is JSF 1.1 (spec from 2004...) with mainly generated code. Eliminating components from the application one by one seems more fruitful than trying to build it from scratch. I'll do my best but it'll take dozens of hours. Interestingly, I tried the unlikely approach and ran the application with Java 11 and Java 17 and both worked just fine in both Tomcat 8.5 and latest Tomcat 9.0. In old legacy code it is rare that runtime upgrades will solve issues instead of creating them. It is just the late Java 8 builds that give me the headache. Tuukka
Re: Testing OpenSSL integration using the FFM API with Tomcat 11 on Windows 10
Thanks Mark, I found the issue, I assumed OpenSSL was installed because I had seen in some logs the message “OpenSSL successfully initialized [OpenSSL 3.0.11 19 Sep 2023].” I double checked and OpenSSL exe is not available on the PATH. Is there any recommendations on how to install on Windows? O build from source is the best alternative? On Fri, Nov 10, 2023, 01:48 Mark Thomas wrote: > On 10/11/2023 00:59, Eduardo Guadalupe wrote: > > Hi, > > > > I wanted to test the OpenSSL integration using the FFM API rather than > > Tomcat Native in Apache Tomcat 11.0.0-M14. > > > > Starting Tomcat is printing an error: > > > > > > Failed to initialize the SSLEngine. java.lang.UnsatisfiedLinkError: no > ssl > > in java.library.path > > > > > > I am running on Windows 10 with openjdk-22-ea+22. > > > > Tomcat downloaded from > > > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-11/v11.0.0-M14/bin/apache-tomcat-11.0.0-M14-windows-x64.zip > > > > Is there additional steps/configurations required? > > Which OpenSSL binary did you install and where did you install it? > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Testing OpenSSL integration using the FFM API with Tomcat 11 on Windows 10
On 10/11/2023 14:44, Eduardo Guadalupe wrote: Thanks Mark, I found the issue, I assumed OpenSSL was installed because I had seen in some logs the message “OpenSSL successfully initialized [OpenSSL 3.0.11 19 Sep 2023].” That may be the OpenSSL version that is static linked to the Tomcat Native library. I don't think you can use that directly. I double checked and OpenSSL exe is not available on the PATH. Is there any recommendations on how to install on Windows? O build from source is the best alternative? I haven't tried this on Windows yet. I've only got as far as noting we'll need to think about this for Tomcat 12 if we are going to switch to FFM and some initial research. Based on my initial research I suggest: - look on the OpenSSL wiki for binary windows disributions - pick one that offers DLLs with no additional dependencies - download it - put libssl.dll (or whatever it is called) in an appropriate directory - ensure that directory is included in java.library.path (use setenv.bat) - ensure the OpenSSLLifecycleListener is configured in server.xml - start Tomcat HTH, Mark On Fri, Nov 10, 2023, 01:48 Mark Thomas wrote: On 10/11/2023 00:59, Eduardo Guadalupe wrote: Hi, I wanted to test the OpenSSL integration using the FFM API rather than Tomcat Native in Apache Tomcat 11.0.0-M14. Starting Tomcat is printing an error: Failed to initialize the SSLEngine. java.lang.UnsatisfiedLinkError: no ssl in java.library.path I am running on Windows 10 with openjdk-22-ea+22. Tomcat downloaded from https://dist.apache.org/repos/dist/dev/tomcat/tomcat-11/v11.0.0-M14/bin/apache-tomcat-11.0.0-M14-windows-x64.zip Is there additional steps/configurations required? Which OpenSSL binary did you install and where did you install it? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Testing OpenSSL integration using the FFM API with Tomcat 11 on Windows 10
On Fri, Nov 10, 2023 at 4:27 PM Mark Thomas wrote: > > On 10/11/2023 14:44, Eduardo Guadalupe wrote: > > Thanks Mark, > > > > I found the issue, I assumed OpenSSL was installed because I had seen in > > some logs the message “OpenSSL successfully initialized [OpenSSL 3.0.11 19 > > Sep 2023].” > > That may be the OpenSSL version that is static linked to the Tomcat > Native library. I don't think you can use that directly. Most likely it would be AprLifecycleListener, which uses the same message when it's done with the OpenSSL init. Meh, my bad, although all messages are completely correct. I guess it is more likely to happen on Windows, where OpenSSL is not bundled, but our tomcat-native binary with statically linked OpenSSL would be on the library path. Then OpenSSLLifecycleListener won't be able to load OpenSSL, but AprLifecycleListener would. Rémy > > I double checked and OpenSSL exe is not available on the PATH. > > > > Is there any recommendations on how to install on Windows? O build from > > source is the best alternative? > > I haven't tried this on Windows yet. I've only got as far as noting > we'll need to think about this for Tomcat 12 if we are going to switch > to FFM and some initial research. > > Based on my initial research I suggest: > - look on the OpenSSL wiki for binary windows disributions > - pick one that offers DLLs with no additional dependencies > - download it > - put libssl.dll (or whatever it is called) in an appropriate directory > - ensure that directory is included in java.library.path (use >setenv.bat) > - ensure the OpenSSLLifecycleListener is configured in server.xml > - start Tomcat > > HTH, > > Mark > > > > > > On Fri, Nov 10, 2023, 01:48 Mark Thomas wrote: > > > >> On 10/11/2023 00:59, Eduardo Guadalupe wrote: > >>> Hi, > >>> > >>> I wanted to test the OpenSSL integration using the FFM API rather than > >>> Tomcat Native in Apache Tomcat 11.0.0-M14. > >>> > >>> Starting Tomcat is printing an error: > >>> > >>> > >>> Failed to initialize the SSLEngine. java.lang.UnsatisfiedLinkError: no > >> ssl > >>> in java.library.path > >>> > >>> > >>> I am running on Windows 10 with openjdk-22-ea+22. > >>> > >>> Tomcat downloaded from > >>> > >> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-11/v11.0.0-M14/bin/apache-tomcat-11.0.0-M14-windows-x64.zip > >>> > >>> Is there additional steps/configurations required? > >> > >> Which OpenSSL binary did you install and where did you install it? > >> > >> Mark > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
FileUpload class not working with Tomcat 10.1
I recently upgraded from Tomcat 10.0.17 to 10.1.13. When I previously upgraded from 9.0.41 to 10.0.17 (back in 2/22) the FileUpload class broke. I fixed that thanks to postings on stackoverflow, but now that I've upgraded to 10.1.13 it is broken again! Here's the error I get: An error occurred at line: [40] in the jsp file: [/schDistImportResults.jsp] The method isMultipartContent(ServletRequestContext) is undefined for the type FileUpload 39: 40: boolean isMultipart = FileUpload.isMultipartContent(new ServletRequestContext(request)); 41: > An error occurred at line: [133] in the jsp file: [/schDistImportResults.jsp] ServletFileUpload cannot be resolved to a type 131: 132: DiskFileItemFactory factory = new DiskFileItemFactory(); // Create a factory for disk-based file items 133: ServletFileUpload upload = new ServletFileUpload(factory); // Create a new file upload handler 134: List items = upload.parseRequest(new ServletRequestContext(request)); // Parse the request 135: Iterator iter = items.iterator(); // Process the uploaded items 136: FileItem item = null; I've checked the RELEASE-NOTES, FAQ and searched the web. I've checked the UploadFile class (no clue) and looked for examples, but none resembled my app. I tried reverting back to the program version I had with 9.0.41, but that didn't work. Here is all I changed in the program between Tomcat versions 9.0.41 and 10.0.17 (which worked): Code: 26,28c26,28 < <%@ page import="org.apache.commons.fileupload.*, < org.apache.commons.fileupload.disk.*, < org.apache.commons.fileupload.servlet.*, --- > <%@ page import="org.apache.tomcat.util.http.fileupload.*, > org.apache.tomcat.util.http.fileupload.disk.*, > org.apache.tomcat.util.http.fileupload.servlet.*, 40c40 < boolean isMultipart = FileUpload.isMultipartContent(request); --- > boolean isMultipart = FileUpload.isMultipartContent(new > ServletRequestContext(request)); 134c134 < List items = upload.parseRequest(request); // Parse the request --- > List items = upload.parseRequest(new ServletRequestContext(request)); > // Parse the request I have quite a few programs that use the FileUpload methods. Does anyone know how to fix this latest breakage? Thanks --Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FileUpload class not working with Tomcat 10.1
On 10/11/2023 16:49, Mark Foley wrote: I recently upgraded from Tomcat 10.0.17 to 10.1.13. When I previously upgraded from 9.0.41 to 10.0.17 (back in 2/22) the FileUpload class broke. I fixed that thanks to postings on stackoverflow, but now that I've upgraded to 10.1.13 it is broken again! Here's the error I get: An error occurred at line: [40] in the jsp file: [/schDistImportResults.jsp] The method isMultipartContent(ServletRequestContext) is undefined for the type FileUpload Tomcat's internal fork of Commons FileUpload isn't intended for applications to use. It is not a full fork - just a limited subset of the functionality Tomcat needs to implement the Servley upload API. If you want to use Commons File Upload, add the JAR to your web application and use it. Alternatively, if you want to use the Servlet upload API then use that. If the javax.sevlet -> jakarta.servlet transition means you can't use your preferred version of Commons File Upload in Tomcat 10.1.x (very likely) then run your preferred version of Commons File Upload through Tomcat's migration tool for Jakarta EE and use the converted version of Commons File Upload in your web application. Depending on Tomcat internals is very likely to lead to breakage. Mark 39: 40: boolean isMultipart = FileUpload.isMultipartContent(new ServletRequestContext(request)); 41: An error occurred at line: [133] in the jsp file: [/schDistImportResults.jsp] ServletFileUpload cannot be resolved to a type 131: 132: DiskFileItemFactory factory = new DiskFileItemFactory(); // Create a factory for disk-based file items 133: ServletFileUpload upload = new ServletFileUpload(factory); // Create a new file upload handler 134: List items = upload.parseRequest(new ServletRequestContext(request)); // Parse the request 135: Iterator iter = items.iterator(); // Process the uploaded items 136: FileItem item = null; I've checked the RELEASE-NOTES, FAQ and searched the web. I've checked the UploadFile class (no clue) and looked for examples, but none resembled my app. I tried reverting back to the program version I had with 9.0.41, but that didn't work. Here is all I changed in the program between Tomcat versions 9.0.41 and 10.0.17 (which worked): Code: 26,28c26,28 < <%@ page import="org.apache.commons.fileupload.*, < org.apache.commons.fileupload.disk.*, < org.apache.commons.fileupload.servlet.*, --- <%@ page import="org.apache.tomcat.util.http.fileupload.*, org.apache.tomcat.util.http.fileupload.disk.*, org.apache.tomcat.util.http.fileupload.servlet.*, 40c40 < boolean isMultipart = FileUpload.isMultipartContent(request); --- boolean isMultipart = FileUpload.isMultipartContent(new ServletRequestContext(request)); 134c134 < List items = upload.parseRequest(request); // Parse the request --- List items = upload.parseRequest(new ServletRequestContext(request)); // Parse the request I have quite a few programs that use the FileUpload methods. Does anyone know how to fix this latest breakage? Thanks --Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FileUpload class not working with Tomcat 10.1
On Fri, 10 Nov 2023 17:11:59 Mark Thomas
> On 10/11/2023 16:49, Mark Foley wrote:
> > I recently upgraded from Tomcat 10.0.17 to 10.1.13. When I previously
> > upgraded
> > from 9.0.41 to 10.0.17 (back in 2/22) the FileUpload class broke. I fixed
> > that
> > thanks to postings on stackoverflow, but now that I've
> > upgraded to 10.1.13 it is broken again! Here's the error I get:
> >
> > An error occurred at line: [40] in the jsp file: [/schDistImportResults.jsp]
> > The method isMultipartContent(ServletRequestContext) is undefined for the
> > type FileUpload
>
> Tomcat's internal fork of Commons FileUpload isn't intended for
> applications to use. It is not a full fork - just a limited subset of
> the functionality Tomcat needs to implement the Servley upload API.
>
> If you want to use Commons File Upload, add the JAR to your web
> application and use it.
>
> Alternatively, if you want to use the Servlet upload API then use that.
>
> If the javax.sevlet -> jakarta.servlet transition means you can't use
> your preferred version of Commons File Upload in Tomcat 10.1.x (very
> likely) then run your preferred version of Commons File Upload through
> Tomcat's migration tool for Jakarta EE and use the converted version of
> Commons File Upload in your web application.
>
> Depending on Tomcat internals is very likely to lead to breakage.
>
> Mark
Thanks for your quick reply. Whatever I've been using keeps breaking. I had it
working in 9.0.14 and earlier, then it broke with 10.0.17 and I fixed that, now
it's broken again with 10.1.13. So, my "prefered" solution is whatever is
recommended and is likely to continue to be supported without breaking in future
Tomcats.
What do you recommend? And do you have a quickie template somewhere which shows
the basic include(s) and method I need? I really don't do anything very fancy.
My current "basic" implementation is:
<%@ page import="org.apache.tomcat.util.http.fileupload.*,
org.apache.tomcat.util.http.fileupload.disk.*,
org.apache.tomcat.util.http.fileupload.servlet.*,
org.apache.commons.io.*" %>
DiskFileItemFactory factory = new DiskFileItemFactory();
ServletFileUpload upload = new ServletFileUpload(factory);
List items = upload.parseRequest(new ServletRequestContext(request));
Iterator iter = items.iterator();
FileItem item = null;
while (iter.hasNext())
{
item = (FileItem) iter.next();
resultsFile = new File(getServletContext().getRealPath("") +
"/tmp/schTaxResults.txt");
try { item.write(resultsFile); }
catch ( Exception e) { out.println("Exception: " + e); }
}
If you could tell me what the officially prefered Apache Tomcat FileUpload
mechanism is, and what the correct jar and functions are to accomplish the
above, I'd be
very grateful!
Thanks --Mark
> > [deleted]
> > I've checked the RELEASE-NOTES, FAQ and searched the web. I've checked the
> > UploadFile class (no clue) and looked for examples, but none resembled my
> > app.
> > I tried reverting back to the program version I had with 9.0.41, but that
> > didn't
> > work.
> >
> > Here is all I changed in the program between Tomcat versions 9.0.41 and
> > 10.0.17 (which worked):
> > Code:
> > [deleted]
> >
> > I have quite a few programs that use the FileUpload methods. Does anyone
> > know how to fix this latest breakage?
> >
> > Thanks --Mark
> >
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
CredentialHandler not working for MD5
Logging into manager using MD5 works in 9.0.73 but now fails in 9.0.74->current Steps to reproduce. Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 tomcat:UserDatabase:nobueno tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0 Step 2. Use the digest # and place it in tomcat-users.xml Step 3. Edit server.xml and add the CredentialHandler to use MD5 Step 4. Edit the web.xml in manager to say DIGEST UserDatabase Step 5 start tomcat and try to access the manager. On WIndows 2019 server/Chrome/OpenJDK11 type tomcat for the user and nobueno for the password. This would work on versions 9.0.73 and earlier This stopped working from 9.0.74 and onwards. The way to access the manager from 9.0.74+ is to use bb6c1c32b9b6df4f707c0e58f2c900e0 as the password. In other words the text in tomcat-user.xml is the password. Anyone have any ideas how to fix this? I have to use 9.0.74+ version of tomcat because of CVEs. Thank you all This e-mail and any files transmitted with it are the property of Arthrex, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 239-643-5553 and delete this message immediately from your computer. Any other use, retention, dissemination forwarding, printing or copying of this e-mail is strictly prohibited. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, while Arthrex uses virus protection, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
Re: CredentialHandler not working for MD5
Peter, On 11/10/23 13:27, Peter Otto wrote: Logging into manager using MD5 works in 9.0.73 but now fails in 9.0.74->current Steps to reproduce. Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 tomcat:UserDatabase:nobueno tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0 Step 2. Use the digest # and place it in tomcat-users.xml Step 3. Edit server.xml and add the CredentialHandler to use MD5 Step 4. Edit the web.xml in manager to say DIGEST UserDatabase Step 5 start tomcat and try to access the manager. On WIndows 2019 server/Chrome/OpenJDK11 type tomcat for the user and nobueno for the password. This would work on versions 9.0.73 and earlier This stopped working from 9.0.74 and onwards. The way to access the manager from 9.0.74+ is to use bb6c1c32b9b6df4f707c0e58f2c900e0 as the password. In other words the text in tomcat-user.xml is the password. Anyone have any ideas how to fix this? I have to use 9.0.74+ version of tomcat because of CVEs. If you temporarily remove the LockOutRealm, does the correct password work? If you upgrade to 9.0.82, does the correct password work? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Testing OpenSSL integration using the FFM API with Tomcat 11 on Windows 10
Mark, On 11/10/23 10:27, Mark Thomas wrote: On 10/11/2023 14:44, Eduardo Guadalupe wrote: Thanks Mark, I found the issue, I assumed OpenSSL was installed because I had seen in some logs the message “OpenSSL successfully initialized [OpenSSL 3.0.11 19 Sep 2023].” That may be the OpenSSL version that is static linked to the Tomcat Native library. I don't think you can use that directly. I would think that WOULD work (once loaded), except Tomcat is specifically attempting to load ssl.dll in this case. IMO it's probably not worth it to allow either libtcnative or libssl. I think you should pick one or the other and load the one you expect to use. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FileUpload class not working with Tomcat 10.1
Mark,
On 11/10/23 12:53, Mark Foley wrote:
On Fri, 10 Nov 2023 17:11:59 Mark Thomas
On 10/11/2023 16:49, Mark Foley wrote:
I recently upgraded from Tomcat 10.0.17 to 10.1.13. When I previously upgraded
from 9.0.41 to 10.0.17 (back in 2/22) the FileUpload class broke. I fixed that
thanks to postings on stackoverflow, but now that I've
upgraded to 10.1.13 it is broken again! Here's the error I get:
An error occurred at line: [40] in the jsp file: [/schDistImportResults.jsp]
The method isMultipartContent(ServletRequestContext) is undefined for the type
FileUpload
Tomcat's internal fork of Commons FileUpload isn't intended for
applications to use. It is not a full fork - just a limited subset of
the functionality Tomcat needs to implement the Servley upload API.
If you want to use Commons File Upload, add the JAR to your web
application and use it.
Alternatively, if you want to use the Servlet upload API then use that.
If the javax.sevlet -> jakarta.servlet transition means you can't use
your preferred version of Commons File Upload in Tomcat 10.1.x (very
likely) then run your preferred version of Commons File Upload through
Tomcat's migration tool for Jakarta EE and use the converted version of
Commons File Upload in your web application.
Depending on Tomcat internals is very likely to lead to breakage.
Mark
Thanks for your quick reply. Whatever I've been using keeps breaking. I had it
working in 9.0.14 and earlier, then it broke with 10.0.17 and I fixed that, now
it's broken again with 10.1.13. So, my "prefered" solution is whatever is
recommended and is likely to continue to be supported without breaking in future
Tomcats.
What do you recommend? And do you have a quickie template somewhere which shows
the basic include(s) and method I need? I really don't do anything very fancy.
My current "basic" implementation is:
<%@ page import="org.apache.tomcat.util.http.fileupload.*,
org.apache.tomcat.util.http.fileupload.disk.*,
org.apache.tomcat.util.http.fileupload.servlet.*,
org.apache.commons.io.*" %>
DiskFileItemFactory factory = new DiskFileItemFactory();
ServletFileUpload upload = new ServletFileUpload(factory);
List items = upload.parseRequest(new ServletRequestContext(request));
Iterator iter = items.iterator();
FileItem item = null;
while (iter.hasNext())
{
item = (FileItem) iter.next();
resultsFile = new File(getServletContext().getRealPath("") +
"/tmp/schTaxResults.txt");
try { item.write(resultsFile); }
catch ( Exception e) { out.println("Exception: " + e); }
}
If you could tell me what the officially prefered Apache Tomcat FileUpload
mechanism is, and what the correct jar and functions are to accomplish the
above, I'd be
very grateful!
No offense, but the above is horrifying. All that Java code in a JSP
makes me cringe. You can do this however you want, but I'd recommend
putting Java code into a proper servlet and letting the JSP handle
display only.
Anyway, I'll get off my soapbox.
The easiest thing IMO for you to do is stop trying to parse the upload
yourself and use the container. You must have migrated this application
forward for like 10 years or something if you are still using a separate
library to handle multipart-form-uploads. This has been a part of the
code servlet API for some time, now, and you should use it:
import jakarta.servlet.http.Part;
...
String contentType = request.getContentType();
if(null == contentType || !contentType.startsWith("multipart/form-data;")) {
logger.warn("Received non-multipart request");
throw new IllegalStateException("Expected multi-part");
}
java.io.File tmpDir =
(java.io.File)request.getServletContext().getAttribute("javax.servlet.context.tempdir");
java.io.File targetFile = new java.io.File(tmpDir, "schTaxResults.txt");
Part fileUpload = request.getPart("param-name");
if(null != fileUpload) {
fileUpload.write(targetFile.getAbsolutePath());
}
I have made some obvious and not-so-obvious changes, here. First, you
don't need a separate library: you are relying on the container for the
multi-part handling.
Second, I have changed from uploading the file directly into the servlet
context (the live running application~) into a temporary directory. If
you want to serve this file back out to clients, you may want to use
WebDAV or some other protocol rather than file-upload, or maybe not.
If you want to serve this file back to clients, I *highly* recommend
creating a directory OUTSIDE your web application where you can push
uploaded files, and then use something like to allow
Tomcat to load content from that location, mounted on a path that won't
allow users to upload binaries, etc. that might get loaded by the
application.
You may want to be careful about how you are writing. If two requests
come-in at the same time, thee files may overwrite each other in
unpredictable ways.
-chris
Re: CredentialHandler not working for MD5
Chris, With 9.0.82, and the latest version 10, I get the same problem. So I assume it stopped working since 9.0.74 all the way up to 9.0.82 Removing the Realm LockOutRealm did not work either. Thanks From: Christopher Schultz Date: Friday, November 10, 2023 at 12:35 PM To: users@tomcat.apache.org Subject: Re: CredentialHandler not working for MD5 Peter, On 11/10/23 13:27, Peter Otto wrote: > Logging into manager using MD5 works in 9.0.73 but now fails in > 9.0.74->current > Steps to reproduce. > > Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 > tomcat:UserDatabase:nobueno > > tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0 > > > Step 2. Use the digest # and place it in tomcat-users.xml > > > roles="manager-gui,manager-script"/> > > > Step 3. Edit server.xml and add the CredentialHandler to use MD5 > > > resourceName="UserDatabase"> > className="org.apache.catalina.realm.MessageDigestCredentialHandler" > algorithm="MD5" /> > > > > > > Step 4. Edit the web.xml in manager to say > > DIGEST > UserDatabase > > > Step 5 start tomcat and try to access the manager. > On WIndows 2019 server/Chrome/OpenJDK11 type tomcat for the user > and nobueno for the password. > > This would work on versions 9.0.73 and earlier > > This stopped working from 9.0.74 and onwards. > The way to access the manager from 9.0.74+ is to use > bb6c1c32b9b6df4f707c0e58f2c900e0 as the password. > In other words the text in tomcat-user.xml is the password. > > Anyone have any ideas how to fix this? I have to use 9.0.74+ version of > tomcat because of CVEs. If you temporarily remove the LockOutRealm, does the correct password work? If you upgrade to 9.0.82, does the correct password work? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This e-mail and any files transmitted with it are the property of Arthrex, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 239-643-5553 and delete this message immediately from your computer. Any other use, retention, dissemination forwarding, printing or copying of this e-mail is strictly prohibited. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, while Arthrex uses virus protection, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
Re: CredentialHandler not working for MD5
Peter, On 11/10/23 16:30, Peter Otto wrote: With 9.0.82, and the latest version 10, I get the same problem. So I assume it stopped working since 9.0.74 all the way up to 9.0.82 Removing the Realm LockOutRealm did not work either. Thanks for double-checking both of those. I don't see anything in the changelog that seems like it would be related. Thing I suspect are related were in an earlier release. Are you able to run under a debugger, and are you comfortable doing that? It's pretty easy to set a breakpoint in the Realm and/or CredentialHandler to see what's being done when you try to authenticate. -chris From: Christopher Schultz Date: Friday, November 10, 2023 at 12:35 PM To: users@tomcat.apache.org Subject: Re: CredentialHandler not working for MD5 Peter, On 11/10/23 13:27, Peter Otto wrote: Logging into manager using MD5 works in 9.0.73 but now fails in 9.0.74->current Steps to reproduce. Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 tomcat:UserDatabase:nobueno tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0 Step 2. Use the digest # and place it in tomcat-users.xml Step 3. Edit server.xml and add the CredentialHandler to use MD5 Step 4. Edit the web.xml in manager to say DIGEST UserDatabase Step 5 start tomcat and try to access the manager. On WIndows 2019 server/Chrome/OpenJDK11 type tomcat for the user and nobueno for the password. This would work on versions 9.0.73 and earlier This stopped working from 9.0.74 and onwards. The way to access the manager from 9.0.74+ is to use bb6c1c32b9b6df4f707c0e58f2c900e0 as the password. In other words the text in tomcat-user.xml is the password. Anyone have any ideas how to fix this? I have to use 9.0.74+ version of tomcat because of CVEs. If you temporarily remove the LockOutRealm, does the correct password work? If you upgrade to 9.0.82, does the correct password work? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This e-mail and any files transmitted with it are the property of Arthrex, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 239-643-5553 and delete this message immediately from your computer. Any other use, retention, dissemination forwarding, printing or copying of this e-mail is strictly prohibited. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, while Arthrex uses virus protection, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
