weblegacy / struts1 Goto Github PK

Hi,

I migrated our app from old struts to your wonderfull project (thanks a lot!)
As we nee support for jakarta we are on 1.5.RC1. Almost everything works for now, but a simple FormFile upload page is not working (besides your commons-fileupload2-* we are using commons-fileupload-1.3.1.jar on classpath):

Caused by: java.lang.IllegalArgumentException: Cannot invoke xxxForm.setFormfile on bean class 'class xxx.Form' - argument type mismatch - had objects of type "java.util.ArrayList" but expected signature "org.apache.struts.upload.FormFile"
at deployment.7.ear.e.war//org.apache.commons.beanutils.PropertyUtilsBean.invokeMethod(PropertyUtilsBean.java:2196)
at deployment7.ear.e.war//org.apache.commons.beanutils.PropertyUtilsBean.setSimpleProperty(PropertyUtilsBean.java:2109)
at deployment.7.ear.e.war//org.apache.commons.beanutils.PropertyUtilsBean.setNestedProperty(PropertyUtilsBean.java:1915)
at deployment.7.ear.e.war//org.apache.commons.beanutils.PropertyUtilsBean.setProperty(PropertyUtilsBean.java:2022)
at deployment.7.ear.e.war//org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:1018)
at deployment.ear.e.war//org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:823)
at deployment.7.ear.e.war//org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:431)
at deployment.7.ear.e.war//org.apache.struts.util.RequestUtils.populate(RequestUtils.java:502)
... 68 more
Caused by: java.lang.IllegalArgumentException: argument type mismatch
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at deployment.er.war//org.apache.commons.beanutils.PropertyUtilsBean.invokeMethod(PropertyUtilsBean.java:2128)
... 75 more

jsp:

<html:file name="uploadForm" property="formFile" style="height: 20px; font-size: 10px;"/>

form

public FormFile getFormFile() {
    return formFile;
}

public void setFormFile(FormFile formFile) {
    this.formFile = formFile;
}

what am I missing or is it a bug?

Thanks a lot again for that project!

Hello,

i have downloaded the complete project and when i perform a maven build.. i am getting the following error. is there a compiled jar available with jakarta namespace which i can use directly instead of building

DEBUG] Configuring mojo org.apache.maven.plugins:maven-enforcer-plugin:3.1.0:enforce from plugin realm ClassRealm[plugin>org.apache.maven.plugins:maven-enforcer-plugin:3.1.0, parent: sun.misc.Launcher$AppClassLoader@55f96302]
[WARNING] Error injecting: org.apache.maven.plugins.enforcer.EnforceMojo
java.lang.NoClassDefFoundError: org/apache/maven/enforcer/rule/api/EnforcerRuleException
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
at java.lang.Class.getDeclaredConstructors(Class.java:2020)
at com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
at com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
at com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:657)
at com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:875)
at com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:798)
at com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:281)
at com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:213)
at com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:998)
at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1031)
at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:994)
at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1044)
at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:54)
at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:126)
at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:46)
at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1009)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1059)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1005)
at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:36)
at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81)
at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:263)
at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:255)
at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:543)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.ClassNotFoundException: org.apache.maven.enforcer.rule.api.EnforcerRuleException
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
... 55 more
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Struts ............................................. FAILURE [ 0.156 s]

We have html:submit fields that have XML Entities for German Umlaut in the value of the value attribute, for example

<html:submit property="..." value="Zurück"/>

The ü XML Entity should display German Umlaut ü on the page but instead the XML text is "Zur%uuml;ck" without replacing the XML Entity ü with German Umlaut ü.

The reason is that during rendering of the value of the value property the TagUtils.getInstance().filter(..) method is called which calls ResponseUtils.filter(). In ResponseUtils.filter() the input string is examined and if a '&' is found it is prepended with &. So in my case the input value of ResponseUtils.filter is "Zurück" and the return is "Zur&aml;ück" and as a result the ü XML Entity is not replaced with the German Umlaut.

From my point of view, the ResponseUtils.filter class should have a list of valid XML entities that are accepted and not escaped, so that the result string does not contain the XML Entity but the expected text.

The next release will be with jakartaEE as documented on the project's landing page. The version of the next release is also documented to be 1.4.5.

Wouldn't it be better to increase the major version number than the patch level number as the change to JakartaEE seems to be a breaking change and with Semantic Versioning a breaking change should increase the major number? Otherwise, dynamic versions in build files (for example 1.4.+ in a Gradle build file) would use the JakartaEE version as soon as published in a Maven repo. In addition, security fixes for the JavaEE version would be difficult if the JakartaEE version would be 1.4.5, as no free patch level number would then be free after 1.4.4

If I cancel an action using taglib html:cancel on a jsp page it is not propagated to the action if coming from a multipart request, for standard requests its fine (see the two sceenshots from debug mode attached)

Discussed in #30

Necessary?
ibissource/ibis-struts@c7f2aa4

We have a legacy project that still uses Struts 1.x heavily. Other aspects of the project have been updated and as part of that we want to move from Tomcat 8.5+Spring 5.3.x to Tomcat 10+Spring 6.x but Struts 1.x is holding us back. I just came across this project and am impressed to see all the modernization you've done. What are you plans going forward with this project? If possible, I'd love to use this but EE 10 is what we need.

Hi @albfernandez,

FYI: I found your repo of struts1 and see some meaningful changes that I would like to add to my repo.

Interesting commits:

• albfernandez/struts1@d1edcdc
• albfernandez/struts1@3f06fa0
• albfernandez/struts1@3bf29b1
• albfernandez/struts1@1b0cc5e

Hint for me: CVE-2008-2025 is fixed with 3e1c6a8 --> add it to README

Greetings
Stefan

In the commons-fileupload2 dependency, the getString(Charset cs) method in FileItem now throws an IOException, which it did not previously. I was able to mitigate this in the weblegacy-chain branch by propagating the error anywhere the method was referenced, although I imagine going forward a more robust solution would be preferred, which is why I'm making note of it here.

This worked at least differently in struts 1.3.x:

If your default resource file is called ApplicationResources.properties (all others are called eg ApplicationResources_de.properties) it should fall back to that one in case you have a browser set to a non supported locale (eg if missing ApplicationResources_bg.properties).

In struts 1.5 it resolves to the locale from the server instead to ApplicationResources.properties, which is a strange behavior I would say.

I will try to investigate, maybe I can find out what changed that.

Thanks to this project for keeping legacy Struts 1.x solutions secured. It is great to see.

I recently learned of CVE-2023-34396 which was published in June 2023, and it says it affects Struts 2.x and 6.x, but the affected versions list all versions, including 1.x. See: https://www.cve.org/CVERecord?id=CVE-2023-34396

In looking at this, I believe it may also affect Struts 1.x, particularly in how multipart form uploads are handled. I think the CVE primarily affects CommonsMultipartRequestHandler:
https://github.com/weblegacy/struts1/blob/main/core/src/main/java/org/apache/struts/upload/CommonsMultipartRequestHandler.java

Here's how the CVE was fixed in Struts 2.5.31, as shown here: https://github.com/apache/struts/compare/STRUTS_2_5_30...STRUTS_2_5_31?diff=split&w=#diff-9c690161b1ba4ba15ccf8b3991857785b66c99dd2a87a95543b18e411deeb17f

Thoughts?

Hello,
I'm facing a problem using this version of struts 1 because in my project we use a protected method "initModuleDataSources" from ActionServlet.
I would like to know if there is any reason to this method being removed from this version. And if exists a reason, what method I could use to adapt my code?

Thank you.

We are considering upgrading our legacy project using weblegacy/struts1.

• We are curious if the team responsible for maintaining this project conducts active scans to identify new vulnerabilities.
• Will the maintenance team address and fix any potential vulnerabilities in the future?
• Can widely used market tools like Prisma scans detect vulnerabilities in this project?