[jira] [Commented] (SLING-3457) Change ResourceUtil.isNonExistingResource(null) to return true instead of NPE.
[ https://issues.apache.org/jira/browse/SLING-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937622#comment-13937622 ] Carsten Ziegeler commented on SLING-3457: - I'm not sure if we should do this. If the method returns true I would expext that the resource is a NonExistingResource and therefore then call any method on the resource object which then results in an NPE. Even the same if the method would return false, so I think a NPE is the best option here. at some point the client code has to check whether the resource is null or not Change ResourceUtil.isNonExistingResource(null) to return true instead of NPE. -- Key: SLING-3457 URL: https://issues.apache.org/jira/browse/SLING-3457 Project: Sling Issue Type: Improvement Affects Versions: API 2.6.0 Reporter: Florentin Wandeler Priority: Minor currently, as specified in its javadocs, ResourceUtil.isNonExistingResource(null) throws a NullPointerException. - Changing this to return true for res == null might be more api user-friendly. -- This message was sent by Atlassian JIRA (v6.2#6252)
RE: [RT] Make ResourceAccessSecurity always restrict access if installed and no ResourceAccessGate present
Furthermore the implementation of the ResourceAccessSecurity for the provider context does not behave like the one for the application context: If we for example check the read access for a resource the implementation calls all ResourceAccessGates till a gate is found which grants read access. That's correct but only done in the provider context. In the application context the implementation also calls all ResourceAccessGates till a gate is found which grants read access. But if no gate is found which grants read access and there's also no gate which denies access (returns GateResult.DONTCARE), access will be granted. This seems wrong in terms of security. The two implementations for provider context and application context should behave the same. With the only difference that ResourceResolver will ignore the application context if the service could not be found. I thought the difference in defaults between application scoped access security and provider scoped is intended. Provider scoped access security is requested by the resource provider itself using USE_RESOURCE_ACCESS_SECURITY, so it makes sense to deny access if no gate is present because the provider really cares about security. However, the application scoped access security is requested by the one that installs a gate, so it should only restrict access if the gate is present, as the provider does not really care about security. Or, am I understanding it wrong? Marius
Re: [RT] Support for deep reads from a value map
OK. Thanks for explaining. Just wanted to make sure I wasn't missing something.
Justin
On Sun, Mar 16, 2014 at 5:46 AM, Carsten Ziegeler cziege...@apache.org wrote:
Hi Justin
it's right we can get the same result without adding this method, however
with adding this method we really make clear that there is a contract
change.
We don't need a refactoring of the Resource api, just an extension - which
imho we should have done from the beginning.
Carsten
2014-03-15 14:37 GMT+01:00 Justin Edelson jus...@justinedelson.com:
Hi Carsten,
I don't understand the coupling between the addition of
Resource.getValueMap() and having the Mongo, Merged, and JMX
ResourceProviders start using DeepReadValueMapDecorator.
IIOW, couldn't we get the same effect *without* changing the Resource
API? That has an impact on downstream users and I'd suggest putting it
in the category of things to address the next time we do a
refactoring of the Resource API.
Regards,
Justin
On Sat, Mar 15, 2014 at 8:57 AM, Carsten Ziegeler cziege...@apache.org
wrote:
Exactly, if you have a look at the implementation or read my description,
you see that the jcr implementation did not change at all. So, for all
jcr
backed resources nothing has changed and the deep read is done there.
Implementations are free to implement the deep read themselves or can use
the provided support.
Although, as mentioned in the beginning, the jcr implementation is wrong
as
it does not use the resource tree, so a
getValueMap().get(content/title)
might return something different than a
getChild(content).getValueMap().get(title). But this has always been
the case, and as the jcr implementation is very complicated with all the
encoding stuff it contains, I think we shouldn't touch this.
Carsten
2014-03-14 20:28 GMT+01:00 Alexander Klimetschek aklim...@adobe.com:
IIUC, a deep read is now done generically by fetching sub resources
first
and each value map will from now on only read their local values.
I think this introduces overhead for a lot of common operations. For
every
descendant node you now have to read and instantiate a resource and
value
map. So far with the JCR property map this was left to the JCR repo.
IMO we should not change much here and simply support deep reads
whereever
possible in the resource implemention (and the missing part here is in
the
/mnt/overlay resource merger AFAIU).
Cheers,
Alex
On 14.03.2014, at 08:45, Carsten Ziegeler cziege...@apache.org wrote:
I just found out that we have to change our idea a little bit, we
can't
demand that Resource#adaptTo(ValueMap.class) always returns a value
map.
The nice exception is the JcrPropertyResource...
Regards
Carsten
2014-03-14 15:08 GMT+01:00 Carsten Ziegeler cziege...@apache.org:
Hi Felix,
yes, the changes I just committed in fact deprecate
ResourceUtil.getValueMap() and let that method call
resource.getValueMap()
(if resource is not null of course).
The utility code is an implementation of the value map which supports
the
deep read methods. See the new DeepReadValueMapDecorator class.
Existing implementations which currently return a value map simply
need
to
wrap their value map with this new decorator. Of course they are
free to
implement the deep reads by themselves.
I wanted to change the jcr resource provider, but that would
introduce
incompatibilities to a lot of wired path encoding stuff in the
implementation. So it's safer to leave it as is.
Carsten
2014-03-14 14:58 GMT+01:00 Felix Meschberger fmesc...@adobe.com:
Hi
Am 14.03.2014 um 11:42 schrieb Carsten Ziegeler
cziege...@apache.org
:
The only other option I see is to make ValueMap a first class
citizen
and:
I think this makes sense independently of deep reads or not -- and
maybe
we should have done this right when we introduced the ValueMap...
a) add a getValueMap() method to Resource - default implementation
in
AbstractResource does the same as ResourceUtil does today
In essence ?
ValueMap AbstractResource.getValueMap() {
return ResourceUtil.getValueMap(this);
}
or rather copy the ResourceUtil.getValueMap(Resource) method to
AbstractResource.getValueMap(), implement the deep-read logic there
and do
ValueMap ResourceUtil.getValueMap(Resource r) {
return r.getValueMap();
}
while at the same time deprecating
ResourceUtil.getValueMap(Resource) ?
b) clearly state that deep gets are allowed for reading from those
maps
That would go to the JavaDoc of Resource.getValueMap() along with
the
requirement to never return null.
c) provide utility code in AbstractResource (or maybe somewhere
else)
so
implementations do not need to copy the same code over and over
again
What kind of utility code ?
What would
[jira] [Commented] (SLING-3447) Add more Source and CI links to sidebar
[ https://issues.apache.org/jira/browse/SLING-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937746#comment-13937746 ] Bertrand Delacretaz commented on SLING-3447: Note that you can also submit patches for any changes to http://sling.apache.org The content is under http://svn.apache.org/repos/asf/sling/site/trunk/ and https://www.apache.org/dev/cmsref.html#non-committer explains how to contribute content. Add more Source and CI links to sidebar --- Key: SLING-3447 URL: https://issues.apache.org/jira/browse/SLING-3447 Project: Sling Issue Type: Improvement Components: Documentation Reporter: Ravi Teja Assignee: Justin Edelson Labels: documentation Attachments: sidenav.diff I'm expecting something on the lines of # http://grails.org/doc/latest/guide/introduction.html # http://docs.spring.io/spring/docs/current/spring-framework-reference/html/ I will also help you build the documentation as I'm learning about Sling. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3435) ResourceAccessSecurity does not secure access for update operations
[ https://issues.apache.org/jira/browse/SLING-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937749#comment-13937749 ] Marius Petria commented on SLING-3435: -- Hi Mike, I tried to run the tests but they do not work. There are a couple of issues with them that were probably introduced when you cleaned the dependencies for jcr implementation. - There should be a session.save(); in org.apache.sling.resourceaccesssecurity.it.impl.Init class. - We should have configuration files for linking gates to providers (setting the path) Also, because I made the initial patch with git, it seems that the history for resourceaccesssecurity was not moved to the new location. ResourceAccessSecurity does not secure access for update operations --- Key: SLING-3435 URL: https://issues.apache.org/jira/browse/SLING-3435 Project: Sling Issue Type: New Feature Components: ResourceResolver Reporter: Marius Petria Assignee: Mike Müller Attachments: SLING-3435.1.patch, SLING-3435.2.patch, SLING-3435.patch ResourceAccessSecurity should use gates registered for update operations in order to secure access to modifiable value maps. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] Release Apache Sling Models Implementation 1.0.2
On Sat, Mar 15, 2014 at 3:57 PM, Justin Edelson jus...@justinedelson.com wrote: Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1035/... +1 for the release, checked signatures, build, svn tag match on the following archive: MD5 org.apache.sling.models.impl-1.0.2-source-release.zip = 2c5a2fddbeafe3a90265a9554cf8ed33 Kudos for the extensive test coverage! -Bertrand
SlingRepository Integration Tests fails on new system
The SlingRepository Integration Tests (in sling/bundles/jcr/it-jackrabbit-ok/) fails on a new system. I'm not sure but I think the reason might be that JackrabbitRepositoryIT OakRepositoryIT contains the line mavenBundle(org.apache.sling, org.apache.sling.jcr.base, 2.2.1-SNAPSHOT), and the current version in the trunk is 2.2.3-SNAPSHOT. /Pontus
Re: [RT] Make ResourceAccessSecurity always restrict access if installed and no ResourceAccessGate present
Yes, I think my first answer was wrong (Note to myself, don't answer mails after long distance travels...) and you're right. The difference between provider and application type is exactly that. If there is no provider RAS and the provider does not declare to require one, the resource is visible. Same with application type, but also if application RAS is there but doesn't restrcit it. Carsten 2014-03-17 3:09 GMT-07:00 Marius Petria mpet...@adobe.com: Furthermore the implementation of the ResourceAccessSecurity for the provider context does not behave like the one for the application context: If we for example check the read access for a resource the implementation calls all ResourceAccessGates till a gate is found which grants read access. That's correct but only done in the provider context. In the application context the implementation also calls all ResourceAccessGates till a gate is found which grants read access. But if no gate is found which grants read access and there's also no gate which denies access (returns GateResult.DONTCARE), access will be granted. This seems wrong in terms of security. The two implementations for provider context and application context should behave the same. With the only difference that ResourceResolver will ignore the application context if the service could not be found. I thought the difference in defaults between application scoped access security and provider scoped is intended. Provider scoped access security is requested by the resource provider itself using USE_RESOURCE_ACCESS_SECURITY, so it makes sense to deny access if no gate is present because the provider really cares about security. However, the application scoped access security is requested by the one that installs a gate, so it should only restrict access if the gate is present, as the provider does not really care about security. Or, am I understanding it wrong? Marius -- Carsten Ziegeler cziege...@apache.org
[VOTE RESULT] Release Apache Sling JCR Resource 2.3.4
The vote passes with three binding +1 votes from Justin Edelson, Felix Meschberger, and Carsten Ziegeler and one non binding +1 vote from Oliver Lietz Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] [Closed] (SLING-3445) Removing multi value property fails
[ https://issues.apache.org/jira/browse/SLING-3445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-3445. --- Removing multi value property fails --- Key: SLING-3445 URL: https://issues.apache.org/jira/browse/SLING-3445 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.3.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Resource 2.3.4 If a jcr resource is adapted to a ModifiableValueMap and remove(propName) is called on a multi value property, the removal fails as the setProperty(name, (String)null) is used - which is not a multi value property. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] Release Apache Sling Models Implementation 1.0.2
+1 2014-03-17 6:48 GMT-07:00 Bertrand Delacretaz bdelacre...@apache.org: On Sat, Mar 15, 2014 at 3:57 PM, Justin Edelson jus...@justinedelson.com wrote: Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1035/. .. +1 for the release, checked signatures, build, svn tag match on the following archive: MD5 org.apache.sling.models.impl-1.0.2-source-release.zip = 2c5a2fddbeafe3a90265a9554cf8ed33 Kudos for the extensive test coverage! -Bertrand -- Carsten Ziegeler cziege...@apache.org
Re: SlingRepository Integration Tests fails on new system
Hi, On Mon, Mar 17, 2014 at 3:22 PM, Pontus Amberg pontus.amb...@gmail.com wrote: ...I think the reason might be that JackrabbitRepositoryIT OakRepositoryIT contains the line mavenBundle(org.apache.sling, org.apache.sling.jcr.base, 2.2.1-SNAPSHOT),... Thanks for reporting this, should be fixed by http://svn.apache.org/r1578404 - can you try again? -Bertrand
Re: SlingRepository Integration Tests fails on new system
That seems to have solved to problem in the SlingRepository Integration Tests but there seems to be a similar problem in Scripting Core implementation (sling/bundles/scripting/core/) where BindingValuesProvidersByContextIT contains the line mavenBundle(org.apache.sling, org.apache.sling.scripting.api, 2.1.5-SNAPSHOT), and the trunk contains the version 2.1.7-SNAPSHOT /Pontus On 17 March 2014 15:46, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, On Mon, Mar 17, 2014 at 3:22 PM, Pontus Amberg pontus.amb...@gmail.com wrote: ...I think the reason might be that JackrabbitRepositoryIT OakRepositoryIT contains the line mavenBundle(org.apache.sling, org.apache.sling.jcr.base, 2.2.1-SNAPSHOT),... Thanks for reporting this, should be fixed by http://svn.apache.org/r1578404 - can you try again? -Bertrand
[jira] [Resolved] (SLING-3352) Expose OSGI configuration via HTTP
[ https://issues.apache.org/jira/browse/SLING-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-3352. Resolution: Fixed Assignee: Tommaso Teofili (was: Carsten Ziegeler) I've applied Marius's patch at r1578436, thanks Marius for your contribution(s) Expose OSGI configuration via HTTP -- Key: SLING-3352 URL: https://issues.apache.org/jira/browse/SLING-3352 Project: Sling Issue Type: Improvement Reporter: Marius Petria Assignee: Tommaso Teofili Labels: replication Attachments: SLING-3352.1.patch, SLING-3352.2.patch, SLING-3352.3.patch, SLING-3352.4.patch, SLING-3352.patch We need a safe way to expose OSGI configuration via HTTP. Requirements: - all configs for a certain factory should be manageable - they should have associated JCR nodes that contain the config properties - only configs that are available through ConfigurationAdmin should be available - the HTTP urls should have friendly names - (Optional) the implementation should be general enough to be used for other configs other than replication if needed For example: a configuration with name publish for org.apache.sling.replication.agent.impl.ReplicationAgentServiceFactory should be mapped to /etc/replication/agent/publish Problems with current implementation of JCR nodes created by JCR installed: - Configuration files are read and created from /apps/.../config or /libs/.../config, and there is no easy way to determine which are active in the ConfigurationAdmin - There is no way to restrict a repository path to create only configuration from a specified factory (making it unusable with relaxed ACLs) - The url of a configuration is unfriendly (it contains the fully qualified name of the factory) - The node types are not homogenous making it hard to use in a client application (some are nt:file, some are sling:OsgiConfig) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3435) ResourceAccessSecurity does not secure access for update operations
[ https://issues.apache.org/jira/browse/SLING-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937936#comment-13937936 ] Mike Müller commented on SLING-3435: Hi Marius I just checked the code out again (fresh copy) and had no problems to run the integration tests (after building the whole sling). But you're right, that the session.save() is missing, which I included now (r The tests completed anyway because the ResouceAccessGates for the tests do not distinguish between logged in user or not by now. Can you try to test it on your side with a fresh copy? Why do you whink we should link the gates with the providers (pathwise)? In the setup now, we just can combine anythink for the tests. I also like to have also some weird combinations in the tests even if nobody should configure his application like this, but to get a good test base (because it's a security feature). ResourceAccessSecurity does not secure access for update operations --- Key: SLING-3435 URL: https://issues.apache.org/jira/browse/SLING-3435 Project: Sling Issue Type: New Feature Components: ResourceResolver Reporter: Marius Petria Assignee: Mike Müller Attachments: SLING-3435.1.patch, SLING-3435.2.patch, SLING-3435.patch ResourceAccessSecurity should use gates registered for update operations in order to secure access to modifiable value maps. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (SLING-3435) ResourceAccessSecurity does not secure access for update operations
[ https://issues.apache.org/jira/browse/SLING-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937936#comment-13937936 ] Mike Müller edited comment on SLING-3435 at 3/17/14 4:03 PM: - Hi Marius I just checked the code out again (fresh copy) and had no problems to run the integration tests (after building the whole sling). But you're right, that the session.save() is missing, which I included now (r1578443) The tests completed anyway because the ResouceAccessGates for the tests do not distinguish between logged in user or not by now. Can you try to test it on your side with a fresh copy? Why do you whink we should link the gates with the providers (pathwise)? In the setup now, we just can combine anythink for the tests. I also like to have also some weird combinations in the tests even if nobody should configure his application like this, but to get a good test base (because it's a security feature). was (Author: mykee): Hi Marius I just checked the code out again (fresh copy) and had no problems to run the integration tests (after building the whole sling). But you're right, that the session.save() is missing, which I included now (r The tests completed anyway because the ResouceAccessGates for the tests do not distinguish between logged in user or not by now. Can you try to test it on your side with a fresh copy? Why do you whink we should link the gates with the providers (pathwise)? In the setup now, we just can combine anythink for the tests. I also like to have also some weird combinations in the tests even if nobody should configure his application like this, but to get a good test base (because it's a security feature). ResourceAccessSecurity does not secure access for update operations --- Key: SLING-3435 URL: https://issues.apache.org/jira/browse/SLING-3435 Project: Sling Issue Type: New Feature Components: ResourceResolver Reporter: Marius Petria Assignee: Mike Müller Attachments: SLING-3435.1.patch, SLING-3435.2.patch, SLING-3435.patch ResourceAccessSecurity should use gates registered for update operations in order to secure access to modifiable value maps. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3435) ResourceAccessSecurity does not secure access for update operations
[ https://issues.apache.org/jira/browse/SLING-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937959#comment-13937959 ] Marius Petria commented on SLING-3435: -- Hi, It must have been something wrong in my local repo. The tests work fine with a full clean build. Regarding the connection between gates and providers, this works because no path is treated as (.*) so the gates are registered for the whole resource space. It would be nice to also test access to providers for which no gate is matched (that was the intent of /providers/unsecured/...). So, maybe we should just define inline the gates to match /providers/secured(.*) ResourceAccessSecurity does not secure access for update operations --- Key: SLING-3435 URL: https://issues.apache.org/jira/browse/SLING-3435 Project: Sling Issue Type: New Feature Components: ResourceResolver Reporter: Marius Petria Assignee: Mike Müller Attachments: SLING-3435.1.patch, SLING-3435.2.patch, SLING-3435.patch ResourceAccessSecurity should use gates registered for update operations in order to secure access to modifiable value maps. -- This message was sent by Atlassian JIRA (v6.2#6252)
RE: [RT] Make ResourceAccessSecurity always restrict access if installed and no ResourceAccessGate present
I think the actual problem might be in the implementation of ProviderHandler. getReadableResource. The applicationsecurityservice should apply its restrictions to the already secured resource (returnValue) rather than on the initial resource. That way any constraint imposed by the providersecurityservice will be taken into account. Marius [1] https://github.com/apache/sling/blob/838ec33748f6cb5eb21d9dd0d8106adecc001f97/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/tree/ProviderHandler.java#L176 -Original Message- From: Mike Müller [mailto:mike...@mysign.ch] Sent: Monday, March 17, 2014 5:38 PM To: dev@sling.apache.org Subject: RE: [RT] Make ResourceAccessSecurity always restrict access if installed and no ResourceAccessGate present Hi I think this is insecure by design and not correct: The problem is not, that we do grant access if no ResourceAccessGate is registered for application context. The problem is, that we grant access also if there is a ResourceAccessGate registered for application level but does return GateResult.DONTCARE. In this case no access should be granted as we do on provider context. To see that actual wrong implementation in action have a look at the integration Test in SecuredProviderResourceAccessSecurityTest#testUpdateDeniedUpdateAllow edRead: Here only READ is granted but not UPDATE. But because there are also registered ResourceAccessGates for application levels the access would be granted for update anyway if no application ResourceAccessGate denies updates (per default they only return GateResult.DONTCARE). There's no disadvantage if we do not grant access if no ResourceAccessGate returns GateResult.GRANT. Because in the case if no ResourceAccessGate is defined we do not have a registered ResourceAccessSecurity service for the application level. So IMHO we definitively have to change this behavour to act similar as in the provider context. Best regards mike -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Monday, March 17, 2014 3:35 PM To: dev@sling.apache.org Subject: Re: [RT] Make ResourceAccessSecurity always restrict access if installed and no ResourceAccessGate present Yes, I think my first answer was wrong (Note to myself, don't answer mails after long distance travels...) and you're right. The difference between provider and application type is exactly that. If there is no provider RAS and the provider does not declare to require one, the resource is visible. Same with application type, but also if application RAS is there but doesn't restrcit it. Carsten 2014-03-17 3:09 GMT-07:00 Marius Petria mpet...@adobe.com: Furthermore the implementation of the ResourceAccessSecurity for the provider context does not behave like the one for the application context: If we for example check the read access for a resource the implementation calls all ResourceAccessGates till a gate is found which grants read access. That's correct but only done in the provider context. In the application context the implementation also calls all ResourceAccessGates till a gate is found which grants read access. But if no gate is found which grants read access and there's also no gate which denies access (returns GateResult.DONTCARE), access will be granted. This seems wrong in terms of security. The two implementations for provider context and application context should behave the same. With the only difference that ResourceResolver will ignore the application context if the service could not be found. I thought the difference in defaults between application scoped access security and provider scoped is intended. Provider scoped access security is requested by the resource provider itself using USE_RESOURCE_ACCESS_SECURITY, so it makes sense to deny access if no gate is present because the provider really cares about security. However, the application scoped access security is requested by the one that installs a gate, so it should only restrict access if the gate is present, as the provider does not really care about security. Or, am I understanding it wrong? Marius -- Carsten Ziegeler cziege...@apache.org
Performance and stability of Sling Models
Hi, I am a little bit worried that model classes which leverage the Sling Models annotations might be slow and break fast. If you use the annotation @Inject without @Source all injectors are asked until one returns a value. Since almost all injectors depend on the fieldname and cover the same namespace, models can break very easily. Let me give three examples for broken models: a) If I use in my model @Inject String myattribute; which used to be resolved by the ValueMap injector and I just introduced a new Scripting variable with the name “myattribute” (https://cwiki.apache.org/confluence/display/SLING/Adding+New+Scripting+Variables), my model would no longer work. b) The same would apply, if I have a Sling resource with a value named “service” which used to be (by coincidence) also the field name of my injected OSGi service in the model. c) The same for a new request attribute, whose name conflicts with the field name of my injected OSGi service in the model Regarding the performance, I fear that the lookup in the value map from the second injector might take some time (since JCR access is necessary in most cases to do that). For example if I have a model class only relying on OSGi services a lot of time would be wasted by asking other injectors. To summarize: Isn’t it always advisable to use the @Source annotation to prevent those kind of name clashes and performance issues? Shouldn’t that be explicitly stated in the documentation? What is your opinion on that? What about making the @Source mandatory for all injectors but the ValueMap injector? Thanks, Konrad
Re: SlingRepository Integration Tests fails on new system
The build works fine now. Thanks for the quick fixes! /Pontus On 17 March 2014 16:36, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, On Mon, Mar 17, 2014 at 3:56 PM, Pontus Amberg pontus.amb...@gmail.com wrote: ...there seems to be a similar problem in Scripting Core implementation... That one should be fixed by revision 1578442 -Bertrand
Resource rendered by .esp script is only rendered on first request
I'm not sure but I think I might have encountered a problem in the current trunk with resources rendered by .esp scripts. Steps to reproduce: 1. Create a new file called test.esp with this content: html body %=Current node path: +currentNode.path%br/ /body /html 2. Copy the file to your repository at /apps/sling/servlet/default 3. Perform a request where the new script shall render the content http://localhost:8080/sling/.test The resource shall now have been rendered correctly by the ESP script 4. Reload the content of the browser, this and any further request will just generate an IOException Any request after the first does (at least on my setup) result in an IOException. I can see in the sling-home/logs/error.log that the IOException is preceded by an RepositoryException. I have attached the entries from the error log and also saved it on pastebin [1] Is this a problem in the current trunk or is it just on my setup? I will create an issue in Jira if someone just confirms that this actually is a problem in the current trunk. /Pontus [1] http://pastebin.com/T19MNJnr 17.03.2014 20:45:53.932 *ERROR* [192.168.1.1 [1395085553930] GET /.test HTTP/1.1] org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource getInputStream: Cannot get InputStream for JcrNodeResource, type=nt:file, superType=null, path=/apps/sling/servlet/default/test.esp javax.jcr.RepositoryException: This session has been closed. See the chained exception for a trace of where the session was closed. at org.apache.jackrabbit.core.session.SessionState.checkAlive(SessionState.java:150) at org.apache.jackrabbit.core.ItemImpl.sanityCheck(ItemImpl.java:101) at org.apache.jackrabbit.core.NodeImpl.isNodeType(NodeImpl.java:927) at org.apache.jackrabbit.core.NodeImpl.isNodeType(NodeImpl.java:2272) at org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource.getInputStream(JcrNodeResource.java:198) at org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource.adaptTo(JcrNodeResource.java:127) at org.apache.sling.scripting.core.impl.DefaultSlingScript$LazyInputStream.getStream(DefaultSlingScript.java:810) at org.apache.sling.scripting.core.impl.DefaultSlingScript$LazyInputStream.read(DefaultSlingScript.java:775) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) at java.io.InputStreamReader.read(InputStreamReader.java:184) at java.io.BufferedReader.fill(BufferedReader.java:154) at java.io.BufferedReader.read(BufferedReader.java:175) at java.io.FilterReader.read(FilterReader.java:65) at java.io.PushbackReader.read(PushbackReader.java:90) at org.apache.sling.scripting.javascript.io.EspReader.doRead(EspReader.java:399) at org.apache.sling.scripting.javascript.io.EspReader.read(EspReader.java:296) at org.mozilla.javascript.TokenStream.fillSourceBuffer(TokenStream.java:1351) at org.mozilla.javascript.TokenStream.getChar(TokenStream.java:1238) at org.mozilla.javascript.TokenStream.getToken(TokenStream.java:304) at org.mozilla.javascript.Parser.peekToken(Parser.java:166) at org.mozilla.javascript.Parser.parse(Parser.java:360) at org.mozilla.javascript.Parser.parse(Parser.java:336) at org.mozilla.javascript.Context.compileImpl(Context.java:2322) at org.mozilla.javascript.Context.compileReader(Context.java:1310) at org.mozilla.javascript.Context.compileReader(Context.java:1282) at org.mozilla.javascript.Context.evaluateReader(Context.java:1224) at org.apache.sling.scripting.javascript.internal.RhinoJavaScriptEngine.eval(RhinoJavaScriptEngine.java:114) at org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:361) at org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(DefaultSlingScript.java:171) at org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:463) at org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:511) at org.apache.sling.engine.impl.SlingRequestProcessorImpl.processComponent(SlingRequestProcessorImpl.java:289) at org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:49) at org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:64) at org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:64) at org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60) at
Re: [RT] Make ResourceAccessSecurity always restrict access if installed and no ResourceAccessGate present
Hi 2014-03-17 8:38 GMT-07:00 Mike Müller mike...@mysign.ch: Hi I think this is insecure by design and not correct: The problem is not, that we do grant access if no ResourceAccessGate is registered for application context. The problem is, that we grant access also if there is a ResourceAccessGate registered for application level but does return GateResult.DONTCARE. In this case no access should be granted as we do on provider context. To see that actual wrong implementation in action have a look at the integration Test in SecuredProviderResourceAccessSecurityTest#testUpdateDeniedUpdateAllowedRead: Here only READ is granted but not UPDATE. But because there are also registered ResourceAccessGates for application levels the access would be granted for update anyway if no application ResourceAccessGate denies updates (per default they only return GateResult.DONTCARE). There's no disadvantage if we do not grant access if no ResourceAccessGate returns GateResult.GRANT. Because in the case if no ResourceAccessGate is defined we do not have a registered ResourceAccessSecurity service for the application level. So IMHO we definitively have to change this behavour to act similar as in the provider context. ah, thanks, got it now. I think either way is a little bit strange. I guess we all agree that if there is no application RAG, the resource is accessible (leaving out the provider RAG for now). Then you add an application RAG which say DONTCARE and out of the sudden, the resource is not visible anymore. This seems a little bit contradicting the term DONTCARE. I think DONTCARE means you get the same result as if this check wasn't done and in the case of the application RAG that's acess is granted. Regards Carsten Best regards mike -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Monday, March 17, 2014 3:35 PM To: dev@sling.apache.org Subject: Re: [RT] Make ResourceAccessSecurity always restrict access if installed and no ResourceAccessGate present Yes, I think my first answer was wrong (Note to myself, don't answer mails after long distance travels...) and you're right. The difference between provider and application type is exactly that. If there is no provider RAS and the provider does not declare to require one, the resource is visible. Same with application type, but also if application RAS is there but doesn't restrcit it. Carsten 2014-03-17 3:09 GMT-07:00 Marius Petria mpet...@adobe.com: Furthermore the implementation of the ResourceAccessSecurity for the provider context does not behave like the one for the application context: If we for example check the read access for a resource the implementation calls all ResourceAccessGates till a gate is found which grants read access. That's correct but only done in the provider context. In the application context the implementation also calls all ResourceAccessGates till a gate is found which grants read access. But if no gate is found which grants read access and there's also no gate which denies access (returns GateResult.DONTCARE), access will be granted. This seems wrong in terms of security. The two implementations for provider context and application context should behave the same. With the only difference that ResourceResolver will ignore the application context if the service could not be found. I thought the difference in defaults between application scoped access security and provider scoped is intended. Provider scoped access security is requested by the resource provider itself using USE_RESOURCE_ACCESS_SECURITY, so it makes sense to deny access if no gate is present because the provider really cares about security. However, the application scoped access security is requested by the one that installs a gate, so it should only restrict access if the gate is present, as the provider does not really care about security. Or, am I understanding it wrong? Marius -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
