Re: rename YAMF to Sling Models
I'm +1 on the move, I'm not sure if Sling Models is a good name - as a non-native speaker, the plural looks strange to me. But I don't oppose if others are fine with it Carsten 2014/1/10 Justin Edelson jus...@justinedelson.com I'd like to move YAMF from my whiteboard in to extensions and rename it as Sling Models. https://issues.apache.org/jira/browse/SLING-3313 Please speak up if you have an objection. Regards, Justin -- Carsten Ziegeler cziege...@apache.org
Re: rename YAMF to Sling Models
Thanks for pushing. I like where this goes and I am very much in favor of having this in prime time. As to the name: As a geak with a bit of a YACC background YAMF has appeal to me ;-) But I am very fine with Sling Models. Thanks Felix Am 10.01.2014 um 08:28 schrieb Justin Edelson jus...@justinedelson.com: I'd like to move YAMF from my whiteboard in to extensions and rename it as Sling Models. https://issues.apache.org/jira/browse/SLING-3313 Please speak up if you have an objection. Regards, Justin
[jira] [Commented] (SLING-3179) Implement solution to the Authentication Handler Credential Validation Problem
[ https://issues.apache.org/jira/browse/SLING-3179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868845#comment-13868845 ] Tobias Bocanegra commented on SLING-3179: - bq. I don't see how this is adding security other than reintroducing the TrustedInfo again, just with different and more complex code. yes, but on a different level. IMO the JCR resource provider must come with a LoginModule counterpart that establishes the trust. bq. complex doAs() logic, which really exposes internal JCR/repository user logic this is how JAAS works and also referred to in [Repository.login()|http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/Repository.html#login(javax.jcr.Credentials, java.lang.String)]. AFAICS, the only problem is the population of the subject and that's why I'd prefer the LoginModule approach. Implement solution to the Authentication Handler Credential Validation Problem -- Key: SLING-3179 URL: https://issues.apache.org/jira/browse/SLING-3179 Project: Sling Issue Type: Bug Components: API, JCR, ResourceResolver Affects Versions: JCR Base 2.1.2, API 2.4.2, Resource Resolver 1.0.6 Reporter: Felix Meschberger Assignee: Antonio Sanso Attachments: SLING-3179.diff, SLING-3179.patch The proposal [Solving the Authentication Handler Credential Validation Problem|https://cwiki.apache.org/confluence/display/SLING/Solving+the+Authentication+Handler+Credential+Validation+Problem] should be implemented. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3179) Implement solution to the Authentication Handler Credential Validation Problem
[
https://issues.apache.org/jira/browse/SLING-3179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868903#comment-13868903
]
Alexander Klimetschek commented on SLING-3179:
--
{quote}this is how JAAS works{quote}
Yes. It seems quite complex and IMO we shouldn't use or advertise it very much
- it seems you can easily mess it up.
IIUC, this is for the use case of external authentication where the repository
needs to trust the outside. IMO this must be a config option in Jackrabbit and
by default off. And use LoginModule or the loginByService mechanism for pre
authentication.
Implement solution to the Authentication Handler Credential Validation Problem
--
Key: SLING-3179
URL: https://issues.apache.org/jira/browse/SLING-3179
Project: Sling
Issue Type: Bug
Components: API, JCR, ResourceResolver
Affects Versions: JCR Base 2.1.2, API 2.4.2, Resource Resolver 1.0.6
Reporter: Felix Meschberger
Assignee: Antonio Sanso
Attachments: SLING-3179.diff, SLING-3179.patch
The proposal [Solving the Authentication Handler Credential Validation
Problem|https://cwiki.apache.org/confluence/display/SLING/Solving+the+Authentication+Handler+Credential+Validation+Problem]
should be implemented.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (SLING-2762) AbstractSlingRepository#login violates JCR spec
[
https://issues.apache.org/jira/browse/SLING-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868919#comment-13868919
]
Felix Meschberger commented on SLING-2762:
--
[~alexander.klimetschek] I fear Sling is not in a position to answer you
question :-)
AbstractSlingRepository#login violates JCR spec
---
Key: SLING-2762
URL: https://issues.apache.org/jira/browse/SLING-2762
Project: Sling
Issue Type: Bug
Components: JCR
Reporter: Antonio Sanso
Assignee: Antonio Sanso
AbstractSlingRepository#login seems to violate the javax.jcr.Repository spec.
The API [0] says
If credentials is null, it is assumed that authentication is handled by a
mechanism external to the repository itself (for example, through the JAAS
framework) and that the repository implementation exists within a context
(for example, an application server) that allows it to handle authorization
of the request for access to the specified workspace.
while the implementation looks like
{code}
...
if (credentials == null) {
credentials = getAnonCredentials(this.anonUser);
}
...
{code}
[0]
http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Repository.html#login%28javax.jcr.Credentials,%20java.lang.String%29
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (SLING-3308) [Javascript] Upgrading Rhino version from 1.6R2 to 1.7R4
[ https://issues.apache.org/jira/browse/SLING-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-3308: Assignee: Felix Meschberger [Javascript] Upgrading Rhino version from 1.6R2 to 1.7R4 Key: SLING-3308 URL: https://issues.apache.org/jira/browse/SLING-3308 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting JavaScript 2.0.12 Reporter: rohit Assignee: Felix Meschberger Attachments: SLING-3308.patch We have a bundle which uses Rhino 1.7 and is incompatible with version 1.6 currently exposed by org.apache.sling.scripting.javascript bundle. I tried building org.apache.sling.scripting.javascript with 1.7R4 version, but received test failures. I am currently working on it and any suggestions would be very helpful. Attaching the patch of pom.xml. Stack trace of failed test: javax.script.ScriptException: Failure running script NO_SCRIPT_NAME: null at org.apache.sling.scripting.javascript.internal.RhinoJavaScriptEngine.eval(RhinoJavaScriptEngine.java:158) at org.apache.sling.scripting.api.AbstractSlingScriptEngine.eval(AbstractSlingScriptEngine.java:44) at org.apache.sling.scripting.javascript.internal.ScriptEngineHelper.eval(ScriptEngineHelper.java:103) at org.apache.sling.scripting.javascript.internal.ScriptEngineHelper.evalToString(ScriptEngineHelper.java:83) at org.apache.sling.scripting.wrapper.ScriptableNodeTest.testForCurrentNode(ScriptableNodeTest.java:279) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:176) at junit.framework.TestCase.runBare(TestCase.java:141) at junit.framework.TestResult$1.protect(TestResult.java:122) at junit.framework.TestResult.runProtected(TestResult.java:142) at junit.framework.TestResult.run(TestResult.java:125) at junit.framework.TestCase.run(TestCase.java:129) at junit.framework.TestSuite.runTest(TestSuite.java:255) at junit.framework.TestSuite.run(TestSuite.java:250) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) Caused by: java.lang.NullPointerException at org.apache.sling.scripting.javascript.wrapper.ScriptableNode.has(ScriptableNode.java:406) at org.mozilla.javascript.ScriptableObject.getBase(ScriptableObject.java:2531) at org.mozilla.javascript.ScriptableObject.hasProperty(ScriptableObject.java:2284) at org.mozilla.javascript.ScriptRuntime.toIterator(ScriptRuntime.java:1984) at org.mozilla.javascript.ScriptRuntime.enumInit(ScriptRuntime.java:2033) at org.mozilla.javascript.gen.NO_SCRIPT_NAME_41._c_script_0(NO_SCRIPT_NAME:1) at org.mozilla.javascript.gen.NO_SCRIPT_NAME_41.call(NO_SCRIPT_NAME) at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:394) at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3091) at org.mozilla.javascript.gen.NO_SCRIPT_NAME_41.call(NO_SCRIPT_NAME) at org.mozilla.javascript.gen.NO_SCRIPT_NAME_41.exec(NO_SCRIPT_NAME) at org.mozilla.javascript.Context.evaluateReader(Context.java:1110) at org.apache.sling.scripting.javascript.internal.RhinoJavaScriptEngine.eval(RhinoJavaScriptEngine.java:115) ... 29 more -- This message was sent by
[jira] [Commented] (SLING-3308) [Javascript] Upgrading Rhino version from 1.6R2 to 1.7R4
[ https://issues.apache.org/jira/browse/SLING-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868935#comment-13868935 ] Felix Meschberger commented on SLING-3308: -- Thanks for providing the patch. It basically looks good, but it opens a box ... Checking the node field for null implies that the jsConstructor method for setting the node is never called. Looks like Rhino instantiates this class as a prototype for all the real/actual host object instances. So the real fix is to properly check for the null field all over (and proably in all the provided host objects which wrap a native Java object) [Javascript] Upgrading Rhino version from 1.6R2 to 1.7R4 Key: SLING-3308 URL: https://issues.apache.org/jira/browse/SLING-3308 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting JavaScript 2.0.12 Reporter: rohit Assignee: Felix Meschberger Attachments: SLING-3308.patch We have a bundle which uses Rhino 1.7 and is incompatible with version 1.6 currently exposed by org.apache.sling.scripting.javascript bundle. I tried building org.apache.sling.scripting.javascript with 1.7R4 version, but received test failures. I am currently working on it and any suggestions would be very helpful. Attaching the patch of pom.xml. Stack trace of failed test: javax.script.ScriptException: Failure running script NO_SCRIPT_NAME: null at org.apache.sling.scripting.javascript.internal.RhinoJavaScriptEngine.eval(RhinoJavaScriptEngine.java:158) at org.apache.sling.scripting.api.AbstractSlingScriptEngine.eval(AbstractSlingScriptEngine.java:44) at org.apache.sling.scripting.javascript.internal.ScriptEngineHelper.eval(ScriptEngineHelper.java:103) at org.apache.sling.scripting.javascript.internal.ScriptEngineHelper.evalToString(ScriptEngineHelper.java:83) at org.apache.sling.scripting.wrapper.ScriptableNodeTest.testForCurrentNode(ScriptableNodeTest.java:279) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:176) at junit.framework.TestCase.runBare(TestCase.java:141) at junit.framework.TestResult$1.protect(TestResult.java:122) at junit.framework.TestResult.runProtected(TestResult.java:142) at junit.framework.TestResult.run(TestResult.java:125) at junit.framework.TestCase.run(TestCase.java:129) at junit.framework.TestSuite.runTest(TestSuite.java:255) at junit.framework.TestSuite.run(TestSuite.java:250) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) Caused by: java.lang.NullPointerException at org.apache.sling.scripting.javascript.wrapper.ScriptableNode.has(ScriptableNode.java:406) at org.mozilla.javascript.ScriptableObject.getBase(ScriptableObject.java:2531) at org.mozilla.javascript.ScriptableObject.hasProperty(ScriptableObject.java:2284) at org.mozilla.javascript.ScriptRuntime.toIterator(ScriptRuntime.java:1984) at org.mozilla.javascript.ScriptRuntime.enumInit(ScriptRuntime.java:2033) at org.mozilla.javascript.gen.NO_SCRIPT_NAME_41._c_script_0(NO_SCRIPT_NAME:1) at org.mozilla.javascript.gen.NO_SCRIPT_NAME_41.call(NO_SCRIPT_NAME) at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:394) at
