RE: How to create a custom profiling rule?
Sorry to bother you all with this again...
Ok, after I've done all these changes, I found a new
problem as well:
no links (*.link files) are displayed on either of the
pages, for neither of the users.
I tried placing them in the / and /dce-portal
directory, but still nothing is displayed.
Is this a problem with my new profiling rule?
What determines whether links are displayed or not?
Thanks!
Marina
--- Marina [EMAIL PROTECTED] wrote:
Randy,
thanks for your help. You are probably right and I
made it more complicated than what it should be.
Basically, what I would like to have in my portal
is:
1. all application-specific portal pages/ docsets/
links should be in a separate directory, say,
.../pages/dce-portal/
2. users ('dce-user', 'dce-admin') with the
'dce-user-role' should be able to see one main page,
dce-main-page.psml, and one additional page as a
tab,
dce-users-page.psml. Both .psml pages are in the
.../pages/dce-portal/ directory
3. a generic (non-logged in, 'guest') user should
see
the ../pages/dce-portal/dce-main-page.psml, and
nothing else
So, to accomplish this, I have created this custom
profiling rule:
insert into PROFILING_RULE values ('dce-generic',
'org.apache.jetspeed.profiler.rules.impl.StandardProfilingRule',
'rule for non-logged in DCE portal users')
insert into RULE_CRITERION values ('100',
'dce-generic', 0, 'path', 'path', '/dce-portal', 0)
and assigned it to the 'guest', 'dce-user' and
'dce-admin' users.
This made all pages visible to these three users. To
restrict access to the user-specific page to the
users
with the 'dce-user-role' role, I've added the
following security constraints to the
dce-users-page.psml:
security-constraint
rolesdce-user-role/roles
permissionsview/permissions
/security-constraint
Well, that did work. With the exception of those
problems I mentioned in my previous post (one of
them
was fixed by using #if($site.rootLinks.isEmpty()) as
David suggested)
So, the only problem that is still left is inclusion
of the .ds sets from the '/' directory. I would
rather
like to use the ../pages/dce-portal/ as the root
directory, but my profiling rule does not seem to
accomplish this.
I hope I'm being clear :)
And thanks a lot for looking into this!
Marina
--- Randy Watler [EMAIL PROTECTED] wrote:
Marina,
Using the Profiler effectively is more in my
court,
so let's see if I can
help here.
I think there are three subjects here that need
individual attention:
1. you probably do not need to define a new
profiling rule... there are some
predefined rules that you can use to achieve
role-based profiling,
2. the demo site is just that and you should start
with a clean
WEB-INF/pages directory only adding in what you
need
from the demo site, and
3. the tigris sample decorator is a good starting
place, but most everyone
ends up customizing and deploying their own
flavor.
So, rather than trying to figure out what you have
now, I would like to know
what your objective is. I'll then tell you how I'd
solve it using the M1
release version. We can then compare notes and
take
it from there... ok?
Randy
-Original Message-
From: Marina
To: Jetspeed Users List
Sent: 12/30/04 1:26 PM
Subject: Re: How to create a custom profiling
rule?
David,
Thanks for the clarification. I did find a way to
do
role-based profiling, basically, by restricting
access
to specific PSML pages by roles.
I still have a few problems I was not able to
solve
so
far. The main one is that I still get some
elements
from the '/' directory included into my pages,
even
though I explicitly specified in my profiling rule
that only elements from a specific directory
should
be
used. I think I made some stupid mistakes while
creating custom profiling rules...
Here is how I setup my portal's content and
created
a
new profiling rule using direct SQL (I don't think
it
is possible to that through the Admin portlets
yet):
1. create new directory for my Portal content:
pages/dce-portal
place into this directory:
dce-main-page.psml
dce-user-page.psml
folder.metadata
2. define new role, 'dce-user-role', and assign it
to
the 'dce-user' user
3. define security constraints in the
folder.metadata:
'guest' users can view all pages;
users with 'dce-user-role' role can view all pages
security-constraints
security-constraint
usersguest/users
permissionsview/permissions
/security-constraint
security-constraint
rolesdce-user-role/roles
permissionsview/permissions
/security-constraint
/security-constraints
4. define security constraints in the
dce-main-page.psml:
!-- allow all users to view --
security-constraints
security-constraint
users*/users
Re: How to create a custom profiling rule?
Marina,
*.link files are only displayed if addressable in the / request
directory as rootLinks, or as elements of a document set. This explains
why they are not visible if located in the /dce-portal directory.
Security limitations apply to link visibility, so perhaps that might
explain why you do not see them when placed in the / directory?
We still need to discuss use of the /dce-portal directory with your
custom profiling rule, but I do not think it is messing up the display
of rootLinks... of course, I might be missing something that should be
obvious.
Randy
Marina wrote:
Sorry to bother you all with this again...
Ok, after I've done all these changes, I found a new
problem as well:
no links (*.link files) are displayed on either of the
pages, for neither of the users.
I tried placing them in the / and /dce-portal
directory, but still nothing is displayed.
Is this a problem with my new profiling rule?
What determines whether links are displayed or not?
Thanks!
Marina
--- Marina [EMAIL PROTECTED] wrote:
Randy,
thanks for your help. You are probably right and I
made it more complicated than what it should be.
Basically, what I would like to have in my portal
is:
1. all application-specific portal pages/ docsets/
links should be in a separate directory, say,
.../pages/dce-portal/
2. users ('dce-user', 'dce-admin') with the
'dce-user-role' should be able to see one main page,
dce-main-page.psml, and one additional page as a
tab,
dce-users-page.psml. Both .psml pages are in the
.../pages/dce-portal/ directory
3. a generic (non-logged in, 'guest') user should
see
the ../pages/dce-portal/dce-main-page.psml, and
nothing else
So, to accomplish this, I have created this custom
profiling rule:
insert into PROFILING_RULE values ('dce-generic',
'org.apache.jetspeed.profiler.rules.impl.StandardProfilingRule',
'rule for non-logged in DCE portal users')
insert into RULE_CRITERION values ('100',
'dce-generic', 0, 'path', 'path', '/dce-portal', 0)
and assigned it to the 'guest', 'dce-user' and
'dce-admin' users.
This made all pages visible to these three users. To
restrict access to the user-specific page to the
users
with the 'dce-user-role' role, I've added the
following security constraints to the
dce-users-page.psml:
security-constraint
rolesdce-user-role/roles
permissionsview/permissions
/security-constraint
Well, that did work. With the exception of those
problems I mentioned in my previous post (one of
them
was fixed by using #if($site.rootLinks.isEmpty()) as
David suggested)
So, the only problem that is still left is inclusion
of the .ds sets from the '/' directory. I would
rather
like to use the ../pages/dce-portal/ as the root
directory, but my profiling rule does not seem to
accomplish this.
I hope I'm being clear :)
And thanks a lot for looking into this!
Marina
--- Randy Watler [EMAIL PROTECTED] wrote:
Marina,
Using the Profiler effectively is more in my
court,
so let's see if I can
help here.
I think there are three subjects here that need
individual attention:
1. you probably do not need to define a new
profiling rule... there are some
predefined rules that you can use to achieve
role-based profiling,
2. the demo site is just that and you should start
with a clean
WEB-INF/pages directory only adding in what you
need
from the demo site, and
3. the tigris sample decorator is a good starting
place, but most everyone
ends up customizing and deploying their own
flavor.
So, rather than trying to figure out what you have
now, I would like to know
what your objective is. I'll then tell you how I'd
solve it using the M1
release version. We can then compare notes and
take
it from there... ok?
Randy
-Original Message-
From: Marina
To: Jetspeed Users List
Sent: 12/30/04 1:26 PM
Subject: Re: How to create a custom profiling
rule?
David,
Thanks for the clarification. I did find a way to
do
role-based profiling, basically, by restricting
access
to specific PSML pages by roles.
I still have a few problems I was not able to
solve
so
far. The main one is that I still get some
elements
from the '/' directory included into my pages,
even
though I explicitly specified in my profiling rule
that only elements from a specific directory
should
be
used. I think I made some stupid mistakes while
creating custom profiling rules...
Here is how I setup my portal's content and
created
a
new profiling rule using direct SQL (I don't think
it
is possible to that through the Admin portlets
yet):
1. create new directory for my Portal content:
pages/dce-portal
place into this directory:
dce-main-page.psml
dce-user-page.psml
folder.metadata
2. define new role, 'dce-user-role', and assign it
to
the 'dce-user' user
3. define security constraints in the
folder.metadata:
'guest' users can view all pages;
users with 'dce-user-role' role can
Re: How to create a custom profiling rule?
Marina wrote: However, there are a few problems: 1. Empty Additional Links area is shown - even though there are no *.link files in the pages/dce-portal/ dir If there are no links available then the collection should be empty I think what is happening is that there is a collection on $site.rootLinks however the collection is empty Instead of checking for null (#if($site.rootLinks) ). My guess (without try (#if($site.rootLinks.isEmpty()) if that works for you please send a patch 2. Empty Top Pages area is shown same as above 3. Docsets from the / root directory (*.ds files) are included Recommend removing any docsets that you are not using As part of the build process for the J2 sites I work on, I will either replace the the psml directory in the spring configuration with a new location, or just delete out all the demo psml, ds, etc... -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to create a custom profiling rule?
On Dec 29, 2004, at 9:25 AM, Marina wrote: Randy, thanks a lot for your answer! Do you know if there are plans to implement role-based (and group-based) profiling in the future J2 releases? I would think that role-based profiling is very critical for real applications. You can setup the default rule to use a role-based algorithm, or you can assigned users to use a specific role algorithm So its not like there isn't role-based profiling in the system -- its pretty well supported, but not in the manner you are suggesting. With the default global profiling, does it mean that the profiling rule assigned to '*' users is used UNLESS a different rule is assigned to specific users? yes take a look at the admin profiling portlet, and the user admin portlet you can configure all profiling (no need to edit the tables) via the admin portlets although I admit its a bit difficult without any documentation Or does it apply to all users regardless of other assignments? Thanks, Marina --- Randy Watler [EMAIL PROTECTED] wrote: Marina, David is the Profiler Master, so he is much more qualified to explain its configuration and inner workings. The source is in components/profiler. See comments below... It seems that profiling rules are assigned to the users based on the user names. Yes. At least this is what I see in the PRINCIPAL_RULE_ASSOC table - I created a new user, 'dce_admin', and assigned a 'security' profiling rule to it, and the (dce_admin, page, security) values got inserted into the PRINCIPAL_RULE_ASSOC table. Just FYI, the locator/rule name security has special meaning in J2... you might want to pick another name for your custom rule to avoid confusion. The security locator/rule is used when a user has an expired password and must select a new one. See details in the archives of the dev list. Now my question: how could I assign a profiling rule to a rolename, not a username? For example, I might want all users with the 'dce_admin_role' role to use the 'security' rule. We have discussed this, but it is not been implemented yet. There is a global default mechanism in place: if you specify a PRINCIPAL_RULE_ASSOC entry with a username of '*, it will be used for all users. This feature may not be implemented in this way in the future, but there certainly will be some other way to do the same thing. Randy __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to create a custom profiling rule?
Marina, David is the Profiler Master, so he is much more qualified to explain its configuration and inner workings. The source is in components/profiler. See comments below... It seems that profiling rules are assigned to the users based on the user names. Yes. At least this is what I see in the PRINCIPAL_RULE_ASSOC table - I created a new user, 'dce_admin', and assigned a 'security' profiling rule to it, and the (dce_admin, page, security) values got inserted into the PRINCIPAL_RULE_ASSOC table. Just FYI, the locator/rule name security has special meaning in J2... you might want to pick another name for your custom rule to avoid confusion. The security locator/rule is used when a user has an expired password and must select a new one. See details in the archives of the dev list. Now my question: how could I assign a profiling rule to a rolename, not a username? For example, I might want all users with the 'dce_admin_role' role to use the 'security' rule. We have discussed this, but it is not been implemented yet. There is a global default mechanism in place: if you specify a PRINCIPAL_RULE_ASSOC entry with a username of '*, it will be used for all users. This feature may not be implemented in this way in the future, but there certainly will be some other way to do the same thing. Randy
