Username restrictions?
by Christophe Laprun
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?
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?
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
12 years, 2 months
Change to WCI registration proposal
by Matt Wringe
There have been a couple of issues arising from the ordering of portlets
and servlets being out of sync. For example see
https://issues.jboss.org/browse/GTNPC-76
This isn't really a bug, since the ordering of when portlets and
servlets are initialized is not suppose to be guaranteed. But I have a
couple of changes to wci which will allow for this behaviour (see patch
attached to GTNPC-76)
Basically there are 2 new features which when used together will provide
ordering between portlets and servlets.
1) by using a context-parameter in the web.xml, we can tell the native
wci implementation to not register the specific webapp.
2) you can now manually add an application to the wci native
implementation.
To control ordering:
- add in the context-parameter so the native implementation doesn't
register the webapplication (and therefor PC doesn't know about it)
- specify the generic GateInServlet in the web.xml and use the
load-on-startup value to control ordering against other servlets. The
GateInServlet will manually register itself to the native
implementation.
Any objections?
12 years, 2 months
Issues with static resources
by Marek Posolda
Hi,
I think that it's not ideal how WebAppController processes static
resources like images. I have 2 things to point out:
1) Today I found (and fixed) a bug that images are first processed by
PortalRequestHandler, even if they should be processed by
StaticResourceRequestHandler. Please look at
https://issues.jboss.org/browse/GTNPORTAL-2338 for more details. This is
really not good because HTTP header "Cache-Control: no-cache" is
returned for every image, and so web browser needs to download images
for each HTTP request to portal. I fixed it by adding
StaticResourceRequestHandler before PortalRequestHandler into
navController configuration, so it should not be the issue anymore.
2) Second thing is not so bad but a bit more tricky. The piece of code
in WebAppController:
{code}
if (!started)
{
RequestLifeCycle.begin(ExoContainerContext.getCurrentContainer());
started = true;
}
.....
processed = handler.execute(new ControllerContext(this,
router, req, res, parameters));
.....
if (started)
{
RequestLifeCycle.end();
}
{code}
This means that we need to start RequestLifeCycle for processing of
every resource including static resource. And startup of some services
is quite expensive (like startup of OrganizationService requires startup
of Hibernate transaction). In other words, currently we are starting
Hibernate transaction for processing images and other static resources.
It's obvious that some handlers (PortalRequestHandler,
LegacyRequestHandler and probably some others) really need to start
RequestLifecycle, but some others like StaticResourceRequestHandler
don't need it. So how about postponing the RequestLifecycle.begin from
WebAppController to concrete handlers, which really need it? And use
some ThreadLocal variable or flag "started" on ControllerContext, so
that we can track if RequestLifeCycle.begin has been already started
(can be useful to avoid double-start if some resource needs to be
processed by more request handlers) ?
Any other suggestions for this?
Marek
12 years, 2 months
Allow shorter portal names?
by Marko Strukelj
There are some portal users that find a portal name limitation of minimum
length of three, and starting with a letter (IdentifierValidator) too
restraining.
For example there is issue JBEPP-885<https://issues.jboss.org/browse/JBEPP-885>
.
Some internal debate on the topic exposed some deeper issues here ...
There are special contexts like 'g' (http://localhost:8080/portal/g/), and
'u'. Allowing portal names one char long could produce name collisions with
these.
On the other hand there are some other 'special' contexts like those mapped
via web.xml: 'javascript', 'error', 'initiatelogin', 'errorlogin', 'login',
'dologin', 'rest', 'connector', 'gateinservlet', 'private', 'admin'.
And I hear there are some others: 'download', 'upload', 'public'. Not sure
if these are supposed to occur at portal site level, or page level.
The point is that while there's some validation in place when adding new
portal through admin UI, it seems a bit arbitrary - like why should a
portal name not start with a digit, and what collition can happen at length
== two? And we already have a name collision problem with names longer than
two as mentioned above.
To try if things would explode I loosened up the criteria, and created a
portal called 1A, and things seem to keep working fine.
It seems like loosening criteria to length >= 2, and 'can start with a
digit' could easily be done, and give a little more freedom to users.
But we should also think about improving things as they already are by
maybe adding checks for site name against a list of reserved words for
example.
We could probably compile the web.xml url mappings programmatically, but
that would not be an exhaustive list. Maybe we could manually collect all
these special contexts into an exhaustive list, make it available through
some service. That would still not prevent possible post-festum collisions
if we introduce new 'special' context mappings in the future - they might
all collide retroactively.
Some other sources of collision that came up include:
- language mapping URLs - i.e. http://localhost:8080/portal/fr/... but I
don't know if that kind of urls are actually used anywhere
- navigation controller - does it only work relative to portal site or
can it override mapping for portal site name as well?
- new additions via navigation.xml could clash with existing MOP nodes -
how to react in that case? Navigation controller automatically overrides
MOP with some warning?
Similarly, we could loosen up page naming - there, navigation controller
would definately be part of an equation. We could dynamically compile
'taken' names from NavigationController ...
Another question is then how to deal with name collision when we detect
them? We could detect them at GateIn startup time, or when adding a site or
page through Site administration UI. We can disallow creation of
conflicting name. That makes sense for portal names that conflict with
mapped web.xml contexts. We could also just warn a user that name is in
conflict, and the portal / page won't be reachable, but allow creation
itself.
I imagine there are some other considerations that I can't see ATM.
Maybe someone can shed additional light on this, or add an opinion ...
- marko
12 years, 3 months