[keycloak-dev] Custom attributes on registration and account management
Marek Posolda
mposolda at redhat.com
Fri Nov 6 09:29:12 EST 2015
+1
On 06/11/15 15:23, Stian Thorgersen wrote:
> Password policies needs to be made into an SPI as well
>
> On 6 November 2015 at 15:23, Stian Thorgersen <sthorger at redhat.com
> <mailto:sthorger at redhat.com>> wrote:
>
> You're right validation is required now. I feel a new Validation
> SPI coming up?
>
> On 6 November 2015 at 15:21, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
>
> Sure, if it's not a blocker for jboss.org <http://jboss.org>
> team to not have it in 1.0 ? I guess dynamic templates can be
> postponed, but at least missing validation for account mgmt
> and update profile is quite a gap IMO.
>
> I've discussed this with Vlasta a week or two ago (and that's
> one of main reasons to write this email btv :-) )
>
> Marek
>
>
> On 06/11/15 15:04, Stian Thorgersen wrote:
>> I think this is something to look at next year. We don't have
>> the resources to do it properly now. My vote is to add it to
>> the agenda for F2F.
>>
>> On 6 November 2015 at 14:36, Marek Posolda
>> <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>
>> On 05/11/15 17:11, Bill Burke wrote:
>> >
>> > On 11/5/2015 5:46 AM, Marek Posolda wrote:
>> >> I wonder if we should improve handling of custom
>> attributes in
>> >> freemarker templates and their validation. Let's
>> assume that I want to
>> >> add custom attribute "birthday" and I want to add it
>> to all screens
>> >> where user can create/edit account. I can see those
>> issues:
>> >>
>> >> - Admin will need to edit 3 separate freemarker
>> templates (registration,
>> >> account management, update profile page) to have this
>> attribute
>> >> displayed on all those places.
>> >>
>> > we've discussed this before. The problem is formatting
>> in each of the
>> > UIs. Often ordering of attributes is important.
>> Grouping of attributes
>> > is a must too.
>> >
>> > i.e. Address, State, Country, Postal Code
>> >
>> > These 4 attribute must be grouped together, and address
>> must come before
>> > state, and so on.
>> >
>> > You might also have a "Billing Address" group that
>> needs to come after
>> > Home Address group.
>> I am not seeing an issue with ordering? The same order
>> you configure in
>> admin console, the same is used in template. It's classic
>> sorted list,
>> not special tricks needed IMO. The grouping some
>> attributes can be
>> easily addressed too IMO.
>> >
>> > So, we'd have an automatic way for displaying
>> attributes, then the
>> > developer would think "that looks like shit" and want
>> to format things
>> > himself. Stian seems to think that CSS will solve this
>> problem, but I'm
>> > not convinced.
>>
>>
>> CSS can do a hell of a lot more than you think it can ;)
>>
>> But, I agree it can't always cover everything - that's why
>> I've been saying we need to be able to define templates, but
>> at a smaller granularity. Having to define the whole
>> update-profile page just to add an attribute is not very elegant.
>>
>> I agree we can't address all possible sort of issues, but
>> IMO it's good
>> to have something, which will address 90% of cases? We
>> can provide types
>> (like combobox "Gender" with values "male" / "female" ).
>> We can also
>> handle multivalued attributes. And most importantly we
>> can provide
>> validations for all 3 screens. People won't need to write
>> their own Java
>> validators when they want something simple like ensure
>> "mandatory" field
>> present or validate with regex. They will still have
>> possibility to
>> inject the custom validator if they want it.
>>
>> At least validation is must IMO as there is no way to add
>> custom
>> validation for account mgmt or update profile right now.
>>
>> What we can't easily do is client-side validation and
>> stuff for
>> display/hide something based on value of other attributes
>> (For example
>> display attribute "Favourite car sign" just if selected
>> gender is "male"
>> ). But not sure if this is often requirement.
>>
>> I am seeing lot of similarity with your
>> kc-provider-config directive in
>> admin console. It can't address all "generic" sort of
>> things and
>> client-side stuff etc. But for most cases, it's sufficient.
>> >
>> > Also the look and feel could be quite different between
>> registration,
>> > update profile, account management, and the admin
>> profile. IMO, it
>> > would end up being easier to just edit the freemarker
>> pages directly
>> > than to have to define each attribute and how it is
>> grouped, ordered,
>> > and displayed on each of the pages within an admin
>> console UI.
>> >
>> >
>> There could be 3 checkboxes where can admin select if he
>> wants to add
>> field on registration, account mgmt and update profile. I
>> am not sure if
>> we need anything for admin console as we already have
>> "Attributes" tab
>> for users, which is almost ok IMO (we don't have nice
>> solution for
>> multivalued attributes).
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151106/c706ece1/attachment-0001.html
More information about the keycloak-dev
mailing list