Amad Fida wrote:
Luke - In our case we use the role information from our own database
repository and only LDAP server for authenticatin. How do you
recomment we do that? Provide a implementation for
LdapAuthoritiesPopulator?
Amad
Yes. That would be the best option.
--
Luke Taylor.
Luke - In our case we use the role information from our own database repository and only LDAP server for authenticatin. How do you recomment we do that? Provide a implementation for LdapAuthoritiesPopulator?AmadLuke Taylor <[EMAIL PROTECTED]> wrote: Brandon Keepers wrote:> Luke,> > One feature that
Brandon Keepers wrote:
Luke,
One feature that the sandbox LDAP provider had that was extremely
useful was the ability to set a default role. In some of my apps, I
don't care what groups a user is in. If they're in the directory,
then I want them to be in ROLE_USER. Could that be added to th
Luke,
One feature that the sandbox LDAP provider had that was extremely
useful was the ability to set a default role. In some of my apps, I
don't care what groups a user is in. If they're in the directory,
then I want them to be in ROLE_USER. Could that be added to the
DefaultLdapAuthoritiesPop
Thanks a lot for your comments, Brandon. Especially since they are
largely positive :). I'm keen to get as much feedback as possible so
that we can make the release as stable as possible.
Brandon Keepers wrote:
...
There isn't an easy way to override which UserDetails implementation
is return
Brandon Keepers wrote:
Is there a good reason for requiring constructor args instead of
setter methods for properties? I don't intend to start a flame war
about constructor vs. setter injection, but I do think the setters
should at least be an option, especially to be consistent with the
rest of
Luke,
I got a chance to look through the new LDAP provider, but I won't be
able to try it out until next week. Here are some of my thoughts
after looking through the code.
There isn't an easy way to override which UserDetails implementation
is returned. As it is now, I have to extend
LdapAuthen
Brandon Keepers wrote:
Any idea when RC2 is expected to be released?
Thanks for the feedback Brandon.
RC2 will be released as soon as we receive some feedback on the new LDAP
provider, and any suggestions are implemented.
BTW, hope everyone has a great Christmas and New Year!
Cheers
Be
Luke,
The new LDAP provider and related interfaces look really good! They
look lot cleaner and more flexible than the old ones. I'm using a
hacked up version of the one in sandbox for testing right now, so I'll
give this one a try. Unfortunately, I'm off visiting family (who
don't have wireless
Carlos Sanchez wrote:
If ldap dependencies are only for testing it may be fine, you set them
to test scope and that's all. Other thing if they are required to run
because everybody using acegi and not needing ldap will get them or
will have to exclude.
That's more related with something I'd like
If ldap dependencies are only for testing it may be fine, you set them
to test scope and that's all. Other thing if they are required to run
because everybody using acegi and not needing ldap will get them or
will have to exclude.
That's more related with something I'd like to propose to 1.1 which
I agree that it might have been preferable to have had different names,
and version numbers would ideally be as rigorously enforced as you say.
I think we generally do pretty well on the stability front though
compared with a lot of projects.
I'm not particularly bothered about what version it
Then 1.0.0 should have been called M1 or alpha, when you call
something release candidate means that if there no bugs the final jar
will be exactly the same (but the version name in the manifest).
Is not that i don't like the ldap support, but this will be confusing
and a potential problem. It coul
Hi Carlos,
I think the intention is to have LDAP support in 1.0, and since it is an
extra feature, largely independent of the rest of the codebase it
shouldn't really have any impact on the code in RC1.
Luke.
Carlos Sanchez wrote:
Hi,
I've notice that this change was included after the RC1
Hi,
I've notice that this change was included after the RC1. This goes
against the version naming policy, 1.0.0 must be the same as 1.0.0-RC1
except for critical bug fixes.
It'd be better to create a branch for 1.0.0 from the 1.0.0-RC1 tag and
set HEAD to 1.1, where you could keep development.
R
Hi all,
Just a short note to say that the new incarnation of the LDAP provider
is now available if you want to take a look at it. It's still a work in
progress but I'm keen to get feedback and suggestions so that any
changes can be nailed down before the 1.0 release.
The code is in org.apach
16 matches
Mail list logo
