When writing gatling simulations in scala, it is possible to access session attributes with #{} and with ${}. Both seem to do the same thing and I can't find anything in official doc or on SO defining their differences.
--> What is the difference between "$" and "#" in gatlings Expression Language when accessing session variables?
example
scenario("")
.exec(http("get foo")
.get("http://localhost/")
.check(jsonPath("$.foo").saveAs("foo")))
.exec(http("url from hashtag___").get("localhost/#{foo}")
.exec(http("url from dollarsign").get("localhost/${foo}")
The official doc acknowledges that both types exists, but doesn't say what the differences are
The ${} syntax is deprecated in favor of #{} but still works for now.
This deprecation is only mentioned in the upgrade guide, we'll add a warning in the page you mentioned.
Related
I'm a little confused about CVE-2022-22950 and the corresponding Spring advisory. The latter says that the vulnerability can be exploited through:
[...] specially crafted SpEL expression [...]
However, an application that allows users to craft SpEL expressions, allows these users to do pretty much anything. Including code injection, which has full impact on confidentiality, integrity, and availability. Plenty of other DoS opportunities here. Take this SpEL snippet for example, which executes the pwd command:
T(java.lang.Runtime).getRuntime().exec("pwd")
This command is fairly harmless, but it could be substituted with anything! Now, SpEL supports different EvaluationContexts which can be used to restrict what is allowed in a SpEL expression. E.g. the SimpleEvaluationContext forbids type expressions, like the one in the above SpEL snippet.
This leads me to 2 sets of questions:
Is CVE-2022-22950 even relevant for applications that use an unrestricted EvaluationContext for tainted SpEL expressions?
E.g. applications that trust selected users (like admins) enough to allow them executing arbitrary code? Or, ideally, have additional sand-boxing measures in place?
It seems that in such scenarios (questionable as they may be) this DoS vulnerability does not add anything new to the game. Would it make sense to improve the security advisory and warn against processing user-controlled SpEL code in a permissive EvaluationContext?
Does CVE-2022-22950 really require a "specially crafted SpEL expression"?
Or could an attacker exploit this DoS vulnerability by crafting data that will be processed by an otherwise harmless SpEL expression? E.g. sending a long list of query parameters to a web application that processes them using a hard-coded SpEL expression?
When I look at the code changes it seems that crafting the data might be enough? If so, the wording of the security advisory should be adjusted!
Looking at the original advisory (translated from Chinese) - https://4ra1n.love/post/Xrym_ZDj3/
It looks like exploiting this does require evaluation of arbitrary SpEL expressions. However - it allows for DoS even when using the SimpleEvaluationContext which is normally considered safe (or at least safer than EvaluationContext) and for example doesn't allow for RCE even when evaluating an arbitrary expression. But with this vulnerability, it will allow for a DoS.
The vulnerable code shown in the advisory -
SpelExpressionParser parser = new SpelExpressionParser();
Expression expr = parser.parseExpression("new int[1024*1024*1024][2]");
SimpleEvaluationContext context = SimpleEvaluationContext.forReadOnlyDataBinding().build();
expr.getValue(context);
The man page for apparmor.d (5) uses the syntax element AARE in several places, such as in SIGNAL PEER = 'peer' '=' AARE.
The definition for AARE is this:
AARE = ?*[]{}^
See below for meanings.
My question now is: where is this "below"? I suspect AARE to maybe mean "AppArmor Regular Expression" but I simply cannot find anywhere in the AA documentation any explanation for it. Googling or DuckduckGo'ing for "apparmor AARE" simpy draws blanks except for the man page where I cannot find any explanation "below". There is a section about "Globbing" but it is totally unclear to me if the AAREs (regular expressions?) are actually refering to "globbing" -- but then globbing isn't regular expressions.
So what are AARE and what is their syntax examples, as I really don't understand the meaning of ?*[]{}^.
Based on a discussion of my original question on the AppArmor mailing list the simplified answer is: yes, AARE means "AppArmor Regular Expression". However, AAREs are nearer (shell) glob expressions, but with additional AppArmor variable expansion using the #{VAR} syntax. This is not to be confused with the glob syntax of alternatives {A,B,C} which is also supported.
While there have been discussion on man page updates I don't see them yet live in production; the proposed changes should have been related to the Globbing section.
I'm a little confused concerning when to use $ compared to #.
Spring's documentation only uses #
I need to know when to use $ and # ?
Can i use # in the MVC jsp pages ?
According to this :
${...} is the property placeholder syntax. It can only be used to dereference properties.
#{...} is SpEL syntax, which is far more capable and complex. It can also handle property placeholders, and a lot more besides.
Both are valid, and neither is deprecated.
The Background
I recently posted an answer where I variously referred to #{} as a literal, an operator, and (in one draft) a "literal constructor." The squishiness of this definition didn't really affect the quality of the answer, since the question was more about what it does and how to find language references for it, but I'm unhappy with being unable to point to a canonical definition of exactly what to call this element of Ruby syntax.
The Ruby manual mentions this syntax element in the section on expression substitution, but doesn't really define the term for the syntax itself. Almost every reference to this language element says it's used for string interpolation, but doesn't define what it is.
Wikipedia Definitions
Here are some Wikipedia definitions that imply this construct is (strictly speaking) neither a literal nor an operator.
Literal (computer programming)
Operator (programming)
The Questions
Does anyone know what the proper term is for this language element? If so, can you please point me to a formal definition?
Ruby's parser calls #{} the "embexpr" operator. That's EMBedded EXPRession, naturally.
I would definitely call it neither a literal (that's more for, e.g. string literals or number literals themselves, but not parts thereof) nor an operator; those are solely for e.g. binary or unary (infix) operators.
I would either just refer to it without a noun (i.e. for string interpolation), or perhaps call those characters the string interpolation sequence or escape.
TL;DR
Originally, I'd hypothesized:
Embedded expression seems the most likely definition for this token, based on hints in the source code.
This turned out to be true, and has been officially validated by the Ruby 2.x documentation. Based on the updates to the Ripper documentation since this answer was originally written, it seems the parser token is formally defined as string_embexpr and the symbol itself is called an "embedded expression." See the Update for Ruby 2.x section at the bottom of this answer for detailed corroboration.
The remainder of the answer is still relevant, especially for older Rubies such as Ruby 1.9.3, and the methodology used to develop the original answer remains interesting. I am therefore updating the answer, but leaving the bulk of the original post as-is for historical purposes, even though the current answer could now be shorter.
Pre-2.x Answer Based on Ruby 1.9.3 Source Code
Related Answer
This answer calls attention to the Ruby source, which makes numerous references to embexpr throughout the code base. #Phlip suggests that this variable is an abbreviation for "EMBedded EXPRession." This seems like a reasonable interpretation, but neither the ruby-1.9.3-p194 source nor Google (as of this writing) explicitly references the term embedded expression in association with embexpr in any context, Ruby-related or not.
Additional Research
A scan of the Ruby 1.9.3-p194 source code with:
ack-grep -cil --type-add=YACC=.y embexpr .rvm/src/ruby-1.9.3-p194 |
sort -rnk2 -t: |
sed 's!^.*/!!'
reveals 9 files and 33 lines with the term embexpr:
test_scanner_events.rb:12
test_parser_events.rb:7
eventids2.c:5
eventids1.c:3
eventids2table.c:2
parse.y:1
parse.c:1
ripper.y:1
ripper.c:1
Of particular interest is the inclusion of string_embexpr on line 4,176 of the parse.y and ripper.y bison files. Likewise, TestRipper::ParserEvents#test_string_embexpr contains two references to parsing #{} on lines 899 and 902 of test_parser_events.rb.
The scanner, exercised in test_scanner_events.rb, is also noteworthy. This file defines tests in #test_embexpr_beg and #test_embexpr_end that scan for the token #{expr} inside various string expressions. The tests reference both embexpr and expr, raising the likelihood that "embedded expression" is indeed a sensible name for the thing.
Update for Ruby 2.x
Since this post was originally written, the documentation for the standard library's Ripper class has been updated to formally identify the token. The usage section provides "Hello, #{world}!" as an example, and says in part:
Within our :string_literal you’ll notice two #tstring_content, this is the literal part for Hello, and !. Between the two #tstring_content statements is a :string_embexpr, where embexpr is an embedded expression.
This Block post suggests, it is called an 'idiom':
http://kconrails.com/2010/12/08/ruby-string-interpolation/
The Wikipedia Article doesn't seem to contradict that:
http://en.wikipedia.org/wiki/Programming_idiom
#{} It's called placeholder and is used to reference variables with a string.
puts "My name is #{my_name}"
I was looking through some tab-completions that were automatically set up for my editor, and I found one where y was mapped to:
:yields: arguments
What is this syntax called, when, where, how and for what is this used?
This is one of the many directives supported by the RDoc documentation tool. It is used to document the arguments that get passed to a block.