Re: [sling:resourceType] protected execution
> > 1. Users can freely define sling:resourceType properties Is there some reason why this must be so? In JCR land, the jcr:nodeTypeManagement privilege must be granted for the user to have permission to add and remove mixin node types and change the primary node type of a node. I would expect that a similar elevated privilege could protect against unwanted modifications of the sling:resourceType values by the wrong users. For #2 and #3, perhaps what you are really describing is a mechanism for defining and checking what I would call "functional privileges"? In other words, not the same as permissions on the data, but permissions on the action. Would it be necessary to associate those "functional privileges" to a resource type? I can imagine you may want to define a "functional privilege" that could be checked by some servlet/filter/component/osgi_service/model/other that works for many different resource types or no specific resource type at all. For example, 1. Imagine a resource defined at "/etc/functional_privileges/yourapp/usage_report" whose "jcr:read" permissions determines if the user can perform the "usage_report" servlet action. 2. Then the "usage_report" servlet simply has to has to check if the "yourapp/usage_report" resource at #1 exists for the current user (or some higher level API that does the same) to know if the servlet should proceed or return an error code. 3. For scripts, perhaps a sling:functionalPrivilege property on the resource could define what is required and block the script processing generically when those conditions are not satisfied. That's my 2 cents.. Regards, -Eric On Fri, Oct 5, 2018 at 2:40 AM Radu Cotescu wrote: > Hi, > > Since this thread exploded so quickly it’s going to be difficult to > respond to all of your questions / concerns individually. We eagerly > started discussing implementation details (of which I’m to blame too) and I > think we didn’t read between the lines of this thread or the previous [0] > to check what the perceived problems are. > > Both threads identified several issues: > 1. Users can freely define sling:resourceType properties > 2. Through 1, users can therefore trigger code execution which is not > always appropriate (depends on how Servlets / scripts are written and the > potential they have to DoS a system or to expose sensible information to > users which shouldn’t have the ability to perform those operations) > 3. For some operations (servlet execution, tasks, etc.) we might want to > provide a set of permissions to check beforehand in order to decide if a > user is allowed to perform said operation or not. > > In this thread I proposed an idea to fix issue no. 2 (which IMO is easier > to accomplish) - and by fix I mean provide a way to define who can execute > what - so that we don’t care about issue no. 1 any more. > > Let’s try to figure out if indeed these are some serious problems that > need to be addressed or not. We can discuss implementation details > afterwards. > > Cheers, > Radu > > >
Re: [sling:resourceType] protected execution
Hi Bertrand, > On 5 Oct 2018, at 16:18, Bertrand Delacretaz wrote: > > Hi, > > On Fri, Oct 5, 2018 at 2:47 PM Jason E Bailey wrote: >> ...1. Each resource provider, if it supports security, should be responsible >> for security... > > I think there are misunderstandings in this thread about what we're > trying to achieve. > > Radu, correct me if I'm wrong but I think the only aspect of your > proposal that we need to agree upon right now is to create a service > that provides an API like > > /** Throw a PermissionDeniedException if any of the requested > permissions is not granted > * in the context of the supplied ResourceResolver which points to > a specific user */ > void checkAllPermissions( > ResourceResolver context, > String ...requestedPermission) >throws PermissionDeniedException; > > The goal being to define permissions for things which are not content > - like letting a specific user execute any code that's tied to a > particular resource type, without having to implement checks in all > the affected code and scripts. > > How these permissions are configured and evaluated is an > implementation detail that we can discuss separately. > > I think Radu is proposing to keep this API internal to the servlets > resolver as we don't see a need for it outside of that for now. Yes, an internal API for now would be more than enough, since we have only one use-case. I’ve already started hacking on something [1] - it’s by no means neither ready, nor complete, but for now it seems to work and it’s only meant to show the idea. We could obviously transform my hack into something more generic, but if we’re only talking about this one use-case it might not be needed. > > Can we agree on this? If yes the remaining aspects can be addressed > separately in more specific discussions. > > -Bertrand Cheers, Radu [1] - https://github.com/apache/sling-org-apache-sling-engine/compare/resource-type-execution?expand=1
Re: [sling:resourceType] protected execution
Hi, On Fri, Oct 5, 2018 at 2:47 PM Jason E Bailey wrote: > ...1. Each resource provider, if it supports security, should be responsible > for security... I think there are misunderstandings in this thread about what we're trying to achieve. Radu, correct me if I'm wrong but I think the only aspect of your proposal that we need to agree upon right now is to create a service that provides an API like /** Throw a PermissionDeniedException if any of the requested permissions is not granted * in the context of the supplied ResourceResolver which points to a specific user */ void checkAllPermissions( ResourceResolver context, String ...requestedPermission) throws PermissionDeniedException; The goal being to define permissions for things which are not content - like letting a specific user execute any code that's tied to a particular resource type, without having to implement checks in all the affected code and scripts. How these permissions are configured and evaluated is an implementation detail that we can discuss separately. I think Radu is proposing to keep this API internal to the servlets resolver as we don't see a need for it outside of that for now. Can we agree on this? If yes the remaining aspects can be addressed separately in more specific discussions. -Bertrand
[jira] [Commented] (SLING-7970) Add Feature Model introspection service
[ https://issues.apache.org/jira/browse/SLING-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639820#comment-16639820 ] ASF GitHub Bot commented on SLING-7970: --- bosschaert commented on issue #3: SLING-7970 Add Feature Model introspection service URL: https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/3#issuecomment-427362517 Hi @cziegeler and @karlpauls would you have time to take a quick look at these changes? I'll work on unit tests in the mean time... This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Feature Model introspection service > --- > > Key: SLING-7970 > URL: https://issues.apache.org/jira/browse/SLING-7970 > Project: Sling > Issue Type: New Feature > Components: Feature Model >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > > We need a service that can report on the feature model that is launched by > the launcher, for introspection purposes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] bosschaert commented on issue #3: SLING-7970 Add Feature Model introspection service
bosschaert commented on issue #3: SLING-7970 Add Feature Model introspection service URL: https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/3#issuecomment-427362517 Hi @cziegeler and @karlpauls would you have time to take a quick look at these changes? I'll work on unit tests in the mean time... This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SLING-7970) Add Feature Model introspection service
[ https://issues.apache.org/jira/browse/SLING-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639818#comment-16639818 ] ASF GitHub Bot commented on SLING-7970: --- bosschaert opened a new pull request #3: SLING-7970 Add Feature Model introspection service URL: https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/3 Get the launcher to install a Felix Inventory Printer service that prints the effective feature. This can be used to report on the selected feature. Additionally register a service that can find the Bundle Artifact ID from a given Bundle Symbolic Name and Version. This can be used to find a bundle in a feature description. The interface for this service can be found here https://github.com/apache/sling-whiteboard/blob/master/featuremodel/feature-service/src/main/java/org/apache/sling/feature/service/Bundles.java This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Feature Model introspection service > --- > > Key: SLING-7970 > URL: https://issues.apache.org/jira/browse/SLING-7970 > Project: Sling > Issue Type: New Feature > Components: Feature Model >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > > We need a service that can report on the feature model that is launched by > the launcher, for introspection purposes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] bosschaert opened a new pull request #3: SLING-7970 Add Feature Model introspection service
bosschaert opened a new pull request #3: SLING-7970 Add Feature Model introspection service URL: https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/3 Get the launcher to install a Felix Inventory Printer service that prints the effective feature. This can be used to report on the selected feature. Additionally register a service that can find the Bundle Artifact ID from a given Bundle Symbolic Name and Version. This can be used to find a bundle in a feature description. The interface for this service can be found here https://github.com/apache/sling-whiteboard/blob/master/featuremodel/feature-service/src/main/java/org/apache/sling/feature/service/Bundles.java This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: [sling:resourceType] protected execution
I don't think we are all that far off from each other.
1. Each resource provider, if it supports security, should be responsible for
security
2. There should be a common interface to tell a resource provider what
permissions to be set.
3. I should be able to take a resource and if I have the privilege, determine
what permission restrictions are in force. This should work no matter what the
resource provider is.
And where I feel I'm really differing from others:
4. The permissions should be reflected within the context of the resources that
the resource provider provides. Much like how the jcr resource provider stores
acl as a rep:policy node. If I tell the servlet resource provider to that only
admin can get to any servlets under /content/custom/servlets/ that when I'm
using a resource browser to go down that tree, the resource provider adds
something like /content/custom/servlets/sling:policy that defines what was set.
What I don't want as a user is to have multiple locations to check to determine
what restrictions are being set for a given path. What I don't want as a
developer is to have multiple classes to deal with so that I have to create
restrictions differently if a user asks me to set a restriction on a resource.
I want magic
{mock}
SlingSecurity security = resource.adaptTo(SlingSecurity);
security.grantRead("bob")
for (SecurityRules rule: security.appliedRules()){
print(rules.toString());
}
{/end}
which would produce
admin / all *
set by jcr resourceProvider
sling-scripting / denyAll * set by jcr
resourceProvider
generic-users /custom read * set by file
resourceProvider
bob /custom/pathread* set by jasons
awesome customResourceProvider
Where I have a problem with Radu's original suggestion is that the permissions
are defined in a separate tree, I would have less of a problem with this, if
the resource providers checked this tree and echoed them out, or if multiple
resource providers used this tree as a common store of permissions. I don't
care so much then. I'm more concerned about the experience and the interface.
- Jason
On Fri, Oct 5, 2018, at 12:52 AM, Carsten Ziegeler wrote:
> Well, this will be a fun discussion :) Adding security on top of
> something is usually easier to be bypassed than having security built-in.
>
> But I would like to get briefly back to the use case of this "dangerous
> servlet". Why isn't that servlet doing the permission checks which I
> think is way safer than relying on additional magic somewhere else
> (regardless of what it is)?
>
> Regards
> Carsten
>
[jira] [Commented] (SLING-7978) Sling Mocks: Allow easy access to the ModelFactory
[
https://issues.apache.org/jira/browse/SLING-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639596#comment-16639596
]
Konrad Windszus commented on SLING-7978:
Merged with
https://github.com/apache/sling-site/commit/9c7262ba0c35c6e9779f38a425daa406ceb1e7c2.
> Sling Mocks: Allow easy access to the ModelFactory
> --
>
> Key: SLING-7978
> URL: https://issues.apache.org/jira/browse/SLING-7978
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing Sling Mock 2.3.4
>Reporter: Konrad Windszus
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently you would instantiate a Sling Model in a unit test leveraging Sling
> Mocks via
> {code}
> @Rule
> public SlingContext context = new
> SlingContext(ResourceResolverType.RESOURCERESOLVER_MOCK);
> @Test
> public void testModel() {
> context.load()
>.json(, "/page1");
> context.addModelsForClasses(MyModel.class);
> MyModel model =
> context.resourceResolver().getResource("/page1").adaptTo(MyModel.class)
> // model is now null for some reason, hard to debug why
> {code}
> In case for some reason the model cannot be instantiated it is hard to debug
> why (because by default the reason is only emitted in the log with level
> DEBUG). To ease debugging it would be nice if {{ModelFactory}} (SLING-3709)
> could be used, as that throws an explicit exception in case of instantiation
> errrors. It would be nice to give direct access to that service directly from
> the {{SlingContext}}.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7978) Sling Mocks: Allow easy access to the ModelFactory
[
https://issues.apache.org/jira/browse/SLING-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639631#comment-16639631
]
Konrad Windszus commented on SLING-7978:
I published the updated site to
https://sling.apache.org/documentation/development/sling-mock.html#sling-models.
> Sling Mocks: Allow easy access to the ModelFactory
> --
>
> Key: SLING-7978
> URL: https://issues.apache.org/jira/browse/SLING-7978
> Project: Sling
> Issue Type: Improvement
> Components: Site, Testing
>Reporter: Konrad Windszus
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently you would instantiate a Sling Model in a unit test leveraging Sling
> Mocks via
> {code}
> @Rule
> public SlingContext context = new
> SlingContext(ResourceResolverType.RESOURCERESOLVER_MOCK);
> @Test
> public void testModel() {
> context.load()
>.json(, "/page1");
> context.addModelsForClasses(MyModel.class);
> MyModel model =
> context.resourceResolver().getResource("/page1").adaptTo(MyModel.class)
> // model is now null for some reason, hard to debug why
> {code}
> In case for some reason the model cannot be instantiated it is hard to debug
> why (because by default the reason is only emitted in the log with level
> DEBUG). To ease debugging it would be nice if {{ModelFactory}} (SLING-3709)
> could be used, as that throws an explicit exception in case of instantiation
> errrors. It would be nice to give direct access to that service directly from
> the {{SlingContext}}.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SLING-7978) Sling Mocks: Allow easy access to the ModelFactory
[
https://issues.apache.org/jira/browse/SLING-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved SLING-7978.
Resolution: Fixed
> Sling Mocks: Allow easy access to the ModelFactory
> --
>
> Key: SLING-7978
> URL: https://issues.apache.org/jira/browse/SLING-7978
> Project: Sling
> Issue Type: Improvement
> Components: Site, Testing
>Reporter: Konrad Windszus
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently you would instantiate a Sling Model in a unit test leveraging Sling
> Mocks via
> {code}
> @Rule
> public SlingContext context = new
> SlingContext(ResourceResolverType.RESOURCERESOLVER_MOCK);
> @Test
> public void testModel() {
> context.load()
>.json(, "/page1");
> context.addModelsForClasses(MyModel.class);
> MyModel model =
> context.resourceResolver().getResource("/page1").adaptTo(MyModel.class)
> // model is now null for some reason, hard to debug why
> {code}
> In case for some reason the model cannot be instantiated it is hard to debug
> why (because by default the reason is only emitted in the log with level
> DEBUG). To ease debugging it would be nice if {{ModelFactory}} (SLING-3709)
> could be used, as that throws an explicit exception in case of instantiation
> errrors. It would be nice to give direct access to that service directly from
> the {{SlingContext}}.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7978) Sling Mocks: Allow easy access to the ModelFactory
[
https://issues.apache.org/jira/browse/SLING-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-7978:
---
Affects Version/s: (was: Testing Sling Mock 2.3.4)
> Sling Mocks: Allow easy access to the ModelFactory
> --
>
> Key: SLING-7978
> URL: https://issues.apache.org/jira/browse/SLING-7978
> Project: Sling
> Issue Type: Improvement
> Components: Site, Testing
>Reporter: Konrad Windszus
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently you would instantiate a Sling Model in a unit test leveraging Sling
> Mocks via
> {code}
> @Rule
> public SlingContext context = new
> SlingContext(ResourceResolverType.RESOURCERESOLVER_MOCK);
> @Test
> public void testModel() {
> context.load()
>.json(, "/page1");
> context.addModelsForClasses(MyModel.class);
> MyModel model =
> context.resourceResolver().getResource("/page1").adaptTo(MyModel.class)
> // model is now null for some reason, hard to debug why
> {code}
> In case for some reason the model cannot be instantiated it is hard to debug
> why (because by default the reason is only emitted in the log with level
> DEBUG). To ease debugging it would be nice if {{ModelFactory}} (SLING-3709)
> could be used, as that throws an explicit exception in case of instantiation
> errrors. It would be nice to give direct access to that service directly from
> the {{SlingContext}}.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7978) Sling Mocks: Allow easy access to the ModelFactory
[
https://issues.apache.org/jira/browse/SLING-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-7978:
---
Component/s: Site
> Sling Mocks: Allow easy access to the ModelFactory
> --
>
> Key: SLING-7978
> URL: https://issues.apache.org/jira/browse/SLING-7978
> Project: Sling
> Issue Type: Improvement
> Components: Site, Testing
>Reporter: Konrad Windszus
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently you would instantiate a Sling Model in a unit test leveraging Sling
> Mocks via
> {code}
> @Rule
> public SlingContext context = new
> SlingContext(ResourceResolverType.RESOURCERESOLVER_MOCK);
> @Test
> public void testModel() {
> context.load()
>.json(, "/page1");
> context.addModelsForClasses(MyModel.class);
> MyModel model =
> context.resourceResolver().getResource("/page1").adaptTo(MyModel.class)
> // model is now null for some reason, hard to debug why
> {code}
> In case for some reason the model cannot be instantiated it is hard to debug
> why (because by default the reason is only emitted in the log with level
> DEBUG). To ease debugging it would be nice if {{ModelFactory}} (SLING-3709)
> could be used, as that throws an explicit exception in case of instantiation
> errrors. It would be nice to give direct access to that service directly from
> the {{SlingContext}}.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7985) ProjectHelper#getConfigValue() puts null values to the resulting Set values
[
https://issues.apache.org/jira/browse/SLING-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639595#comment-16639595
]
ASF GitHub Bot commented on SLING-7985:
---
simonetripodi opened a new pull request #2: SLING-7985 -
ProjectHelper#getConfigValue() puts null values to the resulting Set
values
URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/2
proposed fix
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> ProjectHelper#getConfigValue() puts null values to the resulting Set
> values
> ---
>
> Key: SLING-7985
> URL: https://issues.apache.org/jira/browse/SLING-7985
> Project: Sling
> Issue Type: Bug
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
>
> Looks like {{null}} values can be erroneously added in the {{Set}}
> values and that are preferred to the default value.
> A safer way is adding more safe guards, i.e.
> {noformat}
> if ( pluginNode != null
> && pluginNode.getValue() != null
> && !pluginNode.getValue().isEmpty() ) {
> values.add(pluginNode.getValue());
> }
> {noformat}
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] simonetripodi opened a new pull request #2: SLING-7985 - ProjectHelper#getConfigValue() puts null values to the resulting Set values
simonetripodi opened a new pull request #2: SLING-7985 - ProjectHelper#getConfigValue() puts null values to the resulting Set values URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/2 proposed fix This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (SLING-7985) ProjectHelper#getConfigValue() puts null values to the resulting Set values
Simone Tripodi created SLING-7985:
-
Summary: ProjectHelper#getConfigValue() puts null values to the
resulting Set values
Key: SLING-7985
URL: https://issues.apache.org/jira/browse/SLING-7985
Project: Sling
Issue Type: Bug
Components: Feature Model, Maven Plugins and Archetypes
Reporter: Simone Tripodi
Assignee: David Bosschaert
Looks like {{null}} values can be erroneously added in the {{Set}}
values and that are preferred to the default value.
A safer way is adding more safe guards, i.e.
{noformat}
if ( pluginNode != null
&& pluginNode.getValue() != null
&& !pluginNode.getValue().isEmpty() ) {
values.add(pluginNode.getValue());
}
{noformat}
PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [sling:resourceType] protected execution
Hi, Since this thread exploded so quickly it’s going to be difficult to respond to all of your questions / concerns individually. We eagerly started discussing implementation details (of which I’m to blame too) and I think we didn’t read between the lines of this thread or the previous [0] to check what the perceived problems are. Both threads identified several issues: 1. Users can freely define sling:resourceType properties 2. Through 1, users can therefore trigger code execution which is not always appropriate (depends on how Servlets / scripts are written and the potential they have to DoS a system or to expose sensible information to users which shouldn’t have the ability to perform those operations) 3. For some operations (servlet execution, tasks, etc.) we might want to provide a set of permissions to check beforehand in order to decide if a user is allowed to perform said operation or not. In this thread I proposed an idea to fix issue no. 2 (which IMO is easier to accomplish) - and by fix I mean provide a way to define who can execute what - so that we don’t care about issue no. 1 any more. Let’s try to figure out if indeed these are some serious problems that need to be addressed or not. We can discuss implementation details afterwards. Cheers, Radu
Re: Introducing the Feature json schema validation
Hi Simo, It would be great if we had a JSON Schema definition for the feature files and if we could use that for validation. The schema itself can already be useful for documentation purposes! +1 from me. David On Fri, 5 Oct 2018 at 10:06, Simone Tripodi wrote: > Hi all, > I did an experiment yesterday in the night with the Apache Johnzon JSON > Schema implementation [1], but it doesn't fails where it is expect to be. > I'll do some other tries during the WE :P > ~Simo > > [1] https://johnzon.apache.org/ > > http://people.apache.org/~simonetripodi/ > http://twitter.com/simonetripodi > > > On Thu, Oct 4, 2018 at 5:02 PM Simone Tripodi > wrote: > > > Hi all mates, > > > > while working on an idea of a JSON streaming parser for the Feature > model, > > I noticed that the parser has the delegation of validating the input, > other > > than transforming the json structure the the Feature model. > > > > Given my experience of (many, sigh) years ago I when contributed to the > > Plexus Modello the JSON schema generator, I wrote an initial prototype of > > the Apache Sling Feature JSON schema[2] compliant with the latest #7 > draft, > > and playing around with tests model with an online schema validator[2]. > > The proposed schema supports extensions handling, validating the object > > value type (JSON/TEXT/ARTIFACTS). > > > > I see the advantages below of adopting such schema: > > > > * to have a formal and standard way to describe the Feature data > > structure in JSON model; > > > > * provide an easy way to assist users on editing Feature json files in > > the right way inside IDEs, as shown in Eclipse[3] and IntelliJ[4]; > > > > * separate the input validation - it can be delegated by the Feature > > Analyzer - and the parser phases (which should just take care of > > transforming the JSON data to the Feature model): unfortunately there are > > no up-to-date Java implementations, the most well-known [5] works on > > org.json implementation and the other one [6] is "still" at the draft #4 > > (aside that relies on too many dependencies). > > An alternative could be writing a simple validator for our use case, > based > > on the proposed schema. > > > > WDYT? > > I would like to contribute the schema [1] to one of the feature modules, > > maybe the -io is the more appropriate. > > > > I hope that could be interesting, have a nice day and all the best! > > ~Simo > > > > [1] > https://gist.github.com/simonetripodi/c69d2ffebdbd2c4b1355df60568f1ab5 > > [2] https://www.jsonschemavalidator.net/ > > [3] > > > https://stackoverflow.com/questions/50011837/how-to-do-json-schema-validation-in-eclipse > > [4] > > https://www.jetbrains.com/help/idea/settings-languages-json-schema.html > > [5] https://github.com/everit-org/json-schema > > [6] https://github.com/java-json-tools/json-schema-validator > > > > http://people.apache.org/~simonetripodi/ > > http://twitter.com/simonetripodi > > >
[jira] [Updated] (SLING-7978) Sling Mocks: Allow easy access to the ModelFactory
[
https://issues.apache.org/jira/browse/SLING-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-7978:
---
Issue Type: Improvement (was: Bug)
> Sling Mocks: Allow easy access to the ModelFactory
> --
>
> Key: SLING-7978
> URL: https://issues.apache.org/jira/browse/SLING-7978
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing Sling Mock 2.3.4
>Reporter: Konrad Windszus
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently you would instantiate a Sling Model in a unit test leveraging Sling
> Mocks via
> {code}
> @Rule
> public SlingContext context = new
> SlingContext(ResourceResolverType.RESOURCERESOLVER_MOCK);
> @Test
> public void testModel() {
> context.load()
>.json(, "/page1");
> context.addModelsForClasses(MyModel.class);
> MyModel model =
> context.resourceResolver().getResource("/page1").adaptTo(MyModel.class)
> // model is now null for some reason, hard to debug why
> {code}
> In case for some reason the model cannot be instantiated it is hard to debug
> why (because by default the reason is only emitted in the log with level
> DEBUG). To ease debugging it would be nice if {{ModelFactory}} (SLING-3709)
> could be used, as that throws an explicit exception in case of instantiation
> errrors. It would be nice to give direct access to that service directly from
> the {{SlingContext}}.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7978) Sling Mocks: Allow easy access to the ModelFactory
[
https://issues.apache.org/jira/browse/SLING-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639528#comment-16639528
]
Stefan Seifert commented on SLING-7978:
---
lgtm
> Sling Mocks: Allow easy access to the ModelFactory
> --
>
> Key: SLING-7978
> URL: https://issues.apache.org/jira/browse/SLING-7978
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing Sling Mock 2.3.4
>Reporter: Konrad Windszus
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently you would instantiate a Sling Model in a unit test leveraging Sling
> Mocks via
> {code}
> @Rule
> public SlingContext context = new
> SlingContext(ResourceResolverType.RESOURCERESOLVER_MOCK);
> @Test
> public void testModel() {
> context.load()
>.json(, "/page1");
> context.addModelsForClasses(MyModel.class);
> MyModel model =
> context.resourceResolver().getResource("/page1").adaptTo(MyModel.class)
> // model is now null for some reason, hard to debug why
> {code}
> In case for some reason the model cannot be instantiated it is hard to debug
> why (because by default the reason is only emitted in the log with level
> DEBUG). To ease debugging it would be nice if {{ModelFactory}} (SLING-3709)
> could be used, as that throws an explicit exception in case of instantiation
> errrors. It would be nice to give direct access to that service directly from
> the {{SlingContext}}.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Introducing the Feature json schema validation
Hi all, I did an experiment yesterday in the night with the Apache Johnzon JSON Schema implementation [1], but it doesn't fails where it is expect to be. I'll do some other tries during the WE :P ~Simo [1] https://johnzon.apache.org/ http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Thu, Oct 4, 2018 at 5:02 PM Simone Tripodi wrote: > Hi all mates, > > while working on an idea of a JSON streaming parser for the Feature model, > I noticed that the parser has the delegation of validating the input, other > than transforming the json structure the the Feature model. > > Given my experience of (many, sigh) years ago I when contributed to the > Plexus Modello the JSON schema generator, I wrote an initial prototype of > the Apache Sling Feature JSON schema[2] compliant with the latest #7 draft, > and playing around with tests model with an online schema validator[2]. > The proposed schema supports extensions handling, validating the object > value type (JSON/TEXT/ARTIFACTS). > > I see the advantages below of adopting such schema: > > * to have a formal and standard way to describe the Feature data > structure in JSON model; > > * provide an easy way to assist users on editing Feature json files in > the right way inside IDEs, as shown in Eclipse[3] and IntelliJ[4]; > > * separate the input validation - it can be delegated by the Feature > Analyzer - and the parser phases (which should just take care of > transforming the JSON data to the Feature model): unfortunately there are > no up-to-date Java implementations, the most well-known [5] works on > org.json implementation and the other one [6] is "still" at the draft #4 > (aside that relies on too many dependencies). > An alternative could be writing a simple validator for our use case, based > on the proposed schema. > > WDYT? > I would like to contribute the schema [1] to one of the feature modules, > maybe the -io is the more appropriate. > > I hope that could be interesting, have a nice day and all the best! > ~Simo > > [1] https://gist.github.com/simonetripodi/c69d2ffebdbd2c4b1355df60568f1ab5 > [2] https://www.jsonschemavalidator.net/ > [3] > https://stackoverflow.com/questions/50011837/how-to-do-json-schema-validation-in-eclipse > [4] > https://www.jetbrains.com/help/idea/settings-languages-json-schema.html > [5] https://github.com/everit-org/json-schema > [6] https://github.com/java-json-tools/json-schema-validator > > http://people.apache.org/~simonetripodi/ > http://twitter.com/simonetripodi >
Re: [sling:resourceType] protected execution
Hi, On Fri, Oct 5, 2018 at 6:52 AM Carsten Ziegeler wrote: > ...I would like to get briefly back to the use case of this "dangerous > servlet". Why isn't that servlet doing the permission checks which I > think is way safer than relying on additional magic somewhere else > (regardless of what it is)?... That servlet can of course do its own checks, but how? I don't think we have a recommended way of doing that, nor tools that help. The goal here is to define a standard way for how code running in Sling can check permissions, which can be as simple as void checkAllPermissions(ResourceResolver context, String ... permissionName) throws PermissionDeniedException One idea discussed earlier was to create a generic permissions checking service for that. Here I think Radu is taking the angle that such permissions are currently only needed for resource types, servlets and scripts, so this permissions API and impl can stay internal to the servlets resolver module for now. I think that works, provided that's designed in a way that allow us to take it out into a standalone module if needed later. -Bertrand
