Re: [keycloak-dev] Custom attributes on registration and account management

+1 Bill already has dynamic validations in Authentication SPI, which is used just for registrations now. Wonder if SPI can be reused/enhanced somehow, so you can easily apply validation on all 3 places. And having the default validators based on mandatory attribute + regex and admin UI for define this. Hopefully something like we have for password policy (or OTP policy) can work for validators too. Marek On 06/11/15 15:23, Stian Thorgersen 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(a)redhat.com&gt; wrote: > Sure, if it's not a blocker for 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(a)redhat.com&gt; > mposolda(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > >