11:30 a.m.
Only merge of emergency/critical/blocker fixes please! I'm finishing up
one last JIRA then I'll start testing for a release tomorrow Tuesday if
there are no problems.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:01 p.m.
I've finished testing with AD and added one more commit (support
registration of new users into some Active Directory deployments).
Tomorrow, I plan to update docs for export/import but no more commits
from me (unless I found something critical and I will ping you in that
case).
btv. some more feedback and questions from LDAP testing:
* During import of realm, do we want to add users just to local store or
also to federation providers? Example: I've exported users from my realm
and some are mapped to LDAP. Now I want to import them into different
(clean) database, but during import, they are added into both local
database and into LDAP where they already exists -> error.
I wonder if we should skip adding users into FederationProviders at all
(or at least have it configurable) wdyt?
* The small disadvantage of proxy objects are multiple calls to LDAP
during single user registration. For example calling to:
user.setFirstName(formData.getFirst("firstName"));
user.setLastName(formData.getFirst("lastName"));
user.setEmail(email);
will actually perform 6 network calls to LDAP (each method call to
WritableLDAPUserModelDelegate first checks if user exists and then doing
full update of user). Do we care about this? LDAP is primarily designed
for reading, so maybe writing from Keycloak won't be often anyway? I am
not sure...
* The semantics of "searchForUser" is a bit different for
FederationProviders and our model implementations. For example, if you
have user "John Doe" and you search for "ohn Do" in admin console,
then
both JPA and Mongo local providers will return you "John Doe" as they
add % at the beginning/end. However federation providers are looking
exactly for FirstName: "ohn" , LastName: "Do", so if "John
Doe" exists
in LDAP, he won't be returned.
Marek
On 4.8.2014 18:30, Bill Burke wrote:
Only merge of emergency/critical/blocker fixes please! I'm
finishing up
one last JIRA then I'll start testing for a release tomorrow Tuesday if
there are no problems.
Bill
3:09 p.m.
On 8/4/2014 4:01 PM, Marek Posolda wrote:
I've finished testing with AD and added one more commit (support
registration of new users into some Active Directory deployments).
Tomorrow, I plan to update docs for export/import but no more commits
from me (unless I found something critical and I will ping you in that
case).
btv. some more feedback and questions from LDAP testing:
* During import of realm, do we want to add users just to local store or
also to federation providers? Example: I've exported users from my realm
and some are mapped to LDAP. Now I want to import them into different
(clean) database, but during import, they are added into both local
database and into LDAP where they already exists -> error.
I wonder if we should skip adding users into FederationProviders at all
(or at least have it configurable) wdyt?
IMO, Users shouldn't be registered with Federation Provider on an import.
* The small disadvantage of proxy objects are multiple calls to LDAP
during single user registration. For example calling to:
user.setFirstName(formData.getFirst("firstName"));
user.setLastName(formData.getFirst("lastName"));
user.setEmail(email);
will actually perform 6 network calls to LDAP (each method call to
WritableLDAPUserModelDelegate first checks if user exists and then doing
full update of user). Do we care about this? LDAP is primarily designed
for reading, so maybe writing from Keycloak won't be often anyway? I am
not sure...
Fix for after beta-4. We can add a addUser(Map<string, string>
attriutes) method?
* The semantics of "searchForUser" is a bit different for
FederationProviders and our model implementations. For example, if you
have user "John Doe" and you search for "ohn Do" in admin console,
then
both JPA and Mongo local providers will return you "John Doe" as they
add % at the beginning/end. However federation providers are looking
exactly for FirstName: "ohn" , LastName: "Do", so if "John
Doe" exists
in LDAP, he won't be returned.
Can we do anything about that? Does LDAP have a "like"?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:04 a.m.
On 4.8.2014 22:09, Bill Burke wrote:
On 8/4/2014 4:01 PM, Marek Posolda wrote:
> I've finished testing with AD and added one more commit (support
> registration of new users into some Active Directory deployments).
> Tomorrow, I plan to update docs for export/import but no more commits
> from me (unless I found something critical and I will ping you in that
> case).
>
> btv. some more feedback and questions from LDAP testing:
>
> * During import of realm, do we want to add users just to local store or
> also to federation providers? Example: I've exported users from my realm
> and some are mapped to LDAP. Now I want to import them into different
> (clean) database, but during import, they are added into both local
> database and into LDAP where they already exists -> error.
> I wonder if we should skip adding users into FederationProviders at all
> (or at least have it configurable) wdyt?
>
IMO, Users shouldn't be registered with Federation Provider on an import.
great, created KEYCLOAK-600 . I have a fix already, but will push after
beta-4.
> * The small disadvantage of proxy objects are multiple calls to LDAP
> during single user registration. For example calling to:
>
> user.setFirstName(formData.getFirst("firstName"));
> user.setLastName(formData.getFirst("lastName"));
> user.setEmail(email);
>
> will actually perform 6 network calls to LDAP (each method call to
> WritableLDAPUserModelDelegate first checks if user exists and then doing
> full update of user). Do we care about this? LDAP is primarily designed
> for reading, so maybe writing from Keycloak won't be often anyway? I am
> not sure...
>
Fix for after beta-4. We can add a addUser(Map<string, string>
attriutes) method?
+1, I've created
https://issues.jboss.org/browse/KEYCLOAK-601 .
Hopefully it will help to reduce also number of SQL calls during user
registration. Because actually call to UserProvider.addUser(RealmModel
realm, String username) will insert user, but then there are additional
update call for setFirstName,setLastName, setEmail etc. Hopefully this
can be improved as well.
> * The semantics of "searchForUser" is a bit different for
> FederationProviders and our model implementations. For example, if you
> have user "John Doe" and you search for "ohn Do" in admin
console, then
> both JPA and Mongo local providers will return you "John Doe" as they
> add % at the beginning/end. However federation providers are looking
> exactly for FirstName: "ohn" , LastName: "Do", so if "John
Doe" exists
> in LDAP, he won't be returned.
>
Can we do anything about that? Does LDAP have a "like"?
yes, LDAP has *
. Workaround, which works for me is to put directly
search string like: *ohn Do* into admin console, but this is not pretty
and is LDAP specific though.
Marek
6:33 a.m.
On 5.8.2014 13:04, Marek Posolda wrote:
>> * The semantics of "searchForUser" is a bit
different for
>> >>FederationProviders and our model implementations. For example, if you
>> >>have user "John Doe" and you search for "ohn Do" in
admin console, then
>> >>both JPA and Mongo local providers will return you "John Doe"
as they
>> >>add % at the beginning/end. However federation providers are looking
>> >>exactly for FirstName: "ohn" , LastName: "Do", so if
"John Doe" exists
>> >>in LDAP, he won't be returned.
>> >>
> >Can we do anything about that? Does LDAP have a "like"?
yes, LDAP has * . Workaround, which works for me is to put directly
search string like:*ohn Do* into admin console, but this is not pretty
and is LDAP specific though.
btv. Found a typo when test ldap searching. Not sure
if it's ok to
commit at this stage, so just send PR for that
https://github.com/keycloak/keycloak/pull/590 .
Marek
7:43 a.m.
Added another commit for deleting of users on mongo . Both are one
liners and I hope they are quite safe to be included though.
Marek
On 5.8.2014 13:33, Marek Posolda wrote:
On 5.8.2014 13:04, Marek Posolda wrote:
>>> * The semantics of "searchForUser" is a bit different for
>>> >>FederationProviders and our model implementations. For example, if
you
>>> >>have user "John Doe" and you search for "ohn Do"
in admin console, then
>>> >>both JPA and Mongo local providers will return you "John
Doe" as they
>>> >>add % at the beginning/end. However federation providers are looking
>>> >>exactly for FirstName: "ohn" , LastName: "Do", so
if "John Doe" exists
>>> >>in LDAP, he won't be returned.
>>> >>
>> >Can we do anything about that? Does LDAP have a "like"?
> yes, LDAP has * . Workaround, which works for me is to put directly
> search string like:*ohn Do* into admin console, but this is not pretty
> and is LDAP specific though.
btv. Found a typo when test ldap searching. Not sure if it's ok to
commit at this stage, so just send PR for that
https://github.com/keycloak/keycloak/pull/590 .
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:02 a.m.
YOu find bugs, typos, etc. Fix them, you have until lunch my time
(eastern USA).
On 8/5/2014 8:43 AM, Marek Posolda wrote:
Added another commit for deleting of users on mongo . Both are one
liners and I hope they are quite safe to be included though.
Marek
On 5.8.2014 13:33, Marek Posolda wrote:
> On 5.8.2014 13:04, Marek Posolda wrote:
>>>> * The semantics of "searchForUser" is a bit different for
>>>> >>FederationProviders and our model implementations. For example,
if you
>>>> >>have user "John Doe" and you search for "ohn
Do" in admin console, then
>>>> >>both JPA and Mongo local providers will return you "John
Doe" as they
>>>> >>add % at the beginning/end. However federation providers are
looking
>>>> >>exactly for FirstName: "ohn" , LastName:
"Do", so if "John Doe" exists
>>>> >>in LDAP, he won't be returned.
>>>> >>
>>> >Can we do anything about that? Does LDAP have a "like"?
>> yes, LDAP has * . Workaround, which works for me is to put directly
>> search string like:*ohn Do* into admin console, but this is not pretty
>> and is LDAP specific though.
> btv. Found a typo when test ldap searching. Not sure if it's ok to
> commit at this stage, so just send PR for that
> https://github.com/keycloak/keycloak/pull/590 .
>
> Marek
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:09 a.m.
ok, merged. Found that oracle and mssql are broken, so looking at those
now:-(
I seem to have fix for oracle already, need to test a bit more and then
look at mssql...
On 5.8.2014 15:02, Bill Burke wrote:
YOu find bugs, typos, etc. Fix them, you have until lunch my time
(eastern USA).
On 8/5/2014 8:43 AM, Marek Posolda wrote:
> Added another commit for deleting of users on mongo . Both are one
> liners and I hope they are quite safe to be included though.
>
> Marek
>
> On 5.8.2014 13:33, Marek Posolda wrote:
>> On 5.8.2014 13:04, Marek Posolda wrote:
>>>>> * The semantics of "searchForUser" is a bit different for
>>>>> >>FederationProviders and our model implementations. For
example,
>>>>> if you
>>>>> >>have user "John Doe" and you search for "ohn
Do" in admin
>>>>> console, then
>>>>> >>both JPA and Mongo local providers will return you "John
Doe"
>>>>> as they
>>>>> >>add % at the beginning/end. However federation providers are
>>>>> looking
>>>>> >>exactly for FirstName: "ohn" , LastName:
"Do", so if "John Doe"
>>>>> exists
>>>>> >>in LDAP, he won't be returned.
>>>>> >>
>>>> >Can we do anything about that? Does LDAP have a "like"?
>>> yes, LDAP has * . Workaround, which works for me is to put directly
>>> search string like:*ohn Do* into admin console, but this is not
>>> pretty
>>> and is LDAP specific though.
>> btv. Found a typo when test ldap searching. Not sure if it's ok to
>> commit at this stage, so just send PR for that
>> https://github.com/keycloak/keycloak/pull/590 .
>>
>> Marek
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
9:09 a.m.
Thank god or you...I absolutely hate doing testing on different
databases (and LDAP servers for that matter). Do you have an easy way
to set up testing environments for these different dbs?
On 8/5/2014 9:09 AM, Marek Posolda wrote:
ok, merged. Found that oracle and mssql are broken, so looking at
those
now:-(
I seem to have fix for oracle already, need to test a bit more and then
look at mssql...
On 5.8.2014 15:02, Bill Burke wrote:
> YOu find bugs, typos, etc. Fix them, you have until lunch my time
> (eastern USA).
>
> On 8/5/2014 8:43 AM, Marek Posolda wrote:
>> Added another commit for deleting of users on mongo . Both are one
>> liners and I hope they are quite safe to be included though.
>>
>> Marek
>>
>> On 5.8.2014 13:33, Marek Posolda wrote:
>>> On 5.8.2014 13:04, Marek Posolda wrote:
>>>>>> * The semantics of "searchForUser" is a bit different
for
>>>>>> >>FederationProviders and our model implementations. For
example,
>>>>>> if you
>>>>>> >>have user "John Doe" and you search for
"ohn Do" in admin
>>>>>> console, then
>>>>>> >>both JPA and Mongo local providers will return you
"John Doe"
>>>>>> as they
>>>>>> >>add % at the beginning/end. However federation providers
are
>>>>>> looking
>>>>>> >>exactly for FirstName: "ohn" , LastName:
"Do", so if "John Doe"
>>>>>> exists
>>>>>> >>in LDAP, he won't be returned.
>>>>>> >>
>>>>> >Can we do anything about that? Does LDAP have a
"like"?
>>>> yes, LDAP has * . Workaround, which works for me is to put directly
>>>> search string like:*ohn Do* into admin console, but this is not
>>>> pretty
>>>> and is LDAP specific though.
>>> btv. Found a typo when test ldap searching. Not sure if it's ok to
>>> commit at this stage, so just send PR for that
>>> https://github.com/keycloak/keycloak/pull/590 .
>>>
>>> Marek
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:33 a.m.
So finally I seems to have a fix for MSSSQL and commited it. It
complained about Integer.MAX_VALUE in the query limit:-)
Oracle is fixed as well, it complained again about too long identifier
(there is limit for tableName, columnName and indexName to be max 30
characters).
I am also not enjoying testing with databases much. I am using jenkins
QA lab to access various databases and LDAP servers and I am able to
debug it locally with being connected to remote DB in QA lab, but
connection is quite slow and running single unit test took couple of
minutes. So it's a bit painfull...
For LDAP, I would need to update the automated tests for changes related
to FederationProvider vs. AuthenticationProviders and also fix some
stuff to setup automated test for Active Directory, which doesn't work
correctly ATM, so I am testing it manually.
I've tried to reproduce issue KEYCLOAK-602 reported by aerogear guys,
but wasn't successful. For me Keycloak WAR distribution deployed on EAP
6.3.0.Beta worked with MySQL 5.5.
I will try to update docs later in the evening (won't do more commits to
sources). Besides that there are some portal blockers, I am supposed to
look at, so not sure how I would be able to help you more with release
testing tomorrow:-(
Marek
On 5.8.2014 16:09, Bill Burke wrote:
Thank god or you...I absolutely hate doing testing on different
databases (and LDAP servers for that matter). Do you have an easy way
to set up testing environments for these different dbs?
On 8/5/2014 9:09 AM, Marek Posolda wrote:
> ok, merged. Found that oracle and mssql are broken, so looking at those
> now:-(
>
> I seem to have fix for oracle already, need to test a bit more and then
> look at mssql...
>
> On 5.8.2014 15:02, Bill Burke wrote:
>> YOu find bugs, typos, etc. Fix them, you have until lunch my time
>> (eastern USA).
>>
>> On 8/5/2014 8:43 AM, Marek Posolda wrote:
>>> Added another commit for deleting of users on mongo . Both are one
>>> liners and I hope they are quite safe to be included though.
>>>
>>> Marek
>>>
>>> On 5.8.2014 13:33, Marek Posolda wrote:
>>>> On 5.8.2014 13:04, Marek Posolda wrote:
>>>>>>> * The semantics of "searchForUser" is a bit
different for
>>>>>>> >>FederationProviders and our model implementations.
For example,
>>>>>>> if you
>>>>>>> >>have user "John Doe" and you search for
"ohn Do" in admin
>>>>>>> console, then
>>>>>>> >>both JPA and Mongo local providers will return you
"John Doe"
>>>>>>> as they
>>>>>>> >>add % at the beginning/end. However federation
providers are
>>>>>>> looking
>>>>>>> >>exactly for FirstName: "ohn" , LastName:
"Do", so if "John Doe"
>>>>>>> exists
>>>>>>> >>in LDAP, he won't be returned.
>>>>>>> >>
>>>>>> >Can we do anything about that? Does LDAP have a
"like"?
>>>>> yes, LDAP has * . Workaround, which works for me is to put directly
>>>>> search string like:*ohn Do* into admin console, but this is not
>>>>> pretty package org.keycloak.models;
>>>>>
>>>>> and is LDAP specific though.
>>>> btv. Found a typo when test ldap searching. Not sure if it's ok to
>>>> commit at this stage, so just send PR for that
>>>> https://github.com/keycloak/keycloak/pull/590 .
>>>>
>>>> Marek
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>
11:42 a.m.
On 8/5/2014 12:33 PM, Marek Posolda wrote:
So finally I seems to have a fix for MSSSQL and commited it. It
complained about Integer.MAX_VALUE in the query limit:-)
Oracle is fixed as well, it complained again about too long identifier
(there is limit for tableName, columnName and indexName to be max 30
characters).
I am also not enjoying testing with databases much. I am using jenkins
QA lab to access various databases and LDAP servers and I am able to
debug it locally with being connected to remote DB in QA lab, but
connection is quite slow and running single unit test took couple of
minutes. So it's a bit painfull...
For LDAP, I would need to update the automated tests for changes related
to FederationProvider vs. AuthenticationProviders and also fix some
stuff to setup automated test for Active Directory, which doesn't work
correctly ATM, so I am testing it manually.
I've tried to reproduce issue KEYCLOAK-602 reported by aerogear guys,
but wasn't successful. For me Keycloak WAR distribution deployed on EAP
6.3.0.Beta worked with MySQL 5.5.
I will try to update docs later in the evening (won't do more commits to
sources). Besides that there are some portal blockers, I am supposed to
look at, so not sure how I would be able to help you more with release
testing tomorrow:-(
I'll be releasing tonight.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
1:32 p.m.
Docs updated, that's finally all from me.
Marek
On 5.8.2014 18:49, Marek Posolda wrote:
Ok, will update docs asap.
On 5.8.2014 18:42, Bill Burke wrote:
> I'll be releasing tonight.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
6:57 a.m.
Hello,
I found a little bug when deploying to EAP 6.3.Beta and MySQL:
https://issues.jboss.org/browse/KEYCLOAK-602
This works fine with MySQL and JBossAS 7.1.1
I have also tested Postgres, and EAP 6.3.Beta - this works fine as well
-Matthias
On Mon, Aug 4, 2014 at 6:30 PM, Bill Burke <bburke(a)redhat.com> wrote:
Only merge of emergency/critical/blocker fixes please! I'm
finishing up
one last JIRA then I'll start testing for a release tomorrow Tuesday if
there are no problems.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
3797
days inactive
3798
days old
13 comments
3 participants
participants (3)
-
Bill Burke -
Marek Posolda -
Matthias Wessendorf