nk.
Jamie.
-Original Message-
From: Jamie Mortimore [mailto:[EMAIL PROTECTED]
Sent: 26 April 2004 13:06
To: Slide Users Mailing List
Subject: Re: patch for auto-create-users
On Mon, 2004-04-26 at 10:52, Martin Holz wrote:
> > I added a createUser method to the Content interface an
Martin Holz wrote:
Don't use SlideRealm. The slide realm makes user/password combinations
available to the servlet container.
I am not grasping this part. You mean that slide realm becomes the store
for usernames/passwords that the servlet container authenticates against?
Any realm does not ha
"Ryan Rhodes" <[EMAIL PROTECTED]> writes:
> Well, I should restate that. I do need roles. I was actually hoping
> to use SlideRealm, because I want other parts of the webapp to use
> Slide roles for access control.
>
>
> The only reason I need LDAP is because usernames/passwords must all
> co
-Ryan
From: Martin Holz <[EMAIL PROTECTED]>
Reply-To: "Slide Users Mailing List" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: patch for auto-create-users
Date: 27 Apr 2004 17:32:51 +0200
"Ryan Rhodes" <[EMAIL PROTECTED]> writes:
> I went through
"Ryan Rhodes" <[EMAIL PROTECTED]> writes:
> I went through the same progression as Jamie with auto-create-users.
> It would have been nice to have when I started, but it doesn't add
> anything now since I ultimately need the LDAP sync'd setup as well.
>
> Could you give an idea of just how much
Daniel Florey wrote:
It is possible to assign different stores to different scopes (like mount
points), so you don't need the proxy thing. So the main task would be to
write a LDAP-store. To have such a store would be really a great thing so
that users and roles are stored only in one physical
ExtendedStore allows you to invalidate entries. Subclass it and add your
code that talks to your client store to find out which entries to
delete. Use something like getTxCache().remove(null, [key to be
invalidated] on objectsCache, permissionsCache, etc.
Oliver
Carlos Villegas wrote:
Hi,
Da
Hi,
Daniel Florey wrote:
If LDAP provides some notification mechanism for informing slide about
user/role updates additional user/role caching would be possible to
achieve better performance.
I have a custom store that gets user/role info from an external source.
I set it up in the Domain.xml
imply making sure no user had any write permissions?
-Original Message-
From: Martin Holz [mailto:[EMAIL PROTECTED]
Sent: 26 April 2004 13:49
To: [EMAIL PROTECTED]
Subject: Re: patch for auto-create-users
Daniel Florey <[EMAIL PROTECTED]> writes:
Hi,
I'd propose to add the meth
slide and listen for
updates on LDAP to keep the two in sync.
Could you not make a store read-only by simply making sure no user had any write
permissions?
-Original Message-
From: Martin Holz [mailto:[EMAIL PROTECTED]
Sent: 26 April 2004 13:49
To: [EMAIL PROTECTED]
Subject: Re: patch f
Daniel Florey <[EMAIL PROTECTED]> writes:
> Hi,
> I'd propose to add the methods regarding the user/role stuff to the
> Security-Interface and the SecurityImpl-class. There already are some
> methods regarding user/role management (hasRole()...)
This is not possible, since the methods need access
Jamie Mortimore <[EMAIL PROTECTED]> writes:
> Are you saying there is a way webdav methods are called that do not go
> through AbstractWebdavMethod.run? Is there a more appropriate place to
> call the createUser method (eg at the start of WebdavServlet.service)?
I think, AbstractWebdavMethod.ru
Hi,
I'd propose to add the methods regarding the user/role stuff to the
Security-Interface and the SecurityImpl-class. There already are some
methods regarding user/role management (hasRole()...)
In general I think it would be better to have only one place (e.g. LDAP)
where users are managed and
On Mon, 2004-04-26 at 10:52, Martin Holz wrote:
> > I added a createUser method to the Content interface and implementation,
> > ContentImpl. You may decide this is not the right place for a create
> > user method if Content is only supposed to handle more low level
> > operations. In which case th
Jamie Mortimore <[EMAIL PROTECTED]> writes:
> The user would be created if the getPrincipal method was called from
> within a transaction but the newly created user would not be setup with
> the correct role. For example it would create the user if you perform a
> PUT method with the new user but
Hi Oliver,
With the auto-create-users functionality enabled the
SecurityImpl.getPrincipal method would try to create a user in slide if
the current user was not set up in slide.
There were a couple of problems with this.
Firstly not all webdav methods require a transaction but the creation of
a
Hi Jamie!
Thanks for the patch :)
In order for me to evaluate could you please explain what you did in the
patch and why? What exactly was broken and what did you fix?
For future contributions could you please create the diffs using -u
instead of -c?
Thanks again,
Oliver
Jamie Mortimore wro
17 matches
Mail list logo
