On Jan 30, 2012, at 3:05 PM, Christophe Laprun wrote:
On Jan 30, 2012, at 12:53 PM, Trong Tran wrote:
>
> On 27 January 2012 00:58, Christophe Laprun <claprun(a)redhat.com> 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
The question is more about what can we support as usernames at lower levels (i.e. POM or
JCR persistence). Our customers don't want a one-size-fits-all username: they want to
be able to define their own restrictions so this should be configurable instead of putting
arbitrary constraints on them. Whatever constraints we put in UsernameValidator will never
satisfy all our users.
JCR persistence with Chromattic takes care of encoding chars, so normally any valid char
should be valid (otherwise it's a bug).
However, if we do need some constraints because of persistence, XSS or other issues, we
need these restrictions to be clearly documented and that's what I'm currently
asking about. Our developers (whether they be eXo's or JBoss') need to know what
the low-level constraints are so that we don't break them with future updates and our
users/customers need to be made aware of them as well so that they can configure their own
restrictions accordingly. So, can someone from eXo please document these constraints
(since eXo seems to be the subject matter expert on this) so that we can move forward with
a configurable implementation of constraints?
can you tell me in what eXo did claim to be an expert on ?
Thanks in advance.
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