You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Glenn Golden <gg...@umich.edu> on 2002/01/25 15:19:12 UTC
Group / Role Portals
Can someone comment on the plans for the following:
>From http://www.bluesunrise.com/jetspeed-docs/jetspeed.htm, in the "Site
markup PSML Tags" section:
"There currently isn't support roles or groups. This will be added in the
next release with the new profiler service."
Who is working on this? What will be supported? When will it be available?
Need any help?
Will this address portals for roles and groups, rather than just portals for
individual users?
Thanks.
- Glenn
--------------------------------------------
Glenn R. Golden, Systems Research Programmer
University of Michigan School of Information
ggolden@umich.edu 734-615-1419
http://www-personal.si.umich.edu/~ggolden/
--------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Group / Role Portals
Posted by Frans Thamura <ft...@yahoo.com>.
Dear All,
Who will be a notulen of Group/Role for next version??
I think this is not good to see all the reply-reply email about Group, and
in couple of months, we see new version???
Frans
----- Original Message -----
From: "David Sean Taylor" <da...@bluesunrise.com>
To: "Jetspeed Developers List" <je...@jakarta.apache.org>
Sent: Monday, January 28, 2002 1:45 PM
Subject: RE: Group / Role Portals
> > > What about having the meeting monday about 18hUTC (this is 19 in
Spain,
> > > and 10am for you). Other people, other timezones?
> > >
> >
> >
> > Can a transcript be make available?
> >
>
> If that time isn't good for you, let us know what works for you.
> But yes, I think I can get a log from mIRC.
>
> David
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Group / Role Portals
Posted by David Sean Taylor <da...@bluesunrise.com>.
> > Can a transcript be make available?
http://www.bluesunrise.com/jetspeed-docs/proposals/Discussion-2002-01-28.txt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Group / Role Portals
Posted by David Sean Taylor <da...@bluesunrise.com>.
> > What about having the meeting monday about 18hUTC (this is 19 in Spain,
> > and 10am for you). Other people, other timezones?
> >
>
>
> Can a transcript be make available?
>
If that time isn't good for you, let us know what works for you.
But yes, I think I can get a log from mIRC.
David
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Group / Role Portals
Posted by Paul Spencer <pa...@apache.org>.
Santiago Gala wrote:
> David Sean Taylor wrote:
>
<snip>
>>> For the moment, I have committed wrappers for portlets. I'm in the
>>> process of removing security checks related with portlets and
>>> controls/controllers (no longer needed) and wrapping the portlets in
>>> the PortletFactory. The code results much cleaner, and we have a
>>> small set of classes where all the semantics of the security is
>>> contained.
>>>
>>> I'm still working in PortletSet wrappers, which will take care of the
>>> PSML security checks (after all, a PSML document is a big portletset.
>>> This is still not cristal clear to me, but everything looks promising.
>>>
>>> Still missing the changes in PSML/registry formats for new security
>>> constraints
>>>
>>
>> Why not put the <security role="user"/> tag as a child element of the
>> <portlets> tag:
Proposal 004 describes a very useable method of defining access to a portal.
>>
>> <portlets xmlns="http://www.apache.org/2000/02/CVS">
>> <security role="user"/>
>>
> A portletset has no name/id currently, I think. So, most things that
> need to refer to a portletset instance use (again currently) the
> controller inside this portletset instead. This is one of the things I'm
> trying to figure out how could be improved.
>
> One possibility I have been thinking about is that the wrapper could
> *seal* the portletset *and* the security constraints together. But this
> still leaves some problems there.
>
Their is an ID in the schema for the PSML. Implementing this would solve
a lot of problems, including having the same portlet exist many times in
one PSML.
>>
>>>>
>>> This is an important thing to be done. Please, concentrate here. It
>>> would be nice if default values are not added to the URL. For instance:
>>>
>>> /group/global --> not added
>>> /role/user --> ? I don not see roles completely yet
>>> /user/<currentUser> --> not added
>>>
>>>> - add jlink methods to build these links from .vm
>>>>
>>> Ditto. It would be great if all URL generating code is put together
>>> in the same class. grep is wonderful for this ;)
>>>
>>>>> Need any help?
>>>>>
>>>> sure
>>>>
>>> I think a IRC meeting would be great, to coordinate this efforts.
>>> Give me a touch and we can try to make it ASAP.
>>>
>>
>> When are you available?
>> What about Irc.whichever.com:6667 #jetspeed
>>
> I'm online now for a small chat. I was thinking in a meeting where other
> people wanting to help could join and clarify items around this and
> another issues.
>
> For instance:
> - auditing, cleaning and testing of URI generation (we are using up to
> three classes for this) would be great, and it could happen completely
> in parallel.
> - auditing, cleaning and testing the customizer stuff so that it uses
> only the current Document object to edit the page is another example.
> (See below)
>
> What about having the meeting monday about 18hUTC (this is 19 in Spain,
> and 10am for you). Other people, other timezones?
>
Can a transcript be make available?
>>
Paul Spencer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Group / Role Portals
Posted by David Sean Taylor <da...@bluesunrise.com>.
> What about having the meeting monday about 18hUTC (this is 19 in Spain,
> and 10am for you). Other people, other timezones?
That works for me.
I'll be at irc.whichever.com #jetspeed
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Group / Role Portals
Posted by Santiago Gala <sg...@hisitech.com>.
David Sean Taylor wrote:
>>Don't put permission checks in the implementation code.
>>
>>The idea I'm implementing is to have wrapper classes which
>>take care of
>>the security checks and isolate internal classes from the
>>"portletAPI"
>>visible classes. This could even allow for unplugging completely the
>>security checks, by just having different wrappers or no
>>wrapper at all.
>>
>
>+ 1 Declarative security + interceptors.
>
Yes. It is the only reasonable way to maintain security when a user can
put whatever class in a portlet.
>
>>For the moment, I have committed wrappers for portlets. I'm in the
>>process of removing security checks related with portlets and
>>controls/controllers (no longer needed) and wrapping the
>>portlets in the
>>PortletFactory. The code results much cleaner, and we have a
>>small set
>>of classes where all the semantics of the security is contained.
>>
>>I'm still working in PortletSet wrappers, which will take care of the
>>PSML security checks (after all, a PSML document is a big portletset.
>>This is still not cristal clear to me, but everything looks promising.
>>
>>Still missing the changes in PSML/registry formats for new security
>>constraints
>>
>
>Why not put the <security role="user"/> tag as a child element of the
><portlets> tag:
>
><portlets xmlns="http://www.apache.org/2000/02/CVS">
> <security role="user"/>
>
A portletset has no name/id currently, I think. So, most things that
need to refer to a portletset instance use (again currently) the
controller inside this portletset instead. This is one of the things I'm
trying to figure out how could be improved.
One possibility I have been thinking about is that the wrapper could
*seal* the portletset *and* the security constraints together. But this
still leaves some problems there.
>
>>>
>>This is an important thing to be done. Please, concentrate here. It
>>would be nice if default values are not added to the URL. For
>>instance:
>>
>>/group/global --> not added
>>/role/user --> ? I don not see roles completely yet
>>/user/<currentUser> --> not added
>>
>>>- add jlink methods to build these links from .vm
>>>
>>Ditto. It would be great if all URL generating code is put
>>together in
>>the same class. grep is wonderful for this ;)
>>
>>>>Need any help?
>>>>
>>>sure
>>>
>>I think a IRC meeting would be great, to coordinate this
>>efforts. Give
>>me a touch and we can try to make it ASAP.
>>
>
>When are you available?
>What about Irc.whichever.com:6667 #jetspeed
>
I'm online now for a small chat. I was thinking in a meeting where other
people wanting to help could join and clarify items around this and
another issues.
For instance:
- auditing, cleaning and testing of URI generation (we are using up to
three classes for this) would be great, and it could happen completely
in parallel.
- auditing, cleaning and testing the customizer stuff so that it uses
only the current Document object to edit the page is another example.
(See below)
What about having the meeting monday about 18hUTC (this is 19 in Spain,
and 10am for you). Other people, other timezones?
>
>>The profile returned by the fallback algorithm should be the
>>repository
>>of all this information. I.E. the customizer should only work
>>with it,
>>
>
>Yes, that is a problem right now - we cant even customize the anon page.
>
In my current test version you can if you login as anon and anon has
edit permission granted ;)
>
>>Rule: all PSML related calls in the request path *must* get
>>the document
>>through data.getProfile(), so all are working on the current one.
>>
>
>+1
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Group / Role Portals
Posted by David Sean Taylor <da...@bluesunrise.com>.
> Don't put permission checks in the implementation code.
>
> The idea I'm implementing is to have wrapper classes which
> take care of
> the security checks and isolate internal classes from the
> "portletAPI"
> visible classes. This could even allow for unplugging completely the
> security checks, by just having different wrappers or no
> wrapper at all.
+ 1 Declarative security + interceptors.
>
> For the moment, I have committed wrappers for portlets. I'm in the
> process of removing security checks related with portlets and
> controls/controllers (no longer needed) and wrapping the
> portlets in the
> PortletFactory. The code results much cleaner, and we have a
> small set
> of classes where all the semantics of the security is contained.
>
> I'm still working in PortletSet wrappers, which will take care of the
> PSML security checks (after all, a PSML document is a big portletset.
> This is still not cristal clear to me, but everything looks promising.
>
> Still missing the changes in PSML/registry formats for new security
> constraints
Why not put the <security role="user"/> tag as a child element of the
<portlets> tag:
<portlets xmlns="http://www.apache.org/2000/02/CVS">
<security role="user"/>
>
> >
> >- correctly rewrite the links to include these parameters
> >
> This is an important thing to be done. Please, concentrate here. It
> would be nice if default values are not added to the URL. For
> instance:
>
> /group/global --> not added
> /role/user --> ? I don not see roles completely yet
> /user/<currentUser> --> not added
>
> >
> >- add jlink methods to build these links from .vm
> >
> Ditto. It would be great if all URL generating code is put
> together in
> the same class. grep is wonderful for this ;)
>
> >
> >>Need any help?
> >>
> >sure
> >
> I think a IRC meeting would be great, to coordinate this
> efforts. Give
> me a touch and we can try to make it ASAP.
>
When are you available?
What about Irc.whichever.com:6667 #jetspeed
> The profile returned by the fallback algorithm should be the
> repository
> of all this information. I.E. the customizer should only work
> with it,
Yes, that is a problem right now - we cant even customize the anon page.
> Rule: all PSML related calls in the request path *must* get
> the document
> through data.getProfile(), so all are working on the current one.
+1
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Group / Role Portals
Posted by Santiago Gala <sg...@hisitech.com>.
David Sean Taylor wrote:
>>"There currently isn't support roles or groups. This will be added in the
>>next release with the new profiler service."
>>
>>Who is working on this? What will be supported? When will it be available?
>>Need any help?
>>
>
>I just started revistiing this feature recently.
>In order for it to complete it, we need to:
>- make persmission checks before granting access to these pages
> (there currently is no way to declare security access to a psml page.
> this would be useful for administrative users to customize users psml,
>and the anon account)
>
Don't put permission checks in the implementation code.
The idea I'm implementing is to have wrapper classes which take care of
the security checks and isolate internal classes from the "portletAPI"
visible classes. This could even allow for unplugging completely the
security checks, by just having different wrappers or no wrapper at all.
For the moment, I have committed wrappers for portlets. I'm in the
process of removing security checks related with portlets and
controls/controllers (no longer needed) and wrapping the portlets in the
PortletFactory. The code results much cleaner, and we have a small set
of classes where all the semantics of the security is contained.
I'm still working in PortletSet wrappers, which will take care of the
PSML security checks (after all, a PSML document is a big portletset.
This is still not cristal clear to me, but everything looks promising.
Still missing the changes in PSML/registry formats for new security
constraints
>
>- correctly rewrite the links to include these parameters
>
This is an important thing to be done. Please, concentrate here. It
would be nice if default values are not added to the URL. For instance:
/group/global --> not added
/role/user --> ? I don not see roles completely yet
/user/<currentUser> --> not added
>
>- add jlink methods to build these links from .vm
>
Ditto. It would be great if all URL generating code is put together in
the same class. grep is wonderful for this ;)
>
>>Need any help?
>>
>sure
>
I think a IRC meeting would be great, to coordinate this efforts. Give
me a touch and we can try to make it ASAP.
>
>>Will this address portals for roles and groups, rather than just portals
>>
>for
>
>>individual users?
>>
>
>Im working on an algorithm in the profiler so that when a user
>doesn't have a requested psml resource, it will fallback and look under any
>role-resources that the user may have of the same name.
>Although this may be useful, it may cause issues for portlets that persist
>parameters in the psml file.
>
The profile returned by the fallback algorithm should be the repository
of all this information. I.E. the customizer should only work with it,
the Persistence service should be hooked from there. If we are coherent
following this behaviour, it will be allright.
Rule: all PSML related calls in the request path *must* get the document
through data.getProfile(), so all are working on the current one.
If we are customising a page, this should be done by requesting this
page in mode customise, instead of mode view. Cleaning the code to
respect these guidelines (again, using grep liberally to find all calls)
should help us a lot.
See my commits later today.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Group / Role Portals
Posted by David Sean Taylor <da...@bluesunrise.com>.
> "There currently isn't support roles or groups. This will be added in the
> next release with the new profiler service."
>
> Who is working on this? What will be supported? When will it be available?
> Need any help?
>
I just started revistiing this feature recently.
In order for it to complete it, we need to:
- make persmission checks before granting access to these pages
(there currently is no way to declare security access to a psml page.
this would be useful for administrative users to customize users psml,
and the anon account)
- correctly rewrite the links to include these parameters
- add jlink methods to build these links from .vm
> Need any help?
sure
> Will this address portals for roles and groups, rather than just portals
for
> individual users?
Im working on an algorithm in the profiler so that when a user
doesn't have a requested psml resource, it will fallback and look under any
role-resources that the user may have of the same name.
Although this may be useful, it may cause issues for portlets that persist
parameters in the psml file.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>