-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: JWTAuthenticationMechanism.java #81
Comments
I think both versions work with Soteria, but the Javadoc says that the value is an Expression and not an Expression in #{...}, so the current solution is better. Github has lots of examples for both: https://github.com/search?p=2&q=isRememberMeExpression&type=Code @arjantijms, do you know which is correct? |
This is the code: Line 60 in ca6d009
|
@OndrejM it has to be an expression delimited with the The confusion comes perhaps from the earlier EE Security revision (pre 1.0) where I didn't put in the check for that syntax yet. The reasoning was indeed that if the attribute could only hold an expression, why require the syntax. But, as we implemented EL support across the spec, it became clear that it looked quite inconsistent if for one annotation that had String members already the syntax was required (to distinguish from a plain string) and for other attributes (those that are specifically for expressions) not. So at long lost we made the decision to simply require the syntax everywhere for expressions. The added benefit is that some IDE editors have an easier time recognising them as well. In the code you see this here: public static boolean evalELExpression(ELProcessor getELProcessor, String expression, boolean defaultValue) {
if (!isELExpression(expression)) {
return defaultValue;
}
return (Boolean) getELProcessor(getELProcessor).eval(toRawExpression(expression));
} If it's not an EL expression, the default value is taken, which in this case is the value of the boolean |
Hello, i test in actuall form and it doesn’t funtion. It’s ever put de cookie as rememberme value was true. When i change for the #{}, it does funtion well.
Thanks for you example. In my case this example helps my much.
Enviado desde mi iPhone
El 6/06/2018, a la(s) 6:44 a. m., Arjan Tijms <notifications@github.com> escribió:
… @OndrejM it has to be an expression delimited with the #{} or ${} syntax.
The confusion comes perhaps from the earlier EE Security revision (pre 1.0) where I didn't put in the check for that syntax yet. The reasoning was indeed that if the attribute could only hold an expression, why require the syntax.
But, as we implemented EL support across the spec, it became clear that it looked quite inconsistent if for one annotation that had String members already the syntax was required (to distinguish from a plain string) and for other attributes (those that are specifically for expressions) not.
So at long lost we made the decision to simply require the syntax everywhere for expressions. The added benefit is that some IDE editors have an easier time recognising them as well.
In the code you see this here:
public static boolean evalELExpression(ELProcessor getELProcessor, String expression, boolean defaultValue) {
if (!isELExpression(expression)) {
return defaultValue;
}
return (Boolean) getELProcessor(getELProcessor).eval(toRawExpression(expression));
}
If it's not an EL expression, the default value is taken, which in this case is the value of the boolean isRememberMe. I'll try to clarify this in the JavaDoc.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Hello again…
i forget say that for generate the cookie I change
@RememberMe(
cookieMaxAgeSeconds = REMEMBERME_VALIDITY_SECONDS,
isRememberMeExpression = "self.isRememberMe(httpMessageContext)"
)
to
@RememberMe(
cookieMaxAgeSeconds = REMEMBERME_VALIDITY_SECONDS,
cookieSecureOnly = false,
isRememberMeExpression = "#{self.isRememberMe(httpMessageContext)}"
)
This because the example don't work for http without cookieSecureOnly = false,
… El 6/06/2018, a las 6:44 a. m., Arjan Tijms ***@***.***> escribió:
@OndrejM <https://github.com/OndrejM> it has to be an expression delimited with the #{} or ${} syntax.
The confusion comes perhaps from the earlier EE Security revision (pre 1.0) where I didn't put in the check for that syntax yet. The reasoning was indeed that if the attribute could only hold an expression, why require the syntax.
But, as we implemented EL support across the spec, it became clear that it looked quite inconsistent if for one annotation that had String members already the syntax was required (to distinguish from a plain string) and for other attributes (those that are specifically for expressions) not.
So at long lost we made the decision to simply require the syntax everywhere for expressions. The added benefit is that some IDE editors have an easier time recognising them as well.
In the code you see this here:
public static boolean evalELExpression(ELProcessor getELProcessor, String expression, boolean defaultValue) {
if (!isELExpression(expression)) {
return defaultValue;
}
return (Boolean) getELProcessor(getELProcessor).eval(toRawExpression(expression));
}
If it's not an EL expression, the default value is taken, which in this case is the value of the boolean isRememberMe. I'll try to clarify this in the JavaDoc.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#81 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD9Mmdto528z41Nr_7j7XDh2W0Ze2kxKks5t58CwgaJpZM4UcAKe>.
|
Hello,
In the next line you have a error
isRememberMeExpression = "self.isRememberMe(httpMessageContext)"
change to
isRememberMeExpression = "#{self.isRememberMe(httpMessageContext)}")
The text was updated successfully, but these errors were encountered: