J2 Profiler, was: Re: Jetspeed2 M1 security setup
Doug Schnelzer wrote: Randy, Thanks for the guidance. Putting the login portlet in a plain page in the guest directory and protecting everything else works well. In the future, it would be nice to dynamically show/hide portlets on a page based on a user's role. It is definitely under consideration... odds are it will be there in M2 if I had to guess, but others need to weigh in. As I dig in further, can you point me in the right direction for learning more about how the profiler works? Should I just follow the Jetspeed2 source code? If so, can you point me at a Java class to start with? First, look and understand the examples shipped with J2. Try logging in as user/user and jetspeed/jetspeed. Compare what you see with the various content pages and other elements in the pages directories. For more detail, check out this document: http://cvs.apache.org/viewcvs.cgi/jakarta-jetspeed-2/design-docs/src/profiler/J2-page-manager-profiling.sxw This is an OpenOffice document. I can email you another format if you'd like. The source code for all of this resides in /components/profiler and /components/page-manager, but it is not trivial. Feel free to ask questions here so that others can read about the profiler and how to configure it! Also as I browse through the WEB-INF/pages directory structure, there seems to be psml files that aren't displayed (e.g. pages/_user/user/p003.psml and pages/_user/user/nested-layout.psml). These are simply user files for 'user', (instead of 'guest')! Login as user/user. I'd like to learn more about how this works. Is the psml documentation for Jetspeed 1 applicable? Personally, I'd prefer if you stick with J2 resources and asking questions here. We can also contribute to the wiki as we go, (if nothing else we can link back to user list threads). If not can you recommend a better starting point (part of the source code is fine) for some self-study on overall navigation and layout? The easiest thing is to look at the examples. For a better understanding of navigations/layout, look at the Velocity, (*.vm), templates in the WEB-INF/decorations/layout/html/tigris and WEB-INF/decorations/portlet/html/tigris directories. Most of all, don't be shy on this list! Thanks very much, Doug No problem... good luck with J2! Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jetspeed2 M1 security setup
Randy, Thanks for the guidance. Putting the login portlet in a plain page in the guest directory and protecting everything else works well. In the future, it would be nice to dynamically show/hide portlets on a page based on a user's role. As I dig in further, can you point me in the right direction for learning more about how the profiler works? Should I just follow the Jetspeed2 source code? If so, can you point me at a Java class to start with? Also as I browse through the WEB-INF/pages directory structure, there seems to be psml files that aren't displayed (e.g. pages/_user/user/p003.psml and pages/_user/user/nested-layout.psml). I'd like to learn more about how this works. Is the psml documentation for Jetspeed 1 applicable? If not can you recommend a better starting point (part of the source code is fine) for some self-study on overall navigation and layout? Thanks very much, Doug -Original Message- From: Randy Watler [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 15, 2004 7:04 PM To: Jetspeed Users List Subject: Re: Jetspeed2 M1 security setup Ate Douma wrote: > > Randy Watler wrote: > >> Doug, >> >> Portlet level security constraints are apparently the responsibility >> of the portlet writer to implement, so the portal and portlet >> container will always display the portlet. We just received >> clarification on this from the pluto mail list: >> >> http://nagoya.apache.org/eyebrowse/ReadMsg?listId=261&msgNo=2160 > > One small correction: only the portlet container should not > enforce security constraints according to the portlet specification. > The portal can, as Randy showed in the example below. > > Another solution would be to use security constraints on a page, > restricting > (certain type of) access to only certain users, roles or groups. Just to be clear, I think Doug is trying to control access by role at the page level but wants finer grain control over portlet in the page. This is not available now, so I was proposing he try controlling acess to two different pages with appropriate portlet subsets via the profiler. > > Furthermore, this should not only be possible on page level but even on > (psml) fragment level, but that isn't yet implemented I think (Randy?). This is not implemented in M1. > > If (when) it is, you can simply restrict certain parts of a page to > certain > users, groups and/or roles. Well, David and I discussed this just before M1 was released. I actually had it implemented on the fragment level, but we figured that the portlet security constraints would be sufficient/conflicting, so we removed it. However, we did not have the Pluto ruling then. So, we'll have to revist this for M2. I'll add it to my "to-do" list. > > >> >> So, one way to achieve what you are after is to use the profiler. >> When the user is not logged in, they are known as 'guest'. By >> default, users are profiled using the 'j1' rule. This all boils down >> to the fact that unauthenticated users can be directed to pages >> placed in the ".../WEB-INF/pages/_user/guest" directory. Place your >> stripped down version of your pages in this 'guest' directory, >> (without your role security), and then secure all the rest of the >> pages in your site by role. >> >> HTH, >> >> Randy >> >> Doug Schnelzer wrote: >> >>> I've been working through this thread. It's very helpful. Thanks >>> to Marina >>> and Randy for providing some good documentation here. As I have worked >>> through this, I have a follow up question... >>> >>> Is there a way in a psml file or in one of the deployment >>> descriptors to >>> require a role before displaying "some" of the portlets on a page? >>> I want >>> to modify the default page so that only the login portlet is visible >>> until a >>> user logs in. If I make the entire page require a role, then I >>> can't log in >>> to establish my identity. >>> >>> Thanks, Doug >>> >>> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed2 M1 security setup
Ate Douma wrote: Randy Watler wrote: Doug, Portlet level security constraints are apparently the responsibility of the portlet writer to implement, so the portal and portlet container will always display the portlet. We just received clarification on this from the pluto mail list: http://nagoya.apache.org/eyebrowse/ReadMsg?listId=261&msgNo=2160 One small correction: only the portlet container should not enforce security constraints according to the portlet specification. The portal can, as Randy showed in the example below. Another solution would be to use security constraints on a page, restricting (certain type of) access to only certain users, roles or groups. Just to be clear, I think Doug is trying to control access by role at the page level but wants finer grain control over portlet in the page. This is not available now, so I was proposing he try controlling acess to two different pages with appropriate portlet subsets via the profiler. Furthermore, this should not only be possible on page level but even on (psml) fragment level, but that isn't yet implemented I think (Randy?). This is not implemented in M1. If (when) it is, you can simply restrict certain parts of a page to certain users, groups and/or roles. Well, David and I discussed this just before M1 was released. I actually had it implemented on the fragment level, but we figured that the portlet security constraints would be sufficient/conflicting, so we removed it. However, we did not have the Pluto ruling then. So, we'll have to revist this for M2. I'll add it to my "to-do" list. So, one way to achieve what you are after is to use the profiler. When the user is not logged in, they are known as 'guest'. By default, users are profiled using the 'j1' rule. This all boils down to the fact that unauthenticated users can be directed to pages placed in the ".../WEB-INF/pages/_user/guest" directory. Place your stripped down version of your pages in this 'guest' directory, (without your role security), and then secure all the rest of the pages in your site by role. HTH, Randy Doug Schnelzer wrote: I've been working through this thread. It's very helpful. Thanks to Marina and Randy for providing some good documentation here. As I have worked through this, I have a follow up question... Is there a way in a psml file or in one of the deployment descriptors to require a role before displaying "some" of the portlets on a page? I want to modify the default page so that only the login portlet is visible until a user logs in. If I make the entire page require a role, then I can't log in to establish my identity. Thanks, Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed2 M1 security setup
Randy Watler wrote:
Doug,
Portlet level security constraints are apparently the responsibility of
the portlet writer to implement, so the portal and portlet container
will always display the portlet. We just received clarification on this
from the pluto mail list:
http://nagoya.apache.org/eyebrowse/ReadMsg?listId=261&msgNo=2160
One small correction: only the portlet container should not
enforce security constraints according to the portlet specification.
The portal can, as Randy showed in the example below.
Another solution would be to use security constraints on a page, restricting
(certain type of) access to only certain users, roles or groups.
Furthermore, this should not only be possible on page level but even on
(psml) fragment level, but that isn't yet implemented I think (Randy?).
If (when) it is, you can simply restrict certain parts of a page to certain
users, groups and/or roles.
So, one way to achieve what you are after is to use the profiler. When
the user is not logged in, they are known as 'guest'. By default, users
are profiled using the 'j1' rule. This all boils down to the fact that
unauthenticated users can be directed to pages placed in the
".../WEB-INF/pages/_user/guest" directory. Place your stripped down
version of your pages in this 'guest' directory, (without your role
security), and then secure all the rest of the pages in your site by role.
HTH,
Randy
Doug Schnelzer wrote:
I've been working through this thread. It's very helpful. Thanks to
Marina
and Randy for providing some good documentation here. As I have worked
through this, I have a follow up question...
Is there a way in a psml file or in one of the deployment descriptors to
require a role before displaying "some" of the portlets on a page? I
want
to modify the default page so that only the login portlet is visible
until a
user logs in. If I make the entire page require a role, then I can't
log in
to establish my identity.
Thanks, Doug
-Original Message-
From: Marina [mailto:[EMAIL PROTECTED] Sent: Monday, December 13, 2004
4:35 PM
To: Jetspeed Users List
Subject: RE: Jetspeed2 M1 security setup
Randy, thanks a lot for your help! I was able to setup
a basic access control to my portlet's view and Edit
mode.
I do have more questions on the user management in J2,
though :)
I've created a new user, dce-admin, using the
"Administrative Portlets" as 'admin' user. This worked
fine, and I was able to detect this user through the
PortletResponse.getUserPrincipal().
I've also tried to create a new role, say
dce-admin-role, and assign this role to the new user.
This , unfortunately, did not work. I entered the new
role name into the corresponding form ("Add Role") of
the "Role Management" tab, but it was never added to
the list of the available roles and when I tried to
assign this role to the new user I've got an error
from J2 complaining that this role does not exist:
*** New Full Path: /role/dce-admin-role
failed to add user to role: dce-admin,
dce-admin-roleorg.apache.jetspeed.security.SecurityException:
The role does not exist. dce-admin-role
*** New Full Path: /role/dce-admin-role
Any idea why this is not working?
Thanks,
Marina
--- Randy Watler <[EMAIL PROTECTED]> wrote:
Marina,
Thanks for using the jetspeed user list!
Comments below.
Randy
-Original Message-
From: Marina
To: 'Jetspeed Users List '
Sent: 12/6/04 5:06 PM
Subject: RE: Jetspeed2 M1 security setup (was:
jetspeed-newbie
Roles-Groups-Users)>
Hi,
I've successfully built and installed J2 M1 and
was
looking into the demo applications to figure out
how
to setup access control for portlets/pages.
After checking out some example portlets , like
RoleSecurityTest and Login, and their source code,
I
think I have some idea of how to approach the task
but
I would like to clarify some topics.
First, I'll list my assumptions and then ask
questions:
1.
tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security
file specifies 'Edit'/'View' permissions for the
default Portal's page, defined in default-page.psml
The /page.security file defines named security
constraints that can be
referenced here or in individual page, folder meta
data, link, or document
set documents. The scope of this file is global
across the entire site.
References take the form of
, (which
appear only in /page.security), or
.
Thus, this part :
admin
view, edit
means that only a user with the role 'admin' can
edit
the layout of the page.
Yes, since this fragment is referenced in a
, it applies to
all documents in the site.
And this fragment:
manager
view
means that a user with the role 'manager' can view
the
page.
Re: Jetspeed2 M1 security setup
Doug,
Portlet level security constraints are apparently the responsibility of
the portlet writer to implement, so the portal and portlet container
will always display the portlet. We just received clarification on this
from the pluto mail list:
http://nagoya.apache.org/eyebrowse/ReadMsg?listId=261&msgNo=2160
So, one way to achieve what you are after is to use the profiler. When
the user is not logged in, they are known as 'guest'. By default, users
are profiled using the 'j1' rule. This all boils down to the fact that
unauthenticated users can be directed to pages placed in the
".../WEB-INF/pages/_user/guest" directory. Place your stripped down
version of your pages in this 'guest' directory, (without your role
security), and then secure all the rest of the pages in your site by role.
HTH,
Randy
Doug Schnelzer wrote:
I've been working through this thread. It's very helpful. Thanks to Marina
and Randy for providing some good documentation here. As I have worked
through this, I have a follow up question...
Is there a way in a psml file or in one of the deployment descriptors to
require a role before displaying "some" of the portlets on a page? I want
to modify the default page so that only the login portlet is visible until a
user logs in. If I make the entire page require a role, then I can't log in
to establish my identity.
Thanks, Doug
-Original Message-
From: Marina [mailto:[EMAIL PROTECTED]
Sent: Monday, December 13, 2004 4:35 PM
To: Jetspeed Users List
Subject: RE: Jetspeed2 M1 security setup
Randy, thanks a lot for your help! I was able to setup
a basic access control to my portlet's view and Edit
mode.
I do have more questions on the user management in J2,
though :)
I've created a new user, dce-admin, using the
"Administrative Portlets" as 'admin' user. This worked
fine, and I was able to detect this user through the
PortletResponse.getUserPrincipal().
I've also tried to create a new role, say
dce-admin-role, and assign this role to the new user.
This , unfortunately, did not work. I entered the new
role name into the corresponding form ("Add Role") of
the "Role Management" tab, but it was never added to
the list of the available roles and when I tried to
assign this role to the new user I've got an error
from J2 complaining that this role does not exist:
*** New Full Path: /role/dce-admin-role
failed to add user to role: dce-admin,
dce-admin-roleorg.apache.jetspeed.security.SecurityException:
The role does not exist. dce-admin-role
*** New Full Path: /role/dce-admin-role
Any idea why this is not working?
Thanks,
Marina
--- Randy Watler <[EMAIL PROTECTED]> wrote:
Marina,
Thanks for using the jetspeed user list!
Comments below.
Randy
-Original Message-
From: Marina
To: 'Jetspeed Users List '
Sent: 12/6/04 5:06 PM
Subject: RE: Jetspeed2 M1 security setup (was:
jetspeed-newbie
Roles-Groups-Users)>
Hi,
I've successfully built and installed J2 M1 and
was
looking into the demo applications to figure out
how
to setup access control for portlets/pages.
After checking out some example portlets , like
RoleSecurityTest and Login, and their source code,
I
think I have some idea of how to approach the task
but
I would like to clarify some topics.
First, I'll list my assumptions and then ask
questions:
1.
tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security
file specifies 'Edit'/'View' permissions for the
default Portal's page, defined in default-page.psml
The /page.security file defines named security
constraints that can be
referenced here or in individual page, folder meta
data, link, or document
set documents. The scope of this file is global
across the entire site.
References take the form of
, (which
appear only in /page.security), or
.
Thus, this part :
admin
view, edit
means that only a user with the role 'admin' can
edit
the layout of the page.
Yes, since this fragment is referenced in a
, it applies to
all documents in the site.
And this fragment:
manager
view
means that a user with the role 'manager' can view
the
page.
Yes, where used with a .
However, anybody can view this default page in
reality
- even before a user logs in. You don't need any
special privileges to access
http://localhost:8080/jetspeed to see the page.
My assumption is that it is because security
constraints are "overwritten" in the
pages/folder.metadata file (see below).
Is that true?
Not exactly. The override is in the
default-page.psml itself, (user=*,
permission=view).
What is the scope of the page.security definitions
and
where are they used?
See
RE: Jetspeed2 M1 security setup
I've been working through this thread. It's very helpful. Thanks to Marina
and Randy for providing some good documentation here. As I have worked
through this, I have a follow up question...
Is there a way in a psml file or in one of the deployment descriptors to
require a role before displaying "some" of the portlets on a page? I want
to modify the default page so that only the login portlet is visible until a
user logs in. If I make the entire page require a role, then I can't log in
to establish my identity.
Thanks, Doug
-Original Message-
From: Marina [mailto:[EMAIL PROTECTED]
Sent: Monday, December 13, 2004 4:35 PM
To: Jetspeed Users List
Subject: RE: Jetspeed2 M1 security setup
Randy, thanks a lot for your help! I was able to setup
a basic access control to my portlet's view and Edit
mode.
I do have more questions on the user management in J2,
though :)
I've created a new user, dce-admin, using the
"Administrative Portlets" as 'admin' user. This worked
fine, and I was able to detect this user through the
PortletResponse.getUserPrincipal().
I've also tried to create a new role, say
dce-admin-role, and assign this role to the new user.
This , unfortunately, did not work. I entered the new
role name into the corresponding form ("Add Role") of
the "Role Management" tab, but it was never added to
the list of the available roles and when I tried to
assign this role to the new user I've got an error
from J2 complaining that this role does not exist:
*** New Full Path: /role/dce-admin-role
failed to add user to role: dce-admin,
dce-admin-roleorg.apache.jetspeed.security.SecurityException:
The role does not exist. dce-admin-role
*** New Full Path: /role/dce-admin-role
Any idea why this is not working?
Thanks,
Marina
--- Randy Watler <[EMAIL PROTECTED]> wrote:
> Marina,
>
> Thanks for using the jetspeed user list!
>
> Comments below.
>
> Randy
>
> >-----Original Message-
> >From: Marina
> >To: 'Jetspeed Users List '
> >Sent: 12/6/04 5:06 PM
> >Subject: RE: Jetspeed2 M1 security setup (was:
> jetspeed-newbie
> Roles-Groups-Users)>
> >
> >Hi,
> >
> > I've successfully built and installed J2 M1 and
> was
> >looking into the demo applications to figure out
> how
> >to setup access control for portlets/pages.
> >After checking out some example portlets , like
> >RoleSecurityTest and Login, and their source code,
> I
> >think I have some idea of how to approach the task
> but
> >I would like to clarify some topics.
> >
> >First, I'll list my assumptions and then ask
> >questions:
> >
> >1.
>
>tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security
> > file specifies 'Edit'/'View' permissions for the
> >default Portal's page, defined in default-page.psml
>
> The /page.security file defines named security
> constraints that can be
> referenced here or in individual page, folder meta
> data, link, or document
> set documents. The scope of this file is global
> across the entire site.
> References take the form of
> , (which
> appear only in /page.security), or
> .
>
> >Thus, this part :
> >
> >
> > admin
> > view, edit
> >
> >
> >means that only a user with the role 'admin' can
> edit
> >the layout of the page.
>
> Yes, since this fragment is referenced in a
> , it applies to
> all documents in the site.
>
> >And this fragment:
> >
> >
> > manager
> > view
> >
> >
> >means that a user with the role 'manager' can view
> the
> >page.
>
> Yes, where used with a .
>
> >However, anybody can view this default page in
> reality
> >- even before a user logs in. You don't need any
> >special privileges to access
> >http://localhost:8080/jetspeed to see the page.
> >My assumption is that it is because security
> >constraints are "overwritten" in the
> >pages/folder.metadata file (see below).
> >Is that true?
>
> Not exactly. The override is in the
> default-page.psml itself, (user=*,
> permission=view).
>
> >What is the scope of the page.security definitions
> and
> >where are they used?
>
> See above.
>
> >2. each folder under /pages directory (including
> >/pages itself) has a folder.metadata file where
> more
> > are defined for that folder.
> >For example, here is pages/folder.metadata:
> >.
> >
> >
> > user
> >
Re: Jetspeed2 M1 security setup
Yes, it did work!
The original SQL query did not work right away, so I
looked more closely into the DB schema and guessed
that I should be using the '/role' node's node_id as
the 'parent_node_id' (204). That was a lucky guess and
the following query worked fine:
INSERT INTO PREFS_NODE
VALUES(200,204,'dce-admin-role',0,'/role/dce-admin-role','2004-05-22
16:27:12.472','2004-05-22 16:27:12.472');
After that, I was able to see the new role,
'dce-admin-role', in the 'Role Management' portlet's
list, and was able to assign this role to a user and
see it detected correctly by
PortletRequest.isUserInRole("dce-admin-role").
Thanks a lot for your help!
Marina
--- David Le Strat <[EMAIL PROTECTED]> wrote:
> Marina,
>
> If you are doing this manually, you also need to set
> up the role hierarchy manager. In SQL terms, this
> means something like this:
>
> INSERT INTO PREFS_NODE
>
VALUES(200,196,'dce-admin-role',0,'/role/dce-admin-role','2004-05-22
> 16:27:12.472','2004-05-22 16:27:12.472');
>
> You can also use the RoleManager to add the role you
> want to set up.
>
> Regards,
>
> David.
>
> --- Marina <[EMAIL PROTECTED]> wrote:
>
> > Thanks, Randy,
> >
> > I tried adding the new role directly into the HSQL
> > DB
> > like this:
> > INSERT INTO SECURITY_PRINCIPAL
> >
>
VALUES(15,'org.apache.jetspeed.security.JetspeedRolePrincipalImpl',0,1,'/role/dce-admin-role','2004-12-15
> > 16:27:12.572','2004-12-15 16:27:12.572');
> >
> > I ran this sql query directly on the HSQL DB,
> > without
> > modifying the
> populate-userinfo-for-default-psml.sql
> > and rebuilding J2.
> >
> > After I restarted J2, though, the new role is
> still
> > not displayed in the list of available roles in
> the
> > "Role Management" portlet. And asigning this role
> to
> > a
> > user through the "User Manegement" portlet did not
> > work either.
> >
> > Is this the only table I have to update
> > ('security_principal') in order to create a new
> > role,
> > or are there some other related tables that I
> > missed?
> >
> > Thanks,
> > Marina
> >
> > --- Randy Watler <[EMAIL PROTECTED]> wrote:
> >
> > > Marina,
> > >
> > > There you have it, (thanks David).
> > >
> > > It is a simple matter to add users, roles,
> groups,
> > > etc. directly to the
> > > DB in the interim. See one of the following
> > scripts:
> > >
> > > CVS -
> > src/sql/populate-userinfo-for-default-psml.sql
> > > CVS - src/sql/ > > name>/populate-userinfo-for-default-psml.sql
> > > M1 -
> > >
> >
>
jetspeed-database/scripts/sql/DML/populate-userinfo-for-default-psml.sql
> > > M1 - jetspeed-database/scripts/sql/DML/ > > name>/populate-userinfo-for-default-psml.sql
> > >
> > > Randy
> > >
> > > David Le Strat wrote:
> > >
> > > >Marina,
> > > >
> > > >Implementation of the role management portlet
> is
> > > not
> > > >complete.
> > > >
> > > >Regards,
> > > >
> > > >David Le Strat.
> > > >--- Marina <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > >
> > > >>Randy, thanks a lot for your help! I was able
> to
> > > >>setup
> > > >>a basic access control to my portlet's view
> and
> > > Edit
> > > >>mode.
> > > >>I do have more questions on the user
> management
> > in
> > > >>J2,
> > > >>though :)
> > > >>
> > > >>I've created a new user, dce-admin, using the
> > > >>"Administrative Portlets" as 'admin' user.
> This
> > > >>worked
> > > >>fine, and I was able to detect this user
> through
> > > the
> > > >>PortletResponse.getUserPrincipal().
> > > >>I've also tried to create a new role, say
> > > >>dce-admin-role, and assign this role to the
> new
> > > >>user.
> > > >>This , unfortunately, did not work. I entered
> > the
> > > >>new
> > > >>role name into the corresponding form ("Add
> > Role")
> > > >>of
> > > >>the "Role Management" tab, but it was never
> > added
> > > to
> > > >>the list of the available roles and when I
> tried
> > > to
> > > >>assign this role to the new user I've got an
> > error
> > > >>from J2 complaining that this role does not
> > exist:
> > > >>
> > > >>*** New Full Path: /role/dce-admin-role
> > > >>failed to add user to role: dce-admin,
> > > >>
> > > >>
> > > >>
> > >
> >
>
>dce-admin-roleorg.apache.jetspeed.security.SecurityException:
> > > >
> > > >
> > > >>The role does not exist. dce-admin-role
> > > >>*** New Full Path: /role/dce-admin-role
> > > >>
> > > >>
> > > >>Any idea why this is not working?
> > > >>
> > > >>Thanks,
> > > >>Marina
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
> > >
> >
>
-
> > > To unsubscribe, e-mail:
> > > [EMAIL PROTECTED]
> > > For additional commands, e-mail:
> > > [EMAIL PROTECTED]
> > >
> > >
> >
> >
> >
> >
> > __
> > Do you Yahoo!?
> > Yahoo! Mail - Helps protect you from nasty
> viruses.
> > http://promotions.yahoo.com/new_mail
> >
> >
>
-
> > To unsubscribe, e-mail:
>
Re: Jetspeed2 M1 security setup
Marina,
If you are doing this manually, you also need to set
up the role hierarchy manager. In SQL terms, this
means something like this:
INSERT INTO PREFS_NODE
VALUES(200,196,'dce-admin-role',0,'/role/dce-admin-role','2004-05-22
16:27:12.472','2004-05-22 16:27:12.472');
You can also use the RoleManager to add the role you
want to set up.
Regards,
David.
--- Marina <[EMAIL PROTECTED]> wrote:
> Thanks, Randy,
>
> I tried adding the new role directly into the HSQL
> DB
> like this:
> INSERT INTO SECURITY_PRINCIPAL
>
VALUES(15,'org.apache.jetspeed.security.JetspeedRolePrincipalImpl',0,1,'/role/dce-admin-role','2004-12-15
> 16:27:12.572','2004-12-15 16:27:12.572');
>
> I ran this sql query directly on the HSQL DB,
> without
> modifying the populate-userinfo-for-default-psml.sql
> and rebuilding J2.
>
> After I restarted J2, though, the new role is still
> not displayed in the list of available roles in the
> "Role Management" portlet. And asigning this role to
> a
> user through the "User Manegement" portlet did not
> work either.
>
> Is this the only table I have to update
> ('security_principal') in order to create a new
> role,
> or are there some other related tables that I
> missed?
>
> Thanks,
> Marina
>
> --- Randy Watler <[EMAIL PROTECTED]> wrote:
>
> > Marina,
> >
> > There you have it, (thanks David).
> >
> > It is a simple matter to add users, roles, groups,
> > etc. directly to the
> > DB in the interim. See one of the following
> scripts:
> >
> > CVS -
> src/sql/populate-userinfo-for-default-psml.sql
> > CVS - src/sql/ > name>/populate-userinfo-for-default-psml.sql
> > M1 -
> >
>
jetspeed-database/scripts/sql/DML/populate-userinfo-for-default-psml.sql
> > M1 - jetspeed-database/scripts/sql/DML/ > name>/populate-userinfo-for-default-psml.sql
> >
> > Randy
> >
> > David Le Strat wrote:
> >
> > >Marina,
> > >
> > >Implementation of the role management portlet is
> > not
> > >complete.
> > >
> > >Regards,
> > >
> > >David Le Strat.
> > >--- Marina <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >
> > >>Randy, thanks a lot for your help! I was able to
> > >>setup
> > >>a basic access control to my portlet's view and
> > Edit
> > >>mode.
> > >>I do have more questions on the user management
> in
> > >>J2,
> > >>though :)
> > >>
> > >>I've created a new user, dce-admin, using the
> > >>"Administrative Portlets" as 'admin' user. This
> > >>worked
> > >>fine, and I was able to detect this user through
> > the
> > >>PortletResponse.getUserPrincipal().
> > >>I've also tried to create a new role, say
> > >>dce-admin-role, and assign this role to the new
> > >>user.
> > >>This , unfortunately, did not work. I entered
> the
> > >>new
> > >>role name into the corresponding form ("Add
> Role")
> > >>of
> > >>the "Role Management" tab, but it was never
> added
> > to
> > >>the list of the available roles and when I tried
> > to
> > >>assign this role to the new user I've got an
> error
> > >>from J2 complaining that this role does not
> exist:
> > >>
> > >>*** New Full Path: /role/dce-admin-role
> > >>failed to add user to role: dce-admin,
> > >>
> > >>
> > >>
> >
>
>dce-admin-roleorg.apache.jetspeed.security.SecurityException:
> > >
> > >
> > >>The role does not exist. dce-admin-role
> > >>*** New Full Path: /role/dce-admin-role
> > >>
> > >>
> > >>Any idea why this is not working?
> > >>
> > >>Thanks,
> > >>Marina
> > >>
> > >>
> > >>
> > >
> > >
> >
> >
>
-
> > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
> >
>
>
>
>
> __
> Do you Yahoo!?
> Yahoo! Mail - Helps protect you from nasty viruses.
> http://promotions.yahoo.com/new_mail
>
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
__
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed2 M1 security setup
Thanks, Randy,
I tried adding the new role directly into the HSQL DB
like this:
INSERT INTO SECURITY_PRINCIPAL
VALUES(15,'org.apache.jetspeed.security.JetspeedRolePrincipalImpl',0,1,'/role/dce-admin-role','2004-12-15
16:27:12.572','2004-12-15 16:27:12.572');
I ran this sql query directly on the HSQL DB, without
modifying the populate-userinfo-for-default-psml.sql
and rebuilding J2.
After I restarted J2, though, the new role is still
not displayed in the list of available roles in the
"Role Management" portlet. And asigning this role to a
user through the "User Manegement" portlet did not
work either.
Is this the only table I have to update
('security_principal') in order to create a new role,
or are there some other related tables that I missed?
Thanks,
Marina
--- Randy Watler <[EMAIL PROTECTED]> wrote:
> Marina,
>
> There you have it, (thanks David).
>
> It is a simple matter to add users, roles, groups,
> etc. directly to the
> DB in the interim. See one of the following scripts:
>
> CVS - src/sql/populate-userinfo-for-default-psml.sql
> CVS - src/sql/ name>/populate-userinfo-for-default-psml.sql
> M1 -
>
jetspeed-database/scripts/sql/DML/populate-userinfo-for-default-psml.sql
> M1 - jetspeed-database/scripts/sql/DML/ name>/populate-userinfo-for-default-psml.sql
>
> Randy
>
> David Le Strat wrote:
>
> >Marina,
> >
> >Implementation of the role management portlet is
> not
> >complete.
> >
> >Regards,
> >
> >David Le Strat.
> >--- Marina <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >>Randy, thanks a lot for your help! I was able to
> >>setup
> >>a basic access control to my portlet's view and
> Edit
> >>mode.
> >>I do have more questions on the user management in
> >>J2,
> >>though :)
> >>
> >>I've created a new user, dce-admin, using the
> >>"Administrative Portlets" as 'admin' user. This
> >>worked
> >>fine, and I was able to detect this user through
> the
> >>PortletResponse.getUserPrincipal().
> >>I've also tried to create a new role, say
> >>dce-admin-role, and assign this role to the new
> >>user.
> >>This , unfortunately, did not work. I entered the
> >>new
> >>role name into the corresponding form ("Add Role")
> >>of
> >>the "Role Management" tab, but it was never added
> to
> >>the list of the available roles and when I tried
> to
> >>assign this role to the new user I've got an error
> >>from J2 complaining that this role does not exist:
> >>
> >>*** New Full Path: /role/dce-admin-role
> >>failed to add user to role: dce-admin,
> >>
> >>
> >>
>
>dce-admin-roleorg.apache.jetspeed.security.SecurityException:
> >
> >
> >>The role does not exist. dce-admin-role
> >>*** New Full Path: /role/dce-admin-role
> >>
> >>
> >>Any idea why this is not working?
> >>
> >>Thanks,
> >>Marina
> >>
> >>
> >>
> >
> >
>
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
__
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed2 M1 security setup
Marina,
There you have it, (thanks David).
It is a simple matter to add users, roles, groups, etc. directly to the
DB in the interim. See one of the following scripts:
CVS - src/sql/populate-userinfo-for-default-psml.sql
CVS - src/sql//populate-userinfo-for-default-psml.sql
M1 -
jetspeed-database/scripts/sql/DML/populate-userinfo-for-default-psml.sql
M1 - jetspeed-database/scripts/sql/DML//populate-userinfo-for-default-psml.sql
Randy
David Le Strat wrote:
Marina,
Implementation of the role management portlet is not
complete.
Regards,
David Le Strat.
--- Marina <[EMAIL PROTECTED]> wrote:
Randy, thanks a lot for your help! I was able to
setup
a basic access control to my portlet's view and Edit
mode.
I do have more questions on the user management in
J2,
though :)
I've created a new user, dce-admin, using the
"Administrative Portlets" as 'admin' user. This
worked
fine, and I was able to detect this user through the
PortletResponse.getUserPrincipal().
I've also tried to create a new role, say
dce-admin-role, and assign this role to the new
user.
This , unfortunately, did not work. I entered the
new
role name into the corresponding form ("Add Role")
of
the "Role Management" tab, but it was never added to
the list of the available roles and when I tried to
assign this role to the new user I've got an error
from J2 complaining that this role does not exist:
*** New Full Path: /role/dce-admin-role
failed to add user to role: dce-admin,
dce-admin-roleorg.apache.jetspeed.security.SecurityException:
The role does not exist. dce-admin-role
*** New Full Path: /role/dce-admin-role
Any idea why this is not working?
Thanks,
Marina
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jetspeed2 M1 security setup
Marina,
Implementation of the role management portlet is not
complete.
Regards,
David Le Strat.
--- Marina <[EMAIL PROTECTED]> wrote:
> Randy, thanks a lot for your help! I was able to
> setup
> a basic access control to my portlet's view and Edit
> mode.
> I do have more questions on the user management in
> J2,
> though :)
>
> I've created a new user, dce-admin, using the
> "Administrative Portlets" as 'admin' user. This
> worked
> fine, and I was able to detect this user through the
> PortletResponse.getUserPrincipal().
> I've also tried to create a new role, say
> dce-admin-role, and assign this role to the new
> user.
> This , unfortunately, did not work. I entered the
> new
> role name into the corresponding form ("Add Role")
> of
> the "Role Management" tab, but it was never added to
> the list of the available roles and when I tried to
> assign this role to the new user I've got an error
> from J2 complaining that this role does not exist:
>
> *** New Full Path: /role/dce-admin-role
> failed to add user to role: dce-admin,
>
dce-admin-roleorg.apache.jetspeed.security.SecurityException:
> The role does not exist. dce-admin-role
> *** New Full Path: /role/dce-admin-role
>
>
> Any idea why this is not working?
>
> Thanks,
> Marina
>
>
>
> --- Randy Watler <[EMAIL PROTECTED]> wrote:
>
> > Marina,
> >
> > Thanks for using the jetspeed user list!
> >
> > Comments below.
> >
> > Randy
> >
> > >-Original Message-
> > >From: Marina
> > >To: 'Jetspeed Users List '
> > >Sent: 12/6/04 5:06 PM
> > >Subject: RE: Jetspeed2 M1 security setup (was:
> > jetspeed-newbie
> > Roles-Groups-Users)>
> > >
> > >Hi,
> > >
> > > I've successfully built and installed J2 M1 and
> > was
> > >looking into the demo applications to figure out
> > how
> > >to setup access control for portlets/pages.
> > >After checking out some example portlets , like
> > >RoleSecurityTest and Login, and their source
> code,
> > I
> > >think I have some idea of how to approach the
> task
> > but
> > >I would like to clarify some topics.
> > >
> > >First, I'll list my assumptions and then ask
> > >questions:
> > >
> > >1.
> >
>
>tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security
> > > file specifies 'Edit'/'View' permissions for the
> > >default Portal's page, defined in
> default-page.psml
> >
> > The /page.security file defines named security
> > constraints that can be
> > referenced here or in individual page, folder meta
> > data, link, or document
> > set documents. The scope of this file is global
> > across the entire site.
> > References take the form of
> > , (which
> > appear only in /page.security), or
> > .
> >
> > >Thus, this part :
> > >
> > >
> > > admin
> > > view, edit
> > >
> > >
> > >means that only a user with the role 'admin' can
> > edit
> > >the layout of the page.
> >
> > Yes, since this fragment is referenced in a
> > , it applies to
> > all documents in the site.
> >
> > >And this fragment:
> > >
> > >
> > > manager
> > > view
> > >
> > >
> > >means that a user with the role 'manager' can
> view
> > the
> > >page.
> >
> > Yes, where used with a
> .
> >
> > >However, anybody can view this default page in
> > reality
> > >- even before a user logs in. You don't need any
> > >special privileges to access
> > >http://localhost:8080/jetspeed to see the page.
> > >My assumption is that it is because security
> > >constraints are "overwritten" in the
> > >pages/folder.metadata file (see below).
> > >Is that true?
> >
> > Not exactly. The override is in the
> > default-page.psml itself, (user=*,
> > permission=view).
> >
> > >What is the scope of the page.security
> definitions
> > and
> > >where are they used?
> >
> > See above.
> >
> > >2. each folder under /pages directory (including
> > >/pages itself) has a folder.metadata file where
> > more
> > > are defined for that
RE: Jetspeed2 M1 security setup
Randy, thanks a lot for your help! I was able to setup
a basic access control to my portlet's view and Edit
mode.
I do have more questions on the user management in J2,
though :)
I've created a new user, dce-admin, using the
"Administrative Portlets" as 'admin' user. This worked
fine, and I was able to detect this user through the
PortletResponse.getUserPrincipal().
I've also tried to create a new role, say
dce-admin-role, and assign this role to the new user.
This , unfortunately, did not work. I entered the new
role name into the corresponding form ("Add Role") of
the "Role Management" tab, but it was never added to
the list of the available roles and when I tried to
assign this role to the new user I've got an error
from J2 complaining that this role does not exist:
*** New Full Path: /role/dce-admin-role
failed to add user to role: dce-admin,
dce-admin-roleorg.apache.jetspeed.security.SecurityException:
The role does not exist. dce-admin-role
*** New Full Path: /role/dce-admin-role
Any idea why this is not working?
Thanks,
Marina
--- Randy Watler <[EMAIL PROTECTED]> wrote:
> Marina,
>
> Thanks for using the jetspeed user list!
>
> Comments below.
>
> Randy
>
> >-Original Message-
> >From: Marina
> >To: 'Jetspeed Users List '
> >Sent: 12/6/04 5:06 PM
> >Subject: RE: Jetspeed2 M1 security setup (was:
> jetspeed-newbie
> Roles-Groups-Users)>
> >
> >Hi,
> >
> > I've successfully built and installed J2 M1 and
> was
> >looking into the demo applications to figure out
> how
> >to setup access control for portlets/pages.
> >After checking out some example portlets , like
> >RoleSecurityTest and Login, and their source code,
> I
> >think I have some idea of how to approach the task
> but
> >I would like to clarify some topics.
> >
> >First, I'll list my assumptions and then ask
> >questions:
> >
> >1.
>
>tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security
> > file specifies 'Edit'/'View' permissions for the
> >default Portal's page, defined in default-page.psml
>
> The /page.security file defines named security
> constraints that can be
> referenced here or in individual page, folder meta
> data, link, or document
> set documents. The scope of this file is global
> across the entire site.
> References take the form of
> , (which
> appear only in /page.security), or
> .
>
> >Thus, this part :
> >
> >
> > admin
> > view, edit
> >
> >
> >means that only a user with the role 'admin' can
> edit
> >the layout of the page.
>
> Yes, since this fragment is referenced in a
> , it applies to
> all documents in the site.
>
> >And this fragment:
> >
> >
> > manager
> > view
> >
> >
> >means that a user with the role 'manager' can view
> the
> >page.
>
> Yes, where used with a .
>
> >However, anybody can view this default page in
> reality
> >- even before a user logs in. You don't need any
> >special privileges to access
> >http://localhost:8080/jetspeed to see the page.
> >My assumption is that it is because security
> >constraints are "overwritten" in the
> >pages/folder.metadata file (see below).
> >Is that true?
>
> Not exactly. The override is in the
> default-page.psml itself, (user=*,
> permission=view).
>
> >What is the scope of the page.security definitions
> and
> >where are they used?
>
> See above.
>
> >2. each folder under /pages directory (including
> >/pages itself) has a folder.metadata file where
> more
> > are defined for that folder.
> >For example, here is pages/folder.metadata:
> >.
> >
> >
> > user
> > view
> >
> >
>
>manager
> >
>
> This should be commented out in M1.
>
> >
> >
> >
> > *
> > view
> >
> >
> >
> >And this is why all users can see the default page.
> >(Is that true?)
>
> It would be the case if default-page.psml did not
> override on its own. To be
> exact, this allows all users to view the folder and
> any content within it
> that does not specify its own security constraints.
> In effect, this is the
> site default for global pages because it is defined
> at the root leve.
>
> >On the other hand, here is
> >pages\Administrative\folder.metadata :
> >
>
RE: Jetspeed2 M1 security setup (was: jetspeed-newbie Roles-Group s-Users)
Marina, Thanks for using the jetspeed user list! Comments below. Randy >-Original Message- >From: Marina >To: 'Jetspeed Users List ' >Sent: 12/6/04 5:06 PM >Subject: RE: Jetspeed2 M1 security setup (was: jetspeed-newbie Roles-Groups-Users)> > >Hi, > > I've successfully built and installed J2 M1 and was >looking into the demo applications to figure out how >to setup access control for portlets/pages. >After checking out some example portlets , like >RoleSecurityTest and Login, and their source code, I >think I have some idea of how to approach the task but >I would like to clarify some topics. > >First, I'll list my assumptions and then ask >questions: > >1. >tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security > file specifies 'Edit'/'View' permissions for the >default Portal's page, defined in default-page.psml The /page.security file defines named security constraints that can be referenced here or in individual page, folder meta data, link, or document set documents. The scope of this file is global across the entire site. References take the form of , (which appear only in /page.security), or . >Thus, this part : > > > admin > view, edit > > >means that only a user with the role 'admin' can edit >the layout of the page. Yes, since this fragment is referenced in a , it applies to all documents in the site. >And this fragment: > > > manager > view > > >means that a user with the role 'manager' can view the >page. Yes, where used with a . >However, anybody can view this default page in reality >- even before a user logs in. You don't need any >special privileges to access >http://localhost:8080/jetspeed to see the page. >My assumption is that it is because security >constraints are "overwritten" in the >pages/folder.metadata file (see below). >Is that true? Not exactly. The override is in the default-page.psml itself, (user=*, permission=view). >What is the scope of the page.security definitions and >where are they used? See above. >2. each folder under /pages directory (including >/pages itself) has a folder.metadata file where more > are defined for that folder. >For example, here is pages/folder.metadata: >. > > > user > view > > >manager > This should be commented out in M1. > > > > * > view > > > >And this is why all users can see the default page. >(Is that true?) It would be the case if default-page.psml did not override on its own. To be exact, this allows all users to view the folder and any content within it that does not specify its own security constraints. In effect, this is the site default for global pages because it is defined at the root leve. >On the other hand, here is >pages\Administrative\folder.metadata : > > Jetspeed Administrative Portlets > > >manager > > > >This folder corresponds to the "Jetspeed >Administrative Portlets" menu item in the 'Folder and >Pages' menu on the left side of the Portal window. >However, it is displayed only when a user with the >'manager' role logged in. Correct. It also requires that its contents only be visible in the manager role as well. >3. There also are security-constraints in the .psml >files themselves. For example, pages/default-page.psml >has: > > > * > view > > Yes, and it is this that enables any user to view the default page, no matter what the folder that the page belongs to is permitted. >4. Also, there are defined in the >portlet.xml files of individual portlets. For example: > >. > > Administrator > admin > > > Manager > manager > > > User > user > > > >and corresponding are defined in the >web.xml file of the portlet application: > > > >The admin role >admin > > >The manager role >manager > > >The user role >user > > Yes, but this is portlet level security within the page. I am not sure if it functional as of M1. If it is, it will apply only to the rendering and actions of the individual portlets. If it is not implemented at this time, it will probably be soon. Let me know if you find out it does not function as per the portlet spec... i'll probably dig in and get it working at some point. >Questions: >-- How do all the security declarations in #1, 2, 3 >and 4 relate to each other? 1-3 are document level security and 4 is restricted to t
RE: Jetspeed2 M1 security setup (was: jetspeed-newbie Roles-Groups-Users)
Hi,
I've successfully built and installed J2 M1 and was
looking into the demo applications to figure out how
to setup access control for portlets/pages.
After checking out some example portlets , like
RoleSecurityTest and Login, and their source code, I
think I have some idea of how to approach the task but
I would like to clarify some topics.
First, I'll list my assumptions and then ask
questions:
1.
tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security
file specifies 'Edit'/'View' permissions for the
default Portal's page, defined in default-page.psml
Thus, this part :
admin
view, edit
means that only a user with the role 'admin' can edit
the layout of the page.
And this fragment:
manager
view
means that a user with the role 'manager' can view the
page.
However, anybody can view this default page in reality
- even before a user logs in. You don't need any
special privileges to access
http://localhost:8080/jetspeed to see the page.
My assumption is that it is because security
constraints are "overwritten" in the
pages/folder.metadata file (see below).
Is that true?
What is the scope of the page.security definitions and
where are they used?
2. each folder under /pages directory (including
/pages itself) has a folder.metadata file where more
are defined for that folder.
For example, here is pages/folder.metadata:
.
user
view
manager
*
view
And this is why all users can see the default page.
(Is that true?)
On the other hand, here is
pages\Administrative\folder.metadata :
Jetspeed Administrative Portlets
manager
This folder corresponds to the "Jetspeed
Administrative Portlets" menu item in the 'Folder and
Pages' menu on the left side of the Portal window.
However, it is displayed only when a user with the
'manager' role logged in.
3. There also are security-constraints in the .psml
files themselves. For example, pages/default-page.psml
has:
*
view
4. Also, there are defined in the
portlet.xml files of individual portlets. For example:
.
Administrator
admin
Manager
manager
User
user
and corresponding are defined in the
web.xml file of the portlet application:
The admin role
admin
The manager role
manager
The user role
user
Questions:
-- How do all the security declarations in #1, 2, 3
and 4 relate to each other?
-- What declarations take precedence?
-- what declarations are mandatory for others to work?
5. By looking at the
jakarta-jetspeed-2-M1\applications\demo\src\webapp\WEB-INF\web.xml
file I noticed that there were two example SSO
servlets registered - SSODemoServlet and
SSOBasicDemoServlet, and they were mapped to /sso-demo
and /sso-basic URLs respectively. Here is how
/sso-basic is protected:
HTTPBasicDemo
/sso-basic/*
tomcat
BASIC
Jetspeed
When I access this servlet as
http://localhost:8080/demo/sso-basic
I am getting a login screen that prompts me to enter
username and password, as expected.
The /sso-demo is not protected in the web.xml and when
accessing it as http://localhost:8080/demo/sso-demo
you just get an authentication error. Source code of
the SSODemoServlet gives some explanation:
/**
* SSODemoServlet - looks for username, password in
the URL for single
* signon to this servlet from a SSO portlet.
* Username request parameter: ssouser
* Password request parameter: ssopw
A few questions here:
-- how can you use these servlets from your portlets
if you want to utilize the Basic authentication
mechanism? Should I just call
RequestDispatcher.include("/demo/sso-basic")? If not -
how else could I use these servlets in portlets? Or,
maybe, not use servlets at all but get the Basic
authentication working for portlets somehow?
-- when supplying incorrect username/password for the
SSOBasicDemo servlet, you get an error page in the
browser and if you try to reload it it would not work
and would not let you to retry login, until you start
a new browser session. I checked my browser settings
(both Mozilla and IE) and made sure they do not cache
pages between requests - still the same problem. I'm
sure it's something very simple - but what?
Thanks fo rreading this till the end :)
Marina
__
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
