Attached is a patch for auto-create-users against version 2.0 of slide.
I've added the following methods to the Macro interfasce:
/**
* Adds a user.
*
* @param root The token to use to create the user.
* @param user The name of the user to create.
* @throws
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 for auto-create-users
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 methods regarding the user/role stuff
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
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,
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
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 effort
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 the same progression as Jamie with auto-create-users
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
come from
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
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
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 the
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 the
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
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.run is
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 to
In version 2.0rc1 of slide the auto-create-users functionality is not
working.
The attached patch fixes the problem. With the new functionality enabled
users authenticated by the servlet container are added as users within
slide.
It is configured with the following properties in Domain.xml:
17 matches
Mail list logo
