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>
      <users>guest</users>
      <permissions>view</permissions>
    </security-constraint>
    <security-constraint>
      <roles>dce-user-role</roles>
      <permissions>view</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>
      <permissions>view</permissions>
    </security-constraint>
  </security-constraints>

5. define security constraints in the
dce-user-page.psml:
   <!-- allow users with 'dce-user-role' only to view
-->
    <security-constraints>
      <security-constraint>
        <roles>dce-user-role</roles>
        <permissions>view</permissions>
      </security-constraint>
    </security-constraints>

6. create new J2 profiling rule: 'dce-generic' rule:
rule for non-logged in DCE Portal users (by default,
they are all 'guest' users)

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, 'hard.coded', 'page',
'/dce-portal/dce-main-page.psml', 0)

7. assign new rule to the 'guest' user 
delete from PRINCIPAL_RULE_ASSOC where principal_name
= 'guest'
insert into PRINCIPAL_RULE_ASSOC values ('guest',
'page', 'dce-generic')
insert into PRINCIPAL_RULE_ASSOC values ('guest',
'docset', 'dce-generic')

8. do the same for the 'dce-user' user

The results of all that:
in general , it worked as intended. The
pages/dce-portal/dce-main-page.psml is shown whenever
a 'guest' user accesses it. When a user logs in with a
'dce-user-role' - he also sees the second page (tab),
dce-ser-page.psml.
 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
2. Empty 'Top Pages' area is shown 
3. Docsets from the '/' root directory (*.ds files)
are included

I also tried to modify the profiling rule this way:
insert into RULE_CRITERION values ('100',
'dce-generic', 0, 'path', 'path', '/dce-portal', 0)
 but it produced the same results. 

Any idea how to avoid showing root-level elements and
empty docsets in the portal page?

I checked
decorations\layout\html\tigris\decorator-top.vm and it
seems like it does try not to show, say, 'Additional
Links' label when there are no links
(#if($site.rootLinks) .... ). My guess (without
checking the actual code) would be that it is checking
the links in the '/' directory, always, and then tries
to display links from the real working directory (in
my case - there are none). 

Any insight will be greatly appreciated :-)

Marina



--- David Sean Taylor <[EMAIL PROTECTED]> wrote:

> 
> 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]
> 
> 



        
                
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to