There is one problem with using other ELs - conversion. For example:
{1,2,3}
such a statement will be evaluated by MVEL to: new Object[]{Integer,
Integer, Integer}
but with Ognl it will be: new List{Integer, Integer, Integer}
and then Struts2/Xwork built-in conversion logic will convert just
2013/9/12 Dale Newfield d...@newfield.org:
On Sep 12, 2013, at 11:34 AM, Ken McWilliams ken.mcwilli...@gmail.com wrote:
prefix, IE: OGNL: or EL:
I've long argued that %{}, #{}, ${} provides this already, and that this
wrapping should therefore not be optional in preparation for when
There should be a default EL (OGNL) for backward compatibility. Any IDE
will show you API breakage changes but none of them will pickup changes to
tag string requirements changes in the JSPs!
It's probably a good idea to force the user to explicitly state the default
in struts.xml but such an
Hi,
I have spent some time on MVEL replacement for OGNL and what I can say
it will allow to clarify few things - like dependencies or overused
conversion and so on. The real problem is with Xwork itself as it
doesn't support plugins so it's a bit hard to replace OGNL in all
places.
And it would
Am 12.09.13 11:35, schrieb Lukasz Lenart:
Hi,
I have spent some time on MVEL replacement for OGNL and what I can say
it will allow to clarify few things - like dependencies or overused
conversion and so on. The real problem is with Xwork itself as it
doesn't support plugins so it's a bit
Meant to provide an example of their configuration and use:
http://tiles.apache.org/2.2/framework/tutorial/advanced/el-support.html
On Thu, Sep 12, 2013 at 9:34 AM, Ken McWilliams ken.mcwilli...@gmail.comwrote:
I like the way Apache Tiles handles EL, from a user standpoint. I think
I like the way Apache Tiles handles EL, from a user standpoint. I think
everywhere an expression can occurs an AtributeEvaluatorFactory determines
which registered ELEvaluator to used based on prefix, IE: OGNL: or EL:.
This could be extended to pattern matching too. Regex vs NamedVariable for
On Sep 12, 2013, at 11:34 AM, Ken McWilliams ken.mcwilli...@gmail.com wrote:
prefix, IE: OGNL: or EL:
I've long argued that %{}, #{}, ${} provides this already, and that this
wrapping should therefore not be optional in preparation for when something
other than %{} might be functional.
-Dale
Am 11.09.13 07:54, schrieb Lukasz Lenart:
2013/9/11 David Black dbl...@atlassian.com:
On 9 September 2013 20:52, Christian Grobmeier grobme...@gmail.com wrote:
From a security standpoint we may have the man power to improve things.
For example, if we manage to disable static method calls
Yes, but we can do it via custom SecurityManager - as I understand
OGNL uses SM internally quite often.
2013/9/11 Christian Grobmeier grobme...@gmail.com:
Am 11.09.13 07:54, schrieb Lukasz Lenart:
2013/9/11 David Black dbl...@atlassian.com:
On 9 September 2013 20:52, Christian Grobmeier
On 9 September 2013 20:52, Christian Grobmeier grobme...@gmail.com wrote:
Am 05.09.13 21:22, schrieb Lukasz Lenart:
2013/9/5 Christian Grobmeier grobme...@gmail.com:
Am 05.09.13 20:43, schrieb Lukasz Lenart:
Guys,
are you serious? are you blaming OGNL? the hammer? 100% of
vulnerability
2013/9/11 David Black dbl...@atlassian.com:
On 9 September 2013 20:52, Christian Grobmeier grobme...@gmail.com wrote:
Am 05.09.13 21:22, schrieb Lukasz Lenart:
2013/9/5 Christian Grobmeier grobme...@gmail.com:
Am 05.09.13 20:43, schrieb Lukasz Lenart:
Guys,
are you serious? are you blaming
Am 05.09.13 21:22, schrieb Lukasz Lenart:
2013/9/5 Christian Grobmeier grobme...@gmail.com:
Am 05.09.13 20:43, schrieb Lukasz Lenart:
Guys,
are you serious? are you blaming OGNL? the hammer? 100% of
vulnerability related to OGNL was our - developers - fault. We did use
(and still do) the
I'm not saying that users can't have other options - and have few
support for few ELs is a nice idea and bad as well - more to support
;-)
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
2013/9/5 Steven Benitez steven.beni...@gmail.com:
I support EL3 over OGNL, but I realize this
When working within JSPs, OGNL feels out of place after using the standard
tag libraries and EL for so long. Using OGNL in JSP also limits the use of
existing tag libraries that are built using EL without some type of
javax.el.ELResolver that can access the ValueStack or the Action for the
On Fri, Sep 6, 2013 at 11:59 AM, Aaron Johnson johnson.aar...@gmail.comwrote:
Using OGNL in JSP also limits the use of
existing tag libraries that are built using EL without some type of
javax.el.ELResolver that can access the ValueStack or the Action for the
request.
S2's response wrapper
2013/9/6 Aaron Johnson johnson.aar...@gmail.com:
Struts Enhancements:
Better integration with JSP views
Deferred Value expressions (evaluate now vs. evaluate later)
Later? When? There is no 5 phases of building a page like in JSF -
when view is rendered there is no more 'later'. Do I miss
2013/9/5 Christian Grobmeier grobme...@gmail.com:
Am 05.09.13 20:43, schrieb Lukasz Lenart:
Guys,
are you serious? are you blaming OGNL? the hammer? 100% of
vulnerability related to OGNL was our - developers - fault. We did use
(and still do) the hammer in inappropriate way. Changing hammer
Am 05.09.13 20:43, schrieb Lukasz Lenart:
Guys,
are you serious? are you blaming OGNL? the hammer? 100% of
vulnerability related to OGNL was our - developers - fault. We did use
(and still do) the hammer in inappropriate way. Changing hammer is not
the solution!
The hammer is stuck at Apache
I support EL3 over OGNL, but I realize this will be an uphill battle. I've
used Struts2/Webwork with EL for years and I can continue to do that on my
own.
On Thu, Sep 5, 2013 at 3:22 PM, Lukasz Lenart lukaszlen...@apache.orgwrote:
2013/9/5 Christian Grobmeier grobme...@gmail.com:
Am 05.09.13
Guys,
are you serious? are you blaming OGNL? the hammer? 100% of
vulnerability related to OGNL was our - developers - fault. We did use
(and still do) the hammer in inappropriate way. Changing hammer is not
the solution!
Things related to ${} or %{} should be clarified - %{} is called an
Folks,
when researching on OGNL i found this link:
https://cwiki.apache.org/confluence/display/S2WIKI/OGNL+replacement
In 2008 Brian mentioned Security risks keep appearing along with OGNL
and collected the places where we use OGNL. Given the recent events I
thought it might be good to bring
-Original Message-
From: Christian Grobmeier grobme...@gmail.com
Date: Wed, 04 Sep 2013 15:04:06
To: Struts Developers Listdev@struts.apache.org
Reply-To: Struts Developers List dev@struts.apache.org
Subject: Doubting OGNL
Folks,
when researching on OGNL i found this link:
https
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Subject: Re: Doubting OGNL
keine rechtliche
Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen
wir keine Haftung fuer den Inhalt uebernehmen.
Subject: Re: Doubting OGNL
To: dev@struts.apache.org
From: umeshawas...@gmail.com
Date: Wed, 4 Sep 2013 13:13:20 +
As per my experience over
Isn't it already decoupled since OGNL is a separate project? I mean, of
course Struts 2 needs mediating code to support it, but how coupled is it
really?
Paul
On Wed, Sep 4, 2013 at 8:04 AM, Christian Grobmeier grobme...@gmail.comwrote:
Folks,
when researching on OGNL i found this link:
. Aufgrund der leichten Manipulierbarkeit von
E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Subject: Re: Doubting OGNL
To: dev@struts.apache.org
From: umeshawas...@gmail.com
Date: Wed, 4 Sep 2013 13:13:20 +
As per my experience over Stack
.
Subject: Re: Doubting OGNL
To: dev@struts.apache.org
From: umeshawas...@gmail.com
Date: Wed, 4 Sep 2013 13:13:20 +
As per my experience over Stack Overflow, every alternate question
on
Struts2 is related to OGNL syntax or user is not able to understand
dem Austausch von Informationen und entfaltet keine
rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit
von
E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Subject: Re: Doubting OGNL
To: dev@struts.apache.org
From: umeshawas
von Informationen und entfaltet keine
rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit
von
E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Subject: Re: Doubting OGNL
To: dev@struts.apache.org
From: umeshawas...@gmail.com
Date: Wed, 4 Sep 2013 13:13:20 +
Am 04.09.13 16:34, schrieb Dave Newton:
I'd looked in to replacing OGNL with MVEL, including the templating, but it
entailed a fairly extensive effort.
Not saying it isn't worth it; personally I'd like to see a few other
options and a simplification of the templates (and potential speedups).
von Informationen und entfaltet keine
rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Subject: Re: Doubting OGNL
To: dev@struts.apache.org
From: umeshawas...@gmail.com
Date: Wed, 4 Sep 2013 13:13:20 +
Christian, as I said, I am OK with the view laying using OGNL. If JSPs are
using that, I see no problem. But I should ask if the majority of
vulnerabilities are from the view layer or from the processor/controller
layer?
On Wed, Sep 4, 2013 at 10:20 AM, Christian Grobmeier
It's the params coming in that cause problems; everything else is under
developer control(-ish).
On Wed, Sep 4, 2013 at 11:31 AM, Paul Benedict pbened...@apache.org wrote:
Christian, as I said, I am OK with the view laying using OGNL. If JSPs are
using that, I see no problem. But I should ask
Here is a Struts2 - OGNL vulnerability breakdown.
View based OGNL Vulns:
- S2-001 http://struts.apache.org/release/2.3.x/docs/s2-001.html
- S2-013 http://struts.apache.org/release/2.3.x/docs/s2-013.html
- S2-014 http://struts.apache.org/release/2.3.x/docs/s2-014.html
Non-View based OGNL Vuln:
-
Am 04.09.13 17:38, schrieb Dave Newton:
It's the params coming in that cause problems; everything else is under
developer control(-ish).
The question is: if we replace OGNL, why would the same problems not
appear with a different expression language?
Two things come to my mind:
- OGNLs static
Informationen und entfaltet keine
rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Subject: Re: Doubting OGNL
To: dev@struts.apache.org
From: umeshawas...@gmail.com
Date: Wed, 4 Sep 2013 13:13:20
entfaltet keine
rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Subject: Re: Doubting OGNL
To: dev@struts.apache.org
From: umeshawas...@gmail.com
Date: Wed, 4 Sep 2013 13:13:20 +
As per my
Thank you Cameron for providing this list. I appreciate it. It helped me
alot.
Christian, what do you mean by sandboxing the ValueStack?
On Wed, Sep 4, 2013 at 10:44 AM, Cameron Morris cmor...@part.net wrote:
Here is a Struts2 - OGNL vulnerability breakdown.
View based OGNL Vulns:
-
Am 04.09.13 18:15, schrieb Paul Benedict:
Thank you Cameron for providing this list. I appreciate it. It helped me
alot.
+1
Christian, what do you mean by sandboxing the ValueStack?
Ah i am not sure if I express this well because I have just recently
digged deeper into OGNL/Struts.
As I
I'd looked in to replacing OGNL with MVEL, including the templating, but it
entailed a fairly extensive effort.
Not saying it isn't worth it; personally I'd like to see a few other
options and a simplification of the templates (and potential speedups).
Dave
On Wed, Sep 4, 2013 at 10:21 AM,
On Wed, Sep 4, 2013 at 6:20 PM, Christian Grobmeier grobme...@gmail.comwrote:
Am 04.09.13 18:15, schrieb Paul Benedict:
Thank you Cameron for providing this list. I appreciate it. It helped me
alot.
+1
Christian, what do you mean by sandboxing the ValueStack?
Ah i am not sure if I
A lot of my feelings about OGNL are summed up in a StackOverflow answer
of mine:
http://stackoverflow.com/a/341597/3474
A couple of points from there I'd like to stress:
JSTL and OGNL are not comparable. A few people have mentioned JSTL
today, but hopefully they were talking about EL. More
I prefer EL over OGNL, but the problem with removing OGNL in Struts 3 would
be that there isn't currently (that I am aware of) a way to use EL within
Velocity, FreeMarker, Thymleaf, etc. Not everyone uses JSP.
Someone could probably create ElValueStack and ElValueStackFactory
implementations.
Although Freemarker/Velocity doesn't have a JSP container, I think you can
somehow bridge the two.
Check out this blog post:
http://illegalargumentexception.blogspot.com/2008/04/java-using-el-outside-j2ee.html
On Wed, Sep 4, 2013 at 1:19 PM, Steven Benitez steven.beni...@gmail.comwrote:
I
I personally really like OGNL again this is in the view layer (which most
of this discussion is not concerned with). However if any of you that have
not watched the presentation of what EL3 offers you probably should:
http://www.youtube.com/watch?v=JEKpRjXL06w
But even with respect to the view
46 matches
Mail list logo
