Great to hear that, I will wait a bit then merge the PR and issue a
new test build, thanks a lot for testing this version!!!
Cheers
Łukasz
czw., 1 wrz 2022 o 09:25 i...@flyingfischer.ch
napisał(a):
>
> Resolved the other "phenomenon". Was an issue on my side around
> Modeldriven and mixed up
Resolved the other "phenomenon". Was an issue on my side around
Modeldriven and mixed up getters.
Best regards
Markus
Am 01.09.22 um 09:07 schrieb i...@flyingfischer.ch:
Thanks Łukasz
looks good to me. Provides the possibility to opt out on any given
fine grained use case while maintaing a
Thanks Łukasz
looks good to me. Provides the possibility to opt out on any given fine
grained use case while maintaing a general stricter approach.
Best regards
Markus
PS: looking right now into another strange phenomenon on a different
topic while testing. I will open a separate thread. I
After re-thinking my idea with a dedicated stack, I prepared a PR
which allows to disable those interceptors
https://issues.apache.org/jira/browse/WW-5218
In other ways no one will adopt them, enforcing users to use them with
the option to disable them should help raise more notions about CSP,
+1 for dedicated stack, but not sure if we should name it "default secure
stack" as it implies that the other stacks are not secure.
My 2ct on this
Best Regards
Johannes
i...@flyingfischer.ch schrieb am Mi., 31. Aug.
2022, 14:20:
> Creating a new default secure stack sounds good to me.
Creating a new default secure stack sounds good to me. Thank for
considering.
As far as I can see there would be 4 additional interceptors in this
secure stack:
CoepInterceptor.java
CoopInterceptor.java
CspInterceptor.java
FetchMetadataInterceptor.java
And the appropriate resources used by
I think disabling them doesn't make sense - these are just
interceptors so you can create your own stack without them. I would
rather create a new default secure stack and move those interceptors
into that stack, wdyt?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
I have a use case, where it is no option to muddle with headers. The
headers are dynamically controlled by the App.
So I really would need an option to remove any well-intentioned, but not
wanted headers. This seems not easily possible with the added CSP in 6.x
version.
Any chance that such
Thanks Łukasz
Any chance to disable this on domain basis, or even totally? I fear
coopInterceptor.exemptedPaths will not be sufficiant in my case.
Best regards
Markus
Am 30.08.22 um 16:22 schrieb Łukasz Lenart:
CSP was added in 6.x version
CSP was added in 6.x version
https://struts.apache.org/core-developers/coop-interceptor
https://struts.apache.org/core-developers/coop-interceptor
https://struts.apache.org/core-developers/fetch-metadata-interceptor
W dniu wt., 30.08.2022 o 15:54 i...@flyingfischer.ch
napisał(a):
> It looks
It looks like an cross-site issue: The error does only appear, when the
request is called from a third party domain. When called from a
subdomain of the main domain, the error does not appear.
Regards
Markus
Am 30.08.22 um 15:35 schrieb i...@flyingfischer.ch:
I am puzzled, calling the same
I am puzzled, calling the same request on the console works:
curl -i -X OPTIONS https://domain/context/mypath?url=urlEncodedUrl
HTTP/1.1 302
Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1
Vary: Sec-Fetch-Dest,Sec-Fetch-Mode,Sec-Fetch-Site,Sec-Fetch-User
Indeed I use
http://xmlns.jcp.org/xml/ns/javaee;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd; version="3.1">
Regards
Markus
Am 30.08.22 um 14:39 schrieb Lukasz Lenart:
The action and the result actually do exist as redirectAction
otherpath
${url}
This works:
GET /context/mypath?url=urlEncodedUrl HTTP/1.1"
This fails:
OPTIONS /context/mypath?url=urlEncodedUrl HTTP/1.1" 404
But yes, strange that OPTIONS returns
Do you use the proper Servlet 3.1 headers in web.xml?
http://xmlns.jcp.org/xml/ns/javaee;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd;
Thanks. I see "...and result 403..." so looks like the underlying action
has responded with 403 i.e. forbidden and you haven't defined such
result for this action in struts.xml? wdyt?
On 8/29/2022 8:32 PM, i...@flyingfischer.ch wrote:
Hi Yasser
sure.
Regards
Markus
29-08-2022 16:12:47.8
The corresponding request is
OPTIONS /context/mypath?url=urlEncodedUrl HTTP/1.1" 404
The same request as GET or POST will work fine. OPTIONS and HEAD
requests crash.
Regards
Markus
Am 29.08.22 um 18:02 schrieb i...@flyingfischer.ch:
Hi Yasser
sure.
Regards
Markus
29-08-2022 16:12:47.8
Hi Yasser
sure.
Regards
Markus
29-08-2022 16:12:47.8 WARN org.apache.struts2.dispatcher.Dispatcher -
Could not find action or result: /context/mypath?url=urlEncodedUrl
No result defined for action ch.xx.xx.xx and result 403 - action -
Hi Markus,
I see corresponding codes in Struts:
if (devMode) {
LOG.error("Could not find action or result: {}", uri, e);
} else if (LOG.isWarnEnabled()) {
LOG.warn("Could not find action or result: {}", uri, e);
}
so it seems you should also have
If I see this correctly, this happens only with OPTIONS and HEAD
requests
Am 29.08.22 um 14:09 schrieb i...@flyingfischer.ch:
After removing commons-digester3-3.2 and leaving commons-digester-2.1
only, I still get the Warnings/Errors in production:
WARN
After removing commons-digester3-3.2 and leaving commons-digester-2.1
only, I still get the Warnings/Errors in production:
WARN org.apache.struts2.dispatcher.Dispatcher - Could not find action or
result: /context/mypath?url=urlEncodedUrl
Seems to be a new issue in Struts6 and not really
Removing commons-digester-2.1 gives:
java.lang.NoClassDefFoundError: org/apache/commons/digester/Rule
I am able to remove commons-digester3-3.2: the application does start.
I will replace the application in production and check, if the
Warnings/Errors from
Could you exclude commons-digester in the Tiles plugin?
Regards
Łukasz
pon., 29 sie 2022 o 10:11 i...@flyingfischer.ch
napisał(a):
>
> hmm, in production I see from time to time:
>
> WARN org.apache.struts2.dispatcher.Dispatcher - Could not find action or
> result:
hmm, in production I see from time to time:
WARN org.apache.struts2.dispatcher.Dispatcher - Could not find action or
result: /context/mypath?url=urlEncodedUrl
The action exists and the result also, as redirectAction
otherpath
${url}
This behaviour seems
Works fine here. Tested with tiles-plugin.
Best regards
Markus
Am 25.08.22 um 07:52 schrieb Lukasz Lenart:
Hello,
This is the first patch version of Struts 6.x series. Please take the
time and test the bits - any help is appreciated. Please report any
problems you will spot.
Here are the
czw., 25 sie 2022 o 14:09 Johannes Geppert napisał(a):
>
> Hi Lukasz,
>
> I can confirm that 6.0.2 works well with the aws serverless integration.
Great to hear that, thanks a lot for testing it :)
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Hi Lukasz,
I can confirm that 6.0.2 works well with the aws serverless integration.
Thanks for the new release.
Best Regards
Johannes
#
web: http://www.jgeppert.com
twitter: http://twitter.com/jogep
Am Do., 25. Aug. 2022 um 07:52 Uhr schrieb
Hello,
This is the first patch version of Struts 6.x series. Please take the
time and test the bits - any help is appreciated. Please report any
problems you will spot.
Here are the changes from the previous 6.0.0 version:
https://github.com/apache/struts/releases/tag/STRUTS_6_0_2
Staging Maven
28 matches
Mail list logo
