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 Jon Stevens <jo...@latchkey.com> on 2001/06/11 20:16:22 UTC
Security stuff...
on 6/11/01 12:09 AM, "taylor@apache.org" <ta...@apache.org> wrote:
> Criteria criteria = new Criteria();
> RoleSet roles = JetspeedSecurity.getRoles(criteria);
> context.put("roles", roles.getRolesArray());
Why are you putting roles into the context? Security checks should happen on
a permission level, not on a role level.
Also, all of the information for a particular user is already stored in
$data.getACL(). That is the right way to determine if someone has the right
ACL or not...
-jon
--
"Open source is not available to commercial companies."
-Steve Ballmer, CEO Microsoft
<http://www.suntimes.com/output/tech/cst-fin-micro01.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Security stuff...
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
David Sean Taylor wrote:
>>Because a complete pull design would populate the context by reading the
>>
> objects to instanciate from a configuration info, so you would not have to
>
>>explicitely put it the context.
>>
>>An the other hand, Jetspeed does not currently offer a good pull system
>>
>>for portlets: you can use the Turbine pull system within your system but
>>it's bad because the defintion are global for all the application and not
>>portlet specific (and you need to stop restart your app for adding new
>>tools definition which is not adequate for portlet deployment)
>>
>>I started implementing a Pull system for the Velocity Portlet based on
>>registry parameter info, but it's much more complex that the Turbine one
>>because registry entries *are* mutable at runtime and semantics but be
>>extended to add a "shared" scope for sharing context objects between
>>different portlet instances.
>>
>>
> Yes, as in:
>
> <parameter name="action" value="portlets.security.RoleBrowserAction"/>
>
> So now I see Jon's point. Its not really a 'tool' as described in the TR.p.
> Perhaps it would be better to have a session 'security' tool:
>
> tool.session.security = org.apache.jetspeed.tools.Security
>
> When its instantiated at the start of the session, it could do something
> trivial, like check to see if the user has the proper authority to use the
> security tool. (I want to delay the populating of the roles in the template
> to ensure we get the most recent values)
>
Yes, security is a good candidate for implementation as a global Turbine tool
to be used in any portlet/screen/layout that requires this info.
> For the problem you described with portlet deployment,
> why not have a tool.xreg file that can be distributed with a PAR?
> I know it not a 'xml' format like the other xregs, but does turbine have a
> non-centralized, and dynamic approach to tool definition and maintenance? It
> seems like its all based out of the static TR.p, but don't quote me on
> that...
>
Because PAR are part of the new Portlet API and not integrated in HEAD right
now... ;)
> So Im sure where this this fits in...
>
> <parameter name="action" value="portlets.security.RoleBrowserAction"/>
>
> Taking the security example, we wouldn't need the action to pre-populate the
> context. The context would get populated when referenced in the template:
> $security.Roles
>
>
The action parameter is the best way I found right now for implementing MVC
for portlets (short of a complete Pull system):
- if you don't need to override specific Portlet API methods like (the
PortletState methods) you don't need to subclass the VelocityPortlet but
simply associate at runtime through the registry a default template and a
default action for the portlet.
The portlet will always call the action for populating the portlet context
before rendering with the template, thus all context population is handled
in the Action class and dynamically coupled to a template at runtime.
If you want to change your portlet behavior at runtime, you simply need to
write a new action class implementing a new context, modify the registry
entry, and your portlet will automatically use the new action context...
Also note that the VelocityPortletAction extends VelocityAction (which
itself extends ActionEvent) so you can also dynamically call events on this
action the usual Turbine way.
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Security stuff...
Posted by Jon Stevens <jo...@latchkey.com>.
on 6/12/01 10:33 AM, "David Sean Taylor" <da...@bluesunrise.com> wrote:
> So now I see Jon's point. Its not really a 'tool' as described in the TR.p.
> Perhaps it would be better to have a session 'security' tool:
>
> tool.session.security = org.apache.jetspeed.tools.Security
Correct. The goal of pull is to almost never use context.put(). Everything
should be made available through the Tools. Not 100% easy, but it is the
cleanest MVC design because you never have to worry about tying a template
to a Java class.
-jon
--
"Open source is not available to commercial companies."
-Steve Ballmer, CEO Microsoft
<http://www.suntimes.com/output/tech/cst-fin-micro01.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Security stuff...
Posted by David Sean Taylor <da...@bluesunrise.com>.
> Because a complete pull design would populate the context by reading the
objects to instanciate from a configuration info, so you would not have to
> explicitely put it the context.
>
> An the other hand, Jetspeed does not currently offer a good pull system
>
> for portlets: you can use the Turbine pull system within your system but
> it's bad because the defintion are global for all the application and not
> portlet specific (and you need to stop restart your app for adding new
> tools definition which is not adequate for portlet deployment)
>
> I started implementing a Pull system for the Velocity Portlet based on
> registry parameter info, but it's much more complex that the Turbine one
> because registry entries *are* mutable at runtime and semantics but be
> extended to add a "shared" scope for sharing context objects between
> different portlet instances.
>
Yes, as in:
<parameter name="action" value="portlets.security.RoleBrowserAction"/>
So now I see Jon's point. Its not really a 'tool' as described in the TR.p.
Perhaps it would be better to have a session 'security' tool:
tool.session.security = org.apache.jetspeed.tools.Security
When its instantiated at the start of the session, it could do something
trivial, like check to see if the user has the proper authority to use the
security tool. (I want to delay the populating of the roles in the template
to ensure we get the most recent values)
The populating of the roles is done when we they are pulled out of the
context, as in
#foreach ($role in $security.Roles)
For the problem you described with portlet deployment,
why not have a tool.xreg file that can be distributed with a PAR?
I know it not a 'xml' format like the other xregs, but does turbine have a
non-centralized, and dynamic approach to tool definition and maintenance? It
seems like its all based out of the static TR.p, but don't quote me on
that...
So Im sure where this this fits in...
<parameter name="action" value="portlets.security.RoleBrowserAction"/>
Taking the security example, we wouldn't need the action to pre-populate the
context. The context would get populated when referenced in the template:
$security.Roles
> All in all, this will wait for 1.3a3 if ever (unless someone else picks
> this up)
>
I don't know, maybe we can work something out for 1.3a3 :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Security stuff...
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
David Sean Taylor wrote:
>>Not really a pull design...but ok...I get it...
>>
>>
>
> That part works just like flux, except that the velocity screen is an html
> fragment.
>
> Im sorry but I don't understand why it isn't really pull design.
> The action puts the roles into the context, and then the template pulls each
> role out with a '#foreach role in roles' loop.
>
Because a complete pull design would populate the context by reading the
objects to instanciate from a configuration info, so you would not have to
explicitely put it the context.
An the other hand, Jetspeed does not currently offer a good pull system
for portlets: you can use the Turbine pull system within your system but
it's bad because the defintion are global for all the application and not
portlet specific (and you need to stop restart your app for adding new
tools definition which is not adequate for portlet deployment)
I started implementing a Pull system for the Velocity Portlet based on
registry parameter info, but it's much more complex that the Turbine one
because registry entries *are* mutable at runtime and semantics but be
extended to add a "shared" scope for sharing context objects between
different portlet instances.
All in all, this will wait for 1.3a3 if ever (unless someone else picks
this up)
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Security stuff...
Posted by David Sean Taylor <da...@bluesunrise.com>.
> Not really a pull design...but ok...I get it...
>
That part works just like flux, except that the velocity screen is an html
fragment.
Im sorry but I don't understand why it isn't really pull design.
The action puts the roles into the context, and then the template pulls each
role out with a '#foreach role in roles' loop.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Security stuff...
Posted by Jon Stevens <jo...@latchkey.com>.
on 6/11/01 1:18 PM, "David Sean Taylor" <da...@bluesunrise.com> wrote:
> I am putting *all* the roles from the TURBINE_ROLE table into the context.
> Necessary for role-browser.vm to list all the roles in the system.
Not really a pull design...but ok...I get it...
-jon
--
"Open source is not available to commercial companies."
-Steve Ballmer, CEO Microsoft
<http://www.suntimes.com/output/tech/cst-fin-micro01.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Security stuff...
Posted by David Sean Taylor <da...@bluesunrise.com>.
> Why are you putting roles into the context? Security checks should happen
on
> a permission level, not on a role level.
>
Its not a security check....
I am putting *all* the roles from the TURBINE_ROLE table into the context.
Necessary for role-browser.vm to list all the roles in the system.
This portlet is a security management portlet, (like Flux, but
portlet-based) for administrative maintenance of roles. The RoleBrowser is
for an administrator to view and edit all roles in the system. The code you
are looking at is a portlet action that is invoked whenever the portlet is
displayed, see:
org.apache.jetspeed.modules.actions.portlets.VelocityPortlet
(public abstract class VelocityPortletAction extends VelocityAction)
When was the last time you tried Jetspeed anyway?
We are now making use of Velocity for controls, portlets, and controllers.
To try out the security stuff, logon as the 'admin' user, and its under the
'security' tab. Its not yet complete. I still have permissions and a few
more templates to finish.
-- David
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org