You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2010/01/25 15:02:03 UTC
Re: svn commit: r902726 - in /jackrabbit/sandbox/jackrabbit2-bundle/jackrabbit-api:
./ pom.xml src/main/java/org/apache/jackrabbit/api/JackrabbitRepository.java
Hi,
On Mon, Jan 25, 2010 at 9:45 AM, <fm...@apache.org> wrote:
> + Session loginAdministrative(String workspace) throws LoginException,
> + NoSuchWorkspaceException, RepositoryException;
I quite dislike this method, as it essentially gives all clients the
ability to access the repository as administrators. There's no way for
the repository implementation to verify that the client is doing the
right thing.
I'd rather see such functionality exposed through normal credentials
with some shared secret, or alternatively through the
RepositoryManager interface for which we already solved the
"administrator-only" access problem.
BR,
Jukka Zitting
Re: svn commit: r902726 - in /jackrabbit/sandbox/jackrabbit2-bundle/jackrabbit-api:
./ pom.xml src/main/java/org/apache/jackrabbit/api/JackrabbitRepository.java
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 25.01.2010 15:02, Jukka Zitting wrote:
> Hi,
>
> On Mon, Jan 25, 2010 at 9:45 AM, <fm...@apache.org> wrote:
>> + Session loginAdministrative(String workspace) throws LoginException,
>> + NoSuchWorkspaceException, RepositoryException;
>
> I quite dislike this method, as it essentially gives all clients the
> ability to access the repository as administrators. There's no way for
> the repository implementation to verify that the client is doing the
> right thing.
Well, yes. On the other hand in Sling this method proved quite useful
(not polluting tons of code with keeping some shared secret).
In a safe environment such a method should probably be JAAS guarded any
way and I would assume that remote repository implementations would also
be implemented as a simple "throw new LoginException()".
>
> I'd rather see such functionality exposed through normal credentials
> with some shared secret,
The share secret exactly has the issues noted above: Multiple code
poitns must independently be configured with the shared secret, should
this ever be modified.
> or alternatively through the
> RepositoryManager interface for which we already solved the
> "administrator-only" access problem.
I will look into this solution. Thanks for the pointer.
Regards
Felix
Re: svn commit: r902726 - in /jackrabbit/sandbox/jackrabbit2-bundle/jackrabbit-api:
./ pom.xml src/main/java/org/apache/jackrabbit/api/JackrabbitRepository.java
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 25.01.2010 15:38, Jukka Zitting wrote:
> Hi,
>
> On Mon, Jan 25, 2010 at 3:24 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> On 25.01.2010 15:02, Jukka Zitting wrote:
>>> RepositoryManager interface for which we already solved the
>>> "administrator-only" access problem.
>>
>> Please excuse my ignorance: What RepositoryManager interface are you
>> talking of. The one I find in
>> org.apache.jackrabbit.api.management.RepositoryManager and its
>> implementation o.a.j.core.RepositoryManagerImpl do not seem to "solve"
>> this issue.
>
> That's the one. The point about this interface is that normal client
> code that's given a Session or a Repository instance can never get
> access to the RepositoryManager instance. Only code that instantiated
> the Repository can use the
> JackrabbitRepositoryFactory.getRepositoryManager() method to get the
> RepositoryManager instance.
Well, then this is probably not practical for my use case, which is to
allow code to use the mechanism. Otherwise I would not needs such a method.
I will try to find another solution - maybe based on our old
SlingRepository interface, which we might have to keep for backwards
compatibility anyways.
>
>> Actually: the JackrabbitRepository.shutdown() method is also very
>> dangerous and does not require any level of protection. Or am I misssing
>> something ?
>
> The location shutdown() method has quite often been deemed a mistake.
> The plan is to deprecate the shutdown() method in favor of
> RepositoryManager.stop().
>
> See http://markmail.org/message/ghfqwhivipkxakwh for the related
> thread from last September.
Ok, thanks for the info.
Regards
Felix
Re: svn commit: r902726 - in /jackrabbit/sandbox/jackrabbit2-bundle/jackrabbit-api:
./ pom.xml src/main/java/org/apache/jackrabbit/api/JackrabbitRepository.java
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Jan 25, 2010 at 3:24 PM, Felix Meschberger <fm...@gmail.com> wrote:
> On 25.01.2010 15:02, Jukka Zitting wrote:
>> RepositoryManager interface for which we already solved the
>> "administrator-only" access problem.
>
> Please excuse my ignorance: What RepositoryManager interface are you
> talking of. The one I find in
> org.apache.jackrabbit.api.management.RepositoryManager and its
> implementation o.a.j.core.RepositoryManagerImpl do not seem to "solve"
> this issue.
That's the one. The point about this interface is that normal client
code that's given a Session or a Repository instance can never get
access to the RepositoryManager instance. Only code that instantiated
the Repository can use the
JackrabbitRepositoryFactory.getRepositoryManager() method to get the
RepositoryManager instance.
> Actually: the JackrabbitRepository.shutdown() method is also very
> dangerous and does not require any level of protection. Or am I misssing
> something ?
The location shutdown() method has quite often been deemed a mistake.
The plan is to deprecate the shutdown() method in favor of
RepositoryManager.stop().
See http://markmail.org/message/ghfqwhivipkxakwh for the related
thread from last September.
BR,
Jukka Zitting
Re: svn commit: r902726 - in /jackrabbit/sandbox/jackrabbit2-bundle/jackrabbit-api:
./ pom.xml src/main/java/org/apache/jackrabbit/api/JackrabbitRepository.java
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 25.01.2010 15:02, Jukka Zitting wrote:
> Hi,
>
> On Mon, Jan 25, 2010 at 9:45 AM, <fm...@apache.org> wrote:
>> + Session loginAdministrative(String workspace) throws LoginException,
>> + NoSuchWorkspaceException, RepositoryException;
>
> I quite dislike this method, as it essentially gives all clients the
> ability to access the repository as administrators. There's no way for
> the repository implementation to verify that the client is doing the
> right thing.
>
> I'd rather see such functionality exposed through normal credentials
> with some shared secret, or alternatively through the
> RepositoryManager interface for which we already solved the
> "administrator-only" access problem.
Please excuse my ignorance: What RepositoryManager interface are you
talking of. The one I find in
org.apache.jackrabbit.api.management.RepositoryManager and its
implementation o.a.j.core.RepositoryManagerImpl do not seem to "solve"
this issue.
Actually: the JackrabbitRepository.shutdown() method is also very
dangerous and does not require any level of protection. Or am I misssing
something ?
Regards
Felix