On Jan 26, 2012, at 6:58 PM, Christophe Laprun wrote: > Hi all, > > I'm currently working on https://issues.jboss.org/browse/GTNPORTAL-1673 and I'm quite puzzled by the different rules that are in place to validate usernames. Not only are these rules not consistent across fields which display usernames (some are validated using UsernameValidator, some are validated using ExpressionValidator) but I'm also confused about the need to validate read-only fields (which presumably will only display valid information since it doesn't come from the user, right?). What are the rules for a valid username and where are they documented? What are the restrictions and why are they in place? > - Trong should answer those questions when he comes back from the Tet (Vietnam new year) next monday.

> The second issue is that some of our users (rightly) want to validate user names according to their own rules instead of arbitrary and opaque rules that we impose on them for reasons that are entirely too unclear to me and probably to our users. To address this issue, I need to find a way to dynamically inject validators for some of the fields based on user-definable configuration. I'm currently thinking about using a service that would be initialized by the kernel and take its configuration from ${gatein.conf.dir}. Any opposition to this design? Any better idea? 1/ I have no a priori idea about it except that at some point this should use Bean Validation API. Do you needs require to introduce new Java classes or interfaces considered as public or is it all declarative ? if yes we should not try to overlap with what BV provides and try to reuse the whole or a part of the API.

2/ what is your target with respect to GateIn 3.2 forthcoming release ?

3/ you can write a specification to formulate the needs and define a solution

On Jan 27, 2012, at 10:58 AM, Christophe Laprun wrote: > On Jan 26, 2012, at 7:51 PM, Julien Viet wrote: > >> On Jan 26, 2012, at 6:58 PM, Christophe Laprun wrote: >> >>> Hi all, >>> >>> I'm currently working on https://issues.jboss.org/browse/GTNPORTAL-1673 and I'm quite puzzled by the different rules that are in place to validate usernames. Not only are these rules not consistent across fields which display usernames (some are validated using UsernameValidator, some are validated using ExpressionValidator) but I'm also confused about the need to validate read-only fields (which presumably will only display valid information since it doesn't come from the user, right?). What are the rules for a valid username and where are they documented? What are the restrictions and why are they in place? >>> >> - Trong should answer those questions when he comes back from the Tet (Vietnam new year) next monday. > OK. > >>> The second issue is that some of our users (rightly) want to validate user names according to their own rules instead of arbitrary and opaque rules that we impose on them for reasons that are entirely too unclear to me and probably to our users. To address this issue, I need to find a way to dynamically inject validators for some of the fields based on user-definable configuration. I'm currently thinking about using a service that would be initialized by the kernel and take its configuration from ${gatein.conf.dir}. Any opposition to this design? Any better idea? >> 1/ I have no a priori idea about it except that at some point this should use Bean Validation API. Do you needs require to introduce new Java classes or interfaces considered as public or is it all declarative ? if yes we should not try to overlap with what BV provides and try to reuse the whole or a part of the API. > I was thinking about Bean Validation but there are several issues with this: > 1. It would mean changing completely the validation architecture of WebUI, which would be a significant undertaking. > 2. While we're still stuck with EE 5, this means an added dependency > 3. I'm not familiar with it yet ;) you are already talking about serious changes (introducing a new API, a new service, a new configuration). our point of view is that we should not take an intermediate path and instead either 1/ we minimize the changes and answer the initial case asked "make UI validation regular expressions configurable by users" .

2/ we make it the proper way avoiding to develop a feature that will be not thrown away in 6 months.

>> 2/ what is your target with respect to GateIn 3.2 forthcoming release ? > Target is customer need for EPP 5.2.1 so probably GateIn 3.2 (depending on timing of the 3.2 release). GateIn 3.2 has been postponed for months now, we wanted to have a release early Janueary. How many weeks are we considering to postpone it ?

>> 3/ you can write a specification to formulate the needs and define a solution > The ideal solution would probably be using Bean Validation, though, again, I need to look at it some more. The needs are fairly simple, our customers don't like to be arbitrarily restricted by what *we* think a username should be, so they want to be able to change the username validation. This actually extends to other parts of the portal as Marko as already shown with portal names. Basically, we currently put restrictions on theses things but: > 1. theses restrictions are not documented anywhere > 2. they don't necessarily fit with our users' needs and should therefore be configurable In any case I want this to be specified in a document called "specification" in which we define the functional and technical part. > Cordialement / Best, > Chris > > == > Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. > Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein > Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm > _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On Jan 27, 2012, at 12:50 PM, Julien Viet wrote: >> I was thinking about Bean Validation but there are several issues with this: >> 1. It would mean changing completely the validation architecture of WebUI, which would be a significant undertaking. >> 2. While we're still stuck with EE 5, this means an added dependency >> 3. I'm not familiar with it yet ;) > > you are already talking about serious changes (introducing a new API, a new service, a new configuration). > > our point of view is that we should not take an intermediate path and instead either > > 1/ we minimize the changes and answer the initial case asked "make UI validation regular expressions configurable by users" . Answering the initial case minimally requires a new configuration and a new service to read it in and pass it to the validation architecture, unless there's a magic way to pass the regular expression to the current implementation without having to introduce these new elements that I'm not aware of… :) Note that the service doesn't need to be exposed to users but I currently don't know any other way to read the configuration file and pass the data to the validators. Note also that the username is not currently validated by a regular expression but rather by hardcoded rules in UsernameValidator in the spot that matters (i.e. where users can input data), though it is validated by regexp in some spots but validation seems unneeded (read-only elements). So there are really 3 elements to address here: 1. which is the proper validation for usernames (I'm currently thinking the proper way is the UsernameValidator implementation)? 2. can we change these validation rules without breaking anything? 3. how do we make it so that users can change these rules without breaking anything? > 2/ we make it the proper way avoiding to develop a feature that will be not thrown away in 6 months. Matter of priorities I guess… Not my place to decide on this. >>> 2/ what is your target with respect to GateIn 3.2 forthcoming release ? >> >> Target is customer need for EPP 5.2.1 so probably GateIn 3.2 (depending on timing of the 3.2 release). > > GateIn 3.2 has been postponed for months now, we wanted to have a release early Janueary. How many weeks are we considering to postpone it ? I'm not in charge of the schedule and I have no idea when GateIn 3.2 is supposed to be released. Also, this is a feature targeted at EPP 5.2.1, a solution has to be decided on and implemented quickly, unless a fix is deemed too risky for a dot-dot release. >>> 3/ you can write a specification to formulate the needs and define a solution >> >> The ideal solution would probably be using Bean Validation, though, again, I need to look at it some more. The needs are fairly simple, our customers don't like to be arbitrarily restricted by what *we* think a username should be, so they want to be able to change the username validation. This actually extends to other parts of the portal as Marko as already shown with portal names. Basically, we currently put restrictions on theses things but: >> 1. theses restrictions are not documented anywhere >> 2. they don't necessarily fit with our users' needs and should therefore be configurable > > In any case I want this to be specified in a document called "specification" in which we define the functional and technical part. It goes both ways: I'd like the specifications for the current implementation and I'm sure Marko would like the specification for the portal name restrictions as well. I'm pretty sure our users would like to know this information as well. Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm

On Jan 27, 2012, at 2:04 PM, Julien Viet wrote: > looking in webui there is already a configuration for validation in the package org.exoplatform.webui.config. > > The class org.exoplatform.webui.config.Component class has a list of validators associated with it, each validator has an InitParams objects. > > This can be loaded from XML, a sample is visible there http://anonsvn.jboss.org/repos/gatein/portal/trunk/webui/core/src/test/re... it contains among other: > > <validators> > <validator> > <type>class.name</type> > <init-params> > <param><name>name</name><value>value</value></param> > </init-params> > </validator> > </validators> Good to know, I will look into it. > The class we want to make configured externally is the class UIGroupMembershipForm. I actually don't think that's the only place. See for example UIAccountInputSet, UIAccountProfiles, UIRegisterInputSet, UIAccountEditInputSet and possibly others. There are way too many spots where usernames are dealt with and they are not dealt with in a consistent way. https://issues.jboss.org/browse/GTNPORTAL-2186 changed some of the validation process in some spots but didn't in other for unknown reasons. Regardless of what is being done with the configuration aspects of the validation, a rational validation process for usernames (and other important data) needs to be put in place. > I foresee two steps to investigate > > 1/ we should try to see if we can first remove the validation hardcoded in UIGroupMembershipForm and instead use XML. > 2/ we should find a way to make this configuration overridden externally with additional configuration in conf directory. I will investigate these issues but we need to think about cleaning up the validation of data more deeply.

On 27 January 2012 00:58, Christophe Laprun <claprun(a)redhat.com&gt; wrote: Hi all, I'm currently working on https://issues.jboss.org/browse/GTNPORTAL-1673 and I'm quite puzzled by the different rules that are in place to validate usernames. Not only are these rules not consistent across fields which display usernames (some are validated using UsernameValidator, some are validated using ExpressionValidator) but I'm also confused about the need to validate read-only fields (which presumably will only display valid information since it doesn't come from the user, right?). What are the rules for a valid username and where are they documented? What are the restrictions and why are they in place? Defining the rules for a valid username is a long story, they have been changed/updated many times according to users need. They are also not fixed and documented so far. Until now, we still have requests related to this like : to support case-sensitive, or possible to add username under an email address. Anyway the rules should be consistent every places and no need to validate read-only fields, they are considered as issues

On 27 January 2012 00:58, Christophe Laprun <claprun(a)redhat.com&gt; wrote: Hi all, I'm currently working on https://issues.jboss.org/browse/GTNPORTAL-1673 and I'm quite puzzled by the different rules that are in place to validate usernames. Not only are these rules not consistent across fields which display usernames (some are validated using UsernameValidator, some are validated using ExpressionValidator) but I'm also confused about the need to validate read-only fields (which presumably will only display valid information since it doesn't come from the user, right?). What are the rules for a valid username and where are they documented? What are the restrictions and why are they in place? Defining the rules for a valid username is a long story, they have been changed/updated many times according to users need. They are also not fixed and documented so far. Until now, we still have requests related to this like : to support case-sensitive, or possible to add username under an email address. Anyway the rules should be consistent every places and no need to validate read-only fields, they are considered as issues

I'm available here to discuss and still listening your voice :) we can see that the most restriction is about how to allow our users to be able to customize rules of a valid username ( the others are not hard to achieve indeed ). To get this done, I think the approach of using a kernel service for injecting validator seems to be acceptable. it helps users easier to change the rules without modifying anything in war. It should not be risky as we are just trying to fix problems and make it more flexible. I'm also going to document the current rules of username for reference ( tomorrow i think ) On 31 January 2012 17:26, Boleslaw Dawidowicz <boleslaw.dawidowicz(a)gmail.com&gt; wrote: On Jan 30, 2012, at 12:53 PM, Trong Tran wrote: > > On 27 January 2012 00:58, Christophe Laprun <claprun(a)redhat.com&gt; wrote: > Hi all, > > I'm currently working on https://issues.jboss.org/browse/GTNPORTAL-1673 and I'm quite puzzled by the different rules that are in place to validate usernames. Not only are these rules not consistent across fields which display usernames (some are validated using UsernameValidator, some are validated using ExpressionValidator) but I'm also confused about the need to validate read-only fields (which presumably will only display valid information since it doesn't come from the user, right?). What are the rules for a valid username and where are they documented? What are the restrictions and why are they in place? > > Defining the rules for a valid username is a long story, they have been changed/updated many times according to users need. They are also not fixed and documented so far. Until now, we still have requests related to this like : to support case-sensitive, or possible to add username under an email address. > > Anyway the rules should be consistent every places and no need to validate read-only fields, they are considered as issues I understand that due to the long story of changes it is rather hard to come up with consistent list. However we need to decide on some plan to fix the situation and agree if it is possible and safe to do it now. Trong, who do you think should be involved to get more clear picture about reasons for current restrictions? If we decide that it is too risky to loosen them now thats also quite valid outcome. Bolek -- Tran The Trong eXo Platform SEA _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

Simplest way to do it, to me, is as follows: - Identify where user names are validated in the current code. Remove unneeded validation (in particular where it processes read-only data). - Replace all instances of validators in all places we want users to configure username validation by a single UserConfigurableUsernameValidator. - Implement a simple service that will look for a configuration file in gatein.conf.dir to allow users to define which regular expression should be used (as well as other parameters as we see fit, e.g. min and max length). If no such configuration is found, use the default logic as it currently exists in UsernameValidator. - Have instances of UserConfigurableUsernameValidator gets their configuration from that service. - Optionally, add a user interface in the admin part of the portal to do this configuration from within portal. I think this solution will require the minimal amount of risk/work and still achieve our goals of user configurable validation of user names without added complexity. On Jan 31, 2012, at 1:22 PM, Julien Viet wrote: > I want this to be done with the existing webui metadata objects, i.e the org.exoplatform.webui.application.ConfigurationManager objects takes care of getting the override and override the Validator configuration and then let webui construct the validator from the metadata defined by the org.exoplatform.webui.config.Component class. > > it implies also that the ui component that we want to have pluggable validation should not hardcode the definition and instead define default validation using the annotation and not the programmatic manner. > > On Jan 31, 2012, at 12:21 PM, Trong Tran wrote: > >> I'm available here to discuss and still listening your voice :) >> >> we can see that the most restriction is about how to allow our users to be able to customize rules of a valid username ( the others are not hard to achieve indeed ). To get this done, I think the approach of using a kernel service for injecting validator seems to be acceptable. it helps users easier to change the rules without modifying anything in war. It should not be risky as we are just trying to fix problems and make it more flexible. >> >> I'm also going to document the current rules of username for reference ( tomorrow i think ) >> >> >> On 31 January 2012 17:26, Boleslaw Dawidowicz <boleslaw.dawidowicz(a)gmail.com&gt; wrote: >> >> On Jan 30, 2012, at 12:53 PM, Trong Tran wrote: >> >>> >>> On 27 January 2012 00:58, Christophe Laprun <claprun(a)redhat.com&gt; wrote: >>> Hi all, >>> >>> I'm currently working on https://issues.jboss.org/browse/GTNPORTAL-1673 and I'm quite puzzled by the different rules that are in place to validate usernames. Not only are these rules not consistent across fields which display usernames (some are validated using UsernameValidator, some are validated using ExpressionValidator) but I'm also confused about the need to validate read-only fields (which presumably will only display valid information since it doesn't come from the user, right?). What are the rules for a valid username and where are they documented? What are the restrictions and why are they in place? >>> >>> Defining the rules for a valid username is a long story, they have been changed/updated many times according to users need. They are also not fixed and documented so far. Until now, we still have requests related to this like : to support case-sensitive, or possible to add username under an email address. >>> >>> Anyway the rules should be consistent every places and no need to validate read-only fields, they are considered as issues >> >> I understand that due to the long story of changes it is rather hard to come up with consistent list. However we need to decide on some plan to fix the situation and agree if it is possible and safe to do it now. >> >> Trong, who do you think should be involved to get more clear picture about reasons for current restrictions? If we decide that it is too risky to loosen them now thats also quite valid outcome. >> >> Bolek >> >> >> >> >> -- >> Tran The Trong >> eXo Platform SEA >> _______________________________________________ >> gatein-dev mailing list >> gatein-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/gatein-dev > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm

On Jan 31, 2012, at 2:36 PM, Julien Viet wrote: > I would like to avoid the creation of a service only for this purpose / scope. > > can you avoid this part and make it more straightforward ? I guess UserConfigurableUsernameValidator could parse the configuration file directly, assuming it's possible to retrieve the gatein.conf.dir value from that part of the code.

Since I haven't heard anything more on the implementation I provided yesterday, I will consider the solution as satisfactory and go ahead with the changes needed to use the new validator. Note that the new validator defaults to the old behavior if no user configuration is found. On Jan 31, 2012, at 4:50 PM, Christophe Laprun wrote: > > On Jan 31, 2012, at 2:41 PM, Christophe Laprun wrote: > >> >> On Jan 31, 2012, at 2:36 PM, Julien Viet wrote: >> >>> I would like to avoid the creation of a service only for this purpose / scope. >>> >>> can you avoid this part and make it more straightforward ? >> >> I guess UserConfigurableUsernameValidator could parse the configuration file directly, assuming it's possible to retrieve the gatein.conf.dir value from that part of the code. > > Simple implementation is done: https://source.jboss.org/changelog/GateIn?cs=8330 > > Now, we would just need to use it where needed. I tested that it works, the only problem, which also occurs for ExpressionValidator, is that if the value doesn't match the pattern, then the error message needs to output a format. The default is using the pattern String but that doesn't work very well with HTML output… > > Cordialement / Best, > Chris > > == > Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. > Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein > Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm > > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm

and I think we should make it part of the existing configuration with proper prefixing in a dedicated section.

however for the case we need to avoid case like "minLength" and stick to lower case (except the mistake that was done for gatein.email.smtp.*).

On Feb 1, 2012, at 3:35 PM, Christophe Laprun wrote: > > On Feb 1, 2012, at 2:51 PM, Julien Viet wrote: > >> and I think we should make it part of the existing configuration with proper prefixing in a dedicated section. > > The point of having a dedicated configuration file is that: > 1. it's easy to change for users as they don't risk messing up the rest of the configuration > 2. it's faster to load since it doesn't need to load things that have nothing to do with the specific configuration we're interested in > 3. it doesn't pollute the more important configuration by avoiding putting the validation configuration there when it's likely going to be removed when we switch to Bean Validation (which I understand is the long term goal). The main configuration.properties file should be used for "vital" configuration things, not optional ones, in my opinion. > 4. it's easier to check whether the default behavior can be used or not (otherwise, need to check that *all* the possible configuration keys are missing) > > That said, if people think it's better to put it in the configuration.properties file, I'll change the implementation accordingly. We keep a single file that is the place where you will find any configuration property. We thought about modularizing at some point, but not according to the function but instead to the scope of the property (admin, dev). > >> however for the case we need to avoid case like "minLength" and stick to lower case (except the mistake that was done for gatein.email.smtp.*). > > Is there a point to using only lower case (apart from consistency with the other keys, which will not be an issue if the configuration is made in a separate file)? consistency matters, it's not only narcissistic and assumed, it also allows one to not wonder if a letter of a property should be upper or lower case, it is just lower case. it should be used whenever we define a property name (configuration file, runtime properties like <qname xmlns:prp='http://www.gatein.org/xml/ns/prp_1_0'>prp:navigatio...;, etc...). > > Cordialement / Best, > Chris > > == > Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. > Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein > Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm >

I'm available here to discuss and still listening your voice :) we can see that the most restriction is about how to allow our users to be able to customize rules of a valid username ( the others are not hard to achieve indeed ). To get this done, I think the approach of using a kernel service for injecting validator seems to be acceptable. it helps users easier to change the rules without modifying anything in war. It should not be risky as we are just trying to fix problems and make it more flexible. I'm also going to document the current rules of username for reference ( tomorrow i think )

I just created documentation JIRA issue for username validation https://issues.jboss.org/browse/GTNPORTAL-2345. All current rules are described in Description part

On Feb 2, 2012, at 12:09 PM, Christophe Laprun wrote: > > On Feb 2, 2012, at 9:11 AM, Trong Tran wrote: > >> I just created documentation JIRA issue for username validation https://issues.jboss.org/browse/GTNPORTAL-2345. All current rules are described in Description part > > Thank you. However, I would like to know the reason behind these rules (as I could infer them reading the code for UsernameValidator). My original question was more about why these rules are in place as opposed to what are they. In particular, are these rules needed by other GateIn and/or eXo components? Can we remove all these rules without issues? Trong thanks for the start however Chris is right - we need to provide some context also. I understand that it can be hard to track all requirements but if we provide users configuration capabilities they need some clear info if those are hard constraints or not. Basically we need to agree if putting less restrictive validation can cause issues on JCR/DB level or not. What do you think? Bolek

wrote:

On Feb 2, 2012, at 12:09 PM, Christophe Laprun wrote: > > On Feb 2, 2012, at 9:11 AM, Trong Tran wrote: > >> I just created documentation JIRA issue for username validation https://issues.jboss.org/browse/GTNPORTAL-2345. All current rules are described in Description part > > Thank you. However, I would like to know the reason behind these rules (as I could infer them reading the code for UsernameValidator). My original question was more about why these rules are in place as opposed to what are they. In particular, are these rules needed by other GateIn and/or eXo components? Can we remove all these rules without issues? Trong thanks for the start however Chris is right - we need to provide some context also. I understand that it can be hard to track all requirements but if we provide users configuration capabilities they need some clear info if those are hard constraints or not. Basically we need to agree if putting less restrictive validation can cause issues on JCR/DB level or not. What do you think?

On Feb 3, 2012, at 6:04 AM, Trong Tran wrote: > On 2 February 2012 21:22, Boleslaw Dawidowicz < boleslaw.dawidowicz(a)gmail.com&gt; wrote: > > On Feb 2, 2012, at 12:09 PM, Christophe Laprun wrote: > > > > > On Feb 2, 2012, at 9:11 AM, Trong Tran wrote: > > > >> I just created documentation JIRA issue for username validation https://issues.jboss.org/browse/GTNPORTAL-2345. All current rules are described in Description part > > > > Thank you. However, I would like to know the reason behind these rules (as I could infer them reading the code for UsernameValidator). My original question was more about why these rules are in place as opposed to what are they. In particular, are these rules needed by other GateIn and/or eXo components? Can we remove all these rules without issues? > > Trong thanks for the start however Chris is right - we need to provide some context also. I understand that it can be hard to track all requirements but if we provide users configuration capabilities they need some clear info if those are hard constraints or not. Basically we need to agree if putting less restrictive validation can cause issues on JCR/DB level or not. What do you think? > > I can't remember exactly why these rules are in place. The reasons I can see in my mind now are : > > - It bases on *common* rules used in most of websites > - Some are needed for eXo components. For instance, username must be in lower cases and it is needed for eXo Chat feature which requires username in case-insensitive. Why is it the case? Again, where are these rules documented?

> - I'm not sure but I don't think JCR/DB level is the issue. Even if yes, we could handle it somehow in particular Organization service implementation by itself > > Personally I do think we can put less restriction as long as they are reasonable, users configuration capabilities and documented. The other parts could adapt somehow to be suitable with new rules. The problem is that there won't be any "new" rules: users will be allowed to choose whatever user name format they want unless there are some valid reasons not to do so. However, since there aren't currently any documentation as to what a valid user name is, it will be up to components to make sure they can work with arbitrary user names. Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm