On Thu, Mar 7, 2013 at 12:55 AM, Ian Boston i...@tfd.co.uk wrote:
...If there are other areas where its possible, with ease to create
critical security issues, then I think we must address those
immediately.
Please share, ideally on list.
If you think its not for public list consumption
Hi,
On Wed, Mar 6, 2013 at 8:40 AM, Carsten Ziegeler cziege...@apache.org wrote:
...Then we have the issue of whether to put the support for this into the
resource resolver bundle or not - while I see the point for keeping it
separate, I think it is a central piece of the resource resolving
With the ResourceResolverDecorator we open another dimension. We argue
that people might shoot themselves in the foot by implementing a
ResourceAccessGate, Therefore we put the implementation into a
different bundle.
At the same time we add support for ResourceResolverDecorator to the
resource
On Wed, Mar 6, 2013 at 11:03 AM, Carsten Ziegeler cziege...@apache.org wrote:
...this would mean, we trust people implementing
ResourceResolverDecorator, but we don't trust them implementing
ResourceAccessGates
I see your point...I guess it's very subjective factors here, I prefer
Hello
Please accept my 2.3 cents to this discussion:
I really agree with Angela and Bertrand on this one.
Something that could be called AccessGate is clearly a security
mechanism, and should thus be designed with single point of access in
mind.
Having ACL evaluations scattered among the
Agree. The core problem of the access gate is that it applies *on top of* all
the resource providers, for the entire virtual resource tree created by the
resource resolver (at least that's how I understand the current patch).
That will seem like an easy way for devs to hook in some ad-hoc
2013/3/6 Lars Krapf lkr...@adobe.com:
if time-based access control
is really needed.
Time based access restriction is one of the main use cases as Mike has
explained repeatedly.
This is also an example of how this feature would weaken
security. In order to allow access to a resource within a
I can easily write a resource provider which uses an admin session to
interact with the repository and mount this into the resource tree
bypassing all ACLs checks.
Features can be abused - no matter what we do. We have valid use cases
for this concrete feature, so why are we making it so hard
hi carsten
On 3/6/13 12:45 PM, Carsten Ziegeler wrote:
2013/3/6 Lars Krapflkr...@adobe.com:
if time-based access control
is really needed.
Time based access restriction is one of the main use cases as Mike has
explained repeatedly.
and time-based access restriction is as much an ACL feature
Hello Carsten
On 03/06/2013 12:45 PM, Carsten Ziegeler wrote:
2013/3/6 Lars Krapf lkr...@adobe.com:
if time-based access control
is really needed.
Time based access restriction is one of the main use cases as Mike has
explained repeatedly.
Yes - I understand that. The important part of my
Hi Carsten,
On Wed, Mar 6, 2013 at 12:45 PM, Carsten Ziegeler cziege...@apache.org wrote:
...Now Mike has started work and immediately everyone and his dog is
going back to the old discussion. :(...
So far, between SLING-2698 and this thread AFAICS you're the only one
who doesn't want the
We discussing two things here :) a) if we should add the gate at all
(and I'm referring more to this) and b) the technical implementation
of the feature.
I agree that I'm the only one against the Decorator :( And I will
definitely not call a vote for such a discussion :)
Still, I fail to see a
Hi Mike,
Sorry for all the flak you're getting - this JCR vs. other providers
thing is probably at the core of that, so thanks for bringing it up.
On Wed, Mar 6, 2013 at 3:43 PM, Mike Müller mike...@mysign.ch wrote:
...One thing which was never taken in account
is that Sling is not only a
2013/3/6 Bertrand Delacretaz bdelacre...@apache.org:
Making it clear that Sling has two major modes, JCR (with
repository-based access control) and non-JCR (with do-it-yourself
access control) would probably help all of us who don't like the
current proposals.
Although this is OT, I don't
On 06.03.2013, at 15:43, Mike Müller mike...@mysign.ch wrote:
Think of a sling application with different providers installed, say all
registered somewhere under /mypath/...
Now, how should it be easily managed to restrict access to all resources
Under /mypath/... to be accessed only by
On Wed, Mar 6, 2013 at 4:03 PM, Carsten Ziegeler cziege...@apache.org wrote:
2013/3/6 Bertrand Delacretaz bdelacre...@apache.org:
Making it clear that Sling has two major modes, JCR (with
repository-based access control) and non-JCR...
Although this is OT, I don't agree with this statement:
Just to throw in some more ideas :) what about a decorator for
resource providers? This would also solve the use case of easily
adding additional checks to resource providers who don't have their
own access checks without needing to code this into each and every
provider.
And a
Just to throw in some more ideas :) what about a decorator for
resource providers? This would also solve the use case of easily
adding additional checks to resource providers who don't have their
own access checks without needing to code this into each and every
provider.
And a
On Wed, Mar 6, 2013 at 4:32 PM, Mike Müller mike...@mysign.ch wrote:
...A ResourceProviderDecorator couldn't do the job, because some operations
are on the ResourceResolver at the moment (delete, create but also
findResources
and queryResources)
Does that indicate that those operations
Many modern stores do not provide any security, they're just stupid
key-value or column stores.
How about being able to promote Sling + HBase as a scalable web
framework, for example? How about Sling as web layer for Solr?
That would be very cool IMO, and if you want ACLs in such a setup
On 06/mar/2013, at 16:15, Bertrand Delacretaz wrote:
On Wed, Mar 6, 2013 at 4:08 PM, Alexander Klimetschek
aklim...@adobe.commailto:aklim...@adobe.com wrote:
... Sling is a web framework, about routing, servlet + script rendering etc.
Defining ACL security is not
it's business - this is the
On Wed, Mar 6, 2013 at 4:32 PM, Mike Müller mike...@mysign.ch wrote:
...A ResourceProviderDecorator couldn't do the job, because some operations
are on the ResourceResolver at the moment (delete, create but also
findResources
and queryResources)
Does that indicate that those
very nice summary. thanks alex for writing this up.
kind regards
angela
On 3/6/13 12:45 PM, Alexander Klimetschek wrote:
Agree. The core problem of the access gate is that it applies *on top of* all the
resource providers, for the entire virtual resource tree created by the
resource resolver
2013/3/6 Mike Müller mike...@mysign.ch:
Just to throw in some more ideas :) what about a decorator for
resource providers? This would also solve the use case of easily
adding additional checks to resource providers who don't have their
own access checks without needing to code this into each
2013/3/6 Mike Müller mike...@mysign.ch:
Just to throw in some more ideas :) what about a decorator for
resource providers? This would also solve the use case of easily
adding additional checks to resource providers who don't have their
own access checks without needing to code this into
On Wed, Mar 6, 2013 at 5:34 PM, Mike Müller mike...@mysign.ch wrote:
...We could do it with a ResourceProviderDecorator.
If we do that, we could implement a service param (or something else) in a
way that's easy
To only decorate some providers. So someone can decorate for example only
Yepp, in a new thread please :)
Carsten
2013/3/6 Bertrand Delacretaz bdelacre...@apache.org:
On Wed, Mar 6, 2013 at 5:34 PM, Mike Müller mike...@mysign.ch wrote:
...We could do it with a ResourceProviderDecorator.
If we do that, we could implement a service param (or something else) in a
hi carsten
Finally, although this feature is optional and has no impact if not
used, there are valid concerns that this might be easily abused. But
we can't prevent anyone from abusing stuff and we already have various
places where people do funny things.
just to make it very clear: it's not
On 06.03.2013, at 16:22, Carsten Ziegeler cziege...@apache.org wrote:
Just to throw in some more ideas :) what about a decorator for
resource providers? This would also solve the use case of easily
adding additional checks to resource providers who don't have their
own access checks without
Hi,
I am just catching up on this thread, since it all happened when I was
sleeping, and wanted to share some of my many past misdemeanors and
mistakes.
I too once had a need for Time based and Rule based ACLs associated
with JCR based paths. I did this rightly or wrongly by extending the
On 7 March 2013 04:31, Angela Schreiber anch...@adobe.com wrote:
hi carsten
Finally, although this feature is optional and has no impact if not
used, there are valid concerns that this might be easily abused. But
we can't prevent anyone from abusing stuff and we already have various
places
Hi,
I would love to move forward with this one.
I think Felix raised some valid concerns about the API which could be
fixed easily. In addition (as I wrote in the bug), I think the API
should go into a separate package. Main reason is package versioning.
The resource package is already
32 matches
Mail list logo
