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 David Sean Taylor <da...@bluesunrise.com> on 2002/06/21 07:42:34 UTC
Security_14 Branch Merge
We (Paul and I) would like to merge the new Security_14 branch into the
cvs main branch.
All the unit tests have passed.
Could you please review the branch before we merge.
We would like to merge the branch in by Tuesday June 25.
Thanks
To check out the branch:
cvs co -r security_14 jakarta-jetspeed
The proposal is located in the cvs at:
http://cvs.apache.org/viewcvs/jakarta-jetspeed/proposals/Security.txt?re
v=1.5&content-type=text/vnd.viewcvs-markup
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security_14 Branch Merge
Posted by David Sean Taylor <da...@bluesunrise.com>.
...
> -----Original Message-----
> From: Santiago Gala [mailto:sgala@hisitech.com]
> Sent: Monday, June 24, 2002 12:08 PM
> To: Jetspeed Developers List
> Subject: Re: Security_14 Branch Merge
>
> >I prefer that we all work off the same cvs head in a common
> goal. Wrt
> >Realms, you have a valid argument, and as stated above, there are
> >standards (HTTP, Java) that support your argument.
> >
> As you may know, I am supporting a derivative product which uses
> jetspeed. We need to deliver a portal with this requirements
> now. While
> I prefer to work together in HEAD, I am in the middle of testing and
> integration of a new release. I could do two things:
>
> 1- freeze my jetspeed release date and keep private changes (say, on
> Jetspeed 20020625 or whatever) until the moment we can resynchronize
> versions.
> 2- open a branch and keep having changes that can be mixed together
> gradually.
>
> From my previous experience, 2 is much better than one. So,
> even if we
> work together, I need this branch to keep the current
> security operative
> while changes are merged.
>
> Don't think "fork" when I propose a branch. Rather, think
> about better
> merging abilities later on. In a sense, it is reversing our current
> roles: instead of you two working on a branch and me touching
> HEAD, it
> will be the other way round. But I don't think it would be a
> long term
> branch.
(Sorry for taking so long to respond, had a nasty threading bug arise on
another project today....)
+1
Before we merge, I can label the current Jetspeed cvs "1.3a3", and you
can start your branch off of that (before the merge) if that's
alright...
>
> >Lets try to find something we can agree upon first. Give us a little
> >time to find something that meets everyones needs Im just
> not convinced
> >that the best way is to change the API to always receive a
> realm as a
> >parameter to all the API calls.
> >
> I don't have clear views on how to achieve this. I have been thinking
> about having a /group/XXX parameter (optional means /group/global ->
> whatever name, global is hardcoded in current Turbine model
> and looks a
> good name), and having the psml directory/db structure carrying a
> "group" hierarchy. A PSML would be checked in the realm associated to
> the group it is under. A (hypothetical) PortletSet-imported-fragment
> could have a security reference stating the group/realm under which
> checks would be done, useful for "read-only", or imported content. (I
> use group, but it could be another name. Think "company" or
> "division".)
This changes the current layout of PSML. I am open to this, but what
happens to existing 'group' PSML resources?
>
> The only conceptual problems remaining to be solved are:
> - Which page will be shown after login (i.e. is there a
> "primary"/"default" group/realm? )
Do you logon to a realm? And if you don't, you go to the user's default
realm.
Then we need another relationship, user to default-realm....
> - After a user registers, which groups/realms does she belong
> to? (For
> our scenarios, users will register in a "global" group (like
> now), and
> the admin would grant new group permissions.
>
This seems like a lot more work.
Can we do this in two phases, a single realm phase and then a
multi-realm phase?
> >Please review the current interfaces and make suggestions as
> to how you
> >see realms in the api. Also review the registry.xreg format.
> >I will start doing some research on realms.
> >Its great that you are participating in the proposal now,
> and Im happy
> >to modify the proposal to meet your design
> >
> >
> I have been too overloaded :-( . I concentrated my current efforts in
> getting rid of my very old patches pending (I still have
> some, which I'm
> not sure if are still needed/relevant).
>
> Now I have got rid of most "ready" code, I'm working to get into
> synchrony. I still have not found time to review extensively the
> proposal and code in 1.4.
>
> The reason why I proposed a branch is two-fold:
> - non blocking behaviour WRT your efforts.
> - don't throwing away my (slow,painful) implementation
>
> I agree that your proposal looks cleaner than the current model, and
> decouples us from the Turbine security model, which I don't like very
> much. I'm not sure the public APIs need to be changed. It would be a
> matter of knowing which is the relevant group for each
> checkPermission()
> call, which could be a property of portletsets (both top portletsets,
> for the pages, and "imported" portletsets, for shared content.
>
> I'm still thinking about the merge, so I don't want to
> venture ways to
> do it yet. The whole idea of the branch is to enable more thinking on
> how to do it.
>
> I hope we are able to put Jetspeed in better shape soon :-)
Yes, me too. I think the new security will help a lot of us move towards
that goal, but it seems to create more problems for you since it doesn't
support realms. I didn't get much of a chance to think about realms
today. Lets talk again tomorrow.
David
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security_14 Branch Merge
Posted by Santiago Gala <sg...@hisitech.com>.
David Sean Taylor wrote:
>Santiago,
>
>
>
>>>Nope. Turbine's model is very specific.
>>>We've had so many users confused with the USER/GROUP/ROLE
>>>
>>>
>>model, and it
>>
>>
>>>always leads to disagreement. So the new model is flat, no 3-way
>>>relationship.
>>>
>>>
>>>
>>>
>>This leaves us with a "one portal, one set of permissions"
>>model, that
>>has a lot of problems.
>>
>>While I agree that Turbine's model is confusing (group should
>>be really
>>called "Realm", after HTTP Realm), I think we need such a concept.
>>
>>
>
>I agree that this concept is very important in large portal sites.
>The requirements of smaller portals may be simply one realm / security
>policy per portal.
>I would like to support the concept of realms, but not to overload the
>API with this concept.
>Perhaps we can find another way to configure the context of the realm.
>I need to give this some thought...
>
>
>
>>We have no way to split a portal into areas for which users
>>having the
>>same role do have different permissions, much in the way that you can
>>erase a file in your home directory, but *not* in a different user's
>>home. (You have the user role in both cases, but the resources have
>>different "labels", those owned by jane, and those owned by james.
>>
>>This means the security manager will be forced to use hundreds of
>>different roles, like "salesadmin", and mark PSMLs like
>>role="salesadmin" if you need to have different pages managed by
>>different people. Do you have an idea on how to implement this?
>>
>>
>>
>>>
>>>
>>>
>>>
>
>
>
>>What remains to be committed is:
>>
>>(I'll call turbine's groups realms, since it is much more
>>close to how
>>they behave.)
>>
>>- Secure portletset (PSML) access.
>>
>>
>
>You can do this now with the registry access controller.
>Put a security-ref on the the top-level <portlets> collection in a psml
>file.
>See security.xreg and the psml used in the unit tests
>
>
I will be looking into this ASAP.
>
>
>>- Ensure that every request is executed in the context of a
>>realm, i.e.
>>that we can have different permissions for different pages.
>>- Change the admin portlets so that users are given roles in
>>different
>>realms, not just in the "Jetspeed" one.
>>
>>
>>Since I see the strength of your arguments, and I don't want to be
>>stopping other work, I thing we can do what follows:
>>
>>- Tag and open a branch before you start the merge.
>>- Let me use this branch to have a working implementation of
>>the older
>>model.
>>- Have it migrated to the new model, and maybe mixed, if it is
>>considered relevant.
>>
>>
>
>I prefer that we all work off the same cvs head in a common goal.
>Wrt Realms, you have a valid argument, and as stated above, there are
>standards (HTTP, Java) that support your argument.
>
As you may know, I am supporting a derivative product which uses
jetspeed. We need to deliver a portal with this requirements now. While
I prefer to work together in HEAD, I am in the middle of testing and
integration of a new release. I could do two things:
1- freeze my jetspeed release date and keep private changes (say, on
Jetspeed 20020625 or whatever) until the moment we can resynchronize
versions.
2- open a branch and keep having changes that can be mixed together
gradually.
From my previous experience, 2 is much better than one. So, even if we
work together, I need this branch to keep the current security operative
while changes are merged.
Don't think "fork" when I propose a branch. Rather, think about better
merging abilities later on. In a sense, it is reversing our current
roles: instead of you two working on a branch and me touching HEAD, it
will be the other way round. But I don't think it would be a long term
branch.
>Lets try to find something we can agree upon first. Give us a little
>time to find something that meets everyones needs
>Im just not convinced that the best way is to change the API to always
>receive a realm as a parameter to all the API calls.
>
I don't have clear views on how to achieve this. I have been thinking
about having a /group/XXX parameter (optional means /group/global ->
whatever name, global is hardcoded in current Turbine model and looks a
good name), and having the psml directory/db structure carrying a
"group" hierarchy. A PSML would be checked in the realm associated to
the group it is under. A (hypothetical) PortletSet-imported-fragment
could have a security reference stating the group/realm under which
checks would be done, useful for "read-only", or imported content. (I
use group, but it could be another name. Think "company" or "division".)
The only conceptual problems remaining to be solved are:
- Which page will be shown after login (i.e. is there a
"primary"/"default" group/realm? )
- After a user registers, which groups/realms does she belong to? (For
our scenarios, users will register in a "global" group (like now), and
the admin would grant new group permissions.
>Please review the current interfaces and make suggestions as to how you
>see realms in the api.
>Also review the registry.xreg format.
>I will start doing some research on realms.
>Its great that you are participating in the proposal now, and Im happy
>to modify the proposal to meet your design
>
>
I have been too overloaded :-( . I concentrated my current efforts in
getting rid of my very old patches pending (I still have some, which I'm
not sure if are still needed/relevant).
Now I have got rid of most "ready" code, I'm working to get into
synchrony. I still have not found time to review extensively the
proposal and code in 1.4.
The reason why I proposed a branch is two-fold:
- non blocking behaviour WRT your efforts.
- don't throwing away my (slow,painful) implementation
I agree that your proposal looks cleaner than the current model, and
decouples us from the Turbine security model, which I don't like very
much. I'm not sure the public APIs need to be changed. It would be a
matter of knowing which is the relevant group for each checkPermission()
call, which could be a property of portletsets (both top portletsets,
for the pages, and "imported" portletsets, for shared content.
I'm still thinking about the merge, so I don't want to venture ways to
do it yet. The whole idea of the branch is to enable more thinking on
how to do it.
I hope we are able to put Jetspeed in better shape soon :-)
>David
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security_14 Branch Merge
Posted by David Sean Taylor <da...@bluesunrise.com>.
Santiago,
> >Nope. Turbine's model is very specific.
> >We've had so many users confused with the USER/GROUP/ROLE
> model, and it
> >always leads to disagreement. So the new model is flat, no 3-way
> >relationship.
> >
> >
> This leaves us with a "one portal, one set of permissions"
> model, that
> has a lot of problems.
>
> While I agree that Turbine's model is confusing (group should
> be really
> called "Realm", after HTTP Realm), I think we need such a concept.
I agree that this concept is very important in large portal sites.
The requirements of smaller portals may be simply one realm / security
policy per portal.
I would like to support the concept of realms, but not to overload the
API with this concept.
Perhaps we can find another way to configure the context of the realm.
I need to give this some thought...
> We have no way to split a portal into areas for which users
> having the
> same role do have different permissions, much in the way that you can
> erase a file in your home directory, but *not* in a different user's
> home. (You have the user role in both cases, but the resources have
> different "labels", those owned by jane, and those owned by james.
>
> This means the security manager will be forced to use hundreds of
> different roles, like "salesadmin", and mark PSMLs like
> role="salesadmin" if you need to have different pages managed by
> different people. Do you have an idea on how to implement this?
>
> >
> >
> What remains to be committed is:
>
> (I'll call turbine's groups realms, since it is much more
> close to how
> they behave.)
>
> - Secure portletset (PSML) access.
You can do this now with the registry access controller.
Put a security-ref on the the top-level <portlets> collection in a psml
file.
See security.xreg and the psml used in the unit tests
> - Ensure that every request is executed in the context of a
> realm, i.e.
> that we can have different permissions for different pages.
> - Change the admin portlets so that users are given roles in
> different
> realms, not just in the "Jetspeed" one.
>
>
> Since I see the strength of your arguments, and I don't want to be
> stopping other work, I thing we can do what follows:
>
> - Tag and open a branch before you start the merge.
> - Let me use this branch to have a working implementation of
> the older
> model.
> - Have it migrated to the new model, and maybe mixed, if it is
> considered relevant.
I prefer that we all work off the same cvs head in a common goal.
Wrt Realms, you have a valid argument, and as stated above, there are
standards (HTTP, Java) that support your argument.
Lets try to find something we can agree upon first. Give us a little
time to find something that meets everyones needs
Im just not convinced that the best way is to change the API to always
receive a realm as a parameter to all the API calls.
Please review the current interfaces and make suggestions as to how you
see realms in the api.
Also review the registry.xreg format.
I will start doing some research on realms.
Its great that you are participating in the proposal now, and Im happy
to modify the proposal to meet your design
David
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security_14 Branch Merge
Posted by Santiago Gala <sg...@hisitech.com>.
David Sean Taylor wrote:
>See comments below
>
>
>
>>-----Original Message-----
>>From: Santiago Gala [mailto:sgala@hisitech.com]
>>Sent: Monday, June 24, 2002 7:53 AM
>>To: Jetspeed Developers List
>>Subject: Re: Security_14 Branch Merge
>>
>>
>>David Sean Taylor wrote:
>>
>>
>>
>>>We (Paul and I) would like to merge the new Security_14
>>>
>>>
>>branch into the
>>
>>
>>>cvs main branch. All the unit tests have passed.
>>>Could you please review the branch before we merge.
>>>We would like to merge the branch in by Tuesday June 25.
>>>
>>>
>>>
>>>
>>I have been looking at the branch, but I have not been able
>>to clarify
>>some important issues:
>>
>>- Is there any way to have groups of pages (realms, turbine's groups)
>>having different permissions for users with the same role?
>>Going back to
>>the current turbine model, can I have users having role
>>"admin" in the
>>group "production" having no "admin" rights in different groups, for
>>instance, in the "global" group or in a "sales" group? This
>>is mandatory
>>for any portal where there are different pages for different kinds of
>>users without having a mess of "productionadmin", "salesuser",
>>"salesadmin", etc. roles, and even more mess with the
>>administration of
>>the PSML resources and portlets.
>>
>>
>
>Nope. Turbine's model is very specific.
>We've had so many users confused with the USER/GROUP/ROLE model, and it
>always leads to disagreement.
>So the new model is flat, no 3-way relationship.
>
>
This leaves us with a "one portal, one set of permissions" model, that
has a lot of problems.
While I agree that Turbine's model is confusing (group should be really
called "Realm", after HTTP Realm), I think we need such a concept.
>However, the Turbine security service could be easily extended to
>support this approach, since I still use the TURBINE tables in the
>default Turbine impls
>Just override a few checkPermission methods. The Group interface could
>also easily be extended to receive a Role parameter if you need such a
>thing.
>
>
>
>>- I can't understand how the "group" thing in the Security
>>proposal fits
>>in. I need more time to study it.
>>
>>
>
>Exactly, the group "thing". Its still undefinable after all this time..
>
>Groups can be used for whatever you'd like.
>The new security model simply provides an optional maintenance api.
>The goal of the new security proposal was to decouple from Turbine
>security, and faciliate the needs of so many users to plug in their own
>security.
>
I agree. For what I have seen, it looks that the new API is much cleaner
and makes less assumptions. I'm thinking how portal resources could be
"labelled" so that permissions are checked against this label. This
requires a kind of three-way relationship between
user-role-realm/domain, so that user administration is cleaner. This is
specially true for integrator portals, where a company sets up a portal
with users from different companies, and part of the contents are shared
while other contents are private to each "realm/domain/group". This
applies, for instance, to corporate portals where users of different
divisions do have different pages with different sets of permissions.
Using different roles to model this situation leads to an administrative
nightmare WRT roles and permissions.
>Specifically, authorization and authentication are made pluggable and
>extensible.
>Groups are often not required by many security impls, so why force this
>concept upon users
>
>
I agree that the naming of Turbine groups is very unfortunate, but we
still need something that *every* security implementation has:
- HTTP has Realms (a set of resources (pages) with common security policies)
- The servlet spec has the concept of a Webapp as the security realm (or
domain)
- Java has CodeBase ( " " )
We have no way to split a portal into areas for which users having the
same role do have different permissions, much in the way that you can
erase a file in your home directory, but *not* in a different user's
home. (You have the user role in both cases, but the resources have
different "labels", those owned by jane, and those owned by james.
This means the security manager will be forced to use hundreds of
different roles, like "salesadmin", and mark PSMLs like
role="salesadmin" if you need to have different pages managed by
different people. Do you have an idea on how to implement this?
>
>
>>- Do you feel that functional testing has gone far enough? I have not
>>had time to compare both implementations, let it alone to run it with
>>any realistic portal.
>>
>>
>
>We have passed all the unit tests in the system.
>I believe Glenn is just starting to test secure access to PSML pages.
>I agree, it needs more testing. I'd like to merge to the cvs head since
>it will get more testing there and quicker acceptance.
>The cvs head isn't a production release, it's where development is
>ongoing.
>
>
>
>>I think merging the code while we still don't have any (positive or
>>negative) feed back is risky.
>>
>>I still have ongoing changes related with the current security model,
>>and I would like to be sure that the new model is at least as
>>expressive
>>as the previous one.
>>
>>
>>
>
>The new model is much more expressive. Take a look at the registry-based
>authorization.
>The model is no longer tied to the Turbine security model, which where,
>I believe, you take issue since we no longer support USER/GROUP/ROLE.
>Again, from the requirements of users that I worked with, and from users
>on the list, people found this model confusing and too specific to one
>application.
>
>
I agree with the confusing terminology.
>With due respect to your ongoing changes, these changes have been
>ongoing for a very long time now.
>Could you formalise a list of what exactly it is that you are doing, and
>add it to the security proposal?
>Otherwise I request that you please step back and let others, who have
>more time, participate and commit in this area.
>
>
What remains to be committed is:
(I'll call turbine's groups realms, since it is much more close to how
they behave.)
- Secure portletset (PSML) access.
- Ensure that every request is executed in the context of a realm, i.e.
that we can have different permissions for different pages.
- Change the admin portlets so that users are given roles in different
realms, not just in the "Jetspeed" one.
Since I see the strength of your arguments, and I don't want to be
stopping other work, I thing we can do what follows:
- Tag and open a branch before you start the merge.
- Let me use this branch to have a working implementation of the older
model.
- Have it migrated to the new model, and maybe mixed, if it is
considered relevant.
What do you think?
Regards,
Santiago
>Regards,
>
>David
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security_14 Branch Merge
Posted by David Sean Taylor <da...@bluesunrise.com>.
See comments below
> -----Original Message-----
> From: Santiago Gala [mailto:sgala@hisitech.com]
> Sent: Monday, June 24, 2002 7:53 AM
> To: Jetspeed Developers List
> Subject: Re: Security_14 Branch Merge
>
>
> David Sean Taylor wrote:
>
> >We (Paul and I) would like to merge the new Security_14
> branch into the
> >cvs main branch. All the unit tests have passed.
> >Could you please review the branch before we merge.
> >We would like to merge the branch in by Tuesday June 25.
> >
> >
> I have been looking at the branch, but I have not been able
> to clarify
> some important issues:
>
> - Is there any way to have groups of pages (realms, turbine's groups)
> having different permissions for users with the same role?
> Going back to
> the current turbine model, can I have users having role
> "admin" in the
> group "production" having no "admin" rights in different groups, for
> instance, in the "global" group or in a "sales" group? This
> is mandatory
> for any portal where there are different pages for different kinds of
> users without having a mess of "productionadmin", "salesuser",
> "salesadmin", etc. roles, and even more mess with the
> administration of
> the PSML resources and portlets.
Nope. Turbine's model is very specific.
We've had so many users confused with the USER/GROUP/ROLE model, and it
always leads to disagreement.
So the new model is flat, no 3-way relationship.
However, the Turbine security service could be easily extended to
support this approach, since I still use the TURBINE tables in the
default Turbine impls
Just override a few checkPermission methods. The Group interface could
also easily be extended to receive a Role parameter if you need such a
thing.
> - I can't understand how the "group" thing in the Security
> proposal fits
> in. I need more time to study it.
Exactly, the group "thing". Its still undefinable after all this time..
Groups can be used for whatever you'd like.
The new security model simply provides an optional maintenance api.
The goal of the new security proposal was to decouple from Turbine
security, and faciliate the needs of so many users to plug in their own
security.
Specifically, authorization and authentication are made pluggable and
extensible.
Groups are often not required by many security impls, so why force this
concept upon users
> - Do you feel that functional testing has gone far enough? I have not
> had time to compare both implementations, let it alone to run it with
> any realistic portal.
We have passed all the unit tests in the system.
I believe Glenn is just starting to test secure access to PSML pages.
I agree, it needs more testing. I'd like to merge to the cvs head since
it will get more testing there and quicker acceptance.
The cvs head isn't a production release, it's where development is
ongoing.
>
> I think merging the code while we still don't have any (positive or
> negative) feed back is risky.
>
> I still have ongoing changes related with the current security model,
> and I would like to be sure that the new model is at least as
> expressive
> as the previous one.
>
The new model is much more expressive. Take a look at the registry-based
authorization.
The model is no longer tied to the Turbine security model, which where,
I believe, you take issue since we no longer support USER/GROUP/ROLE.
Again, from the requirements of users that I worked with, and from users
on the list, people found this model confusing and too specific to one
application.
With due respect to your ongoing changes, these changes have been
ongoing for a very long time now.
Could you formalise a list of what exactly it is that you are doing, and
add it to the security proposal?
Otherwise I request that you please step back and let others, who have
more time, participate and commit in this area.
Regards,
David
>
> Regards, Santiago
>
> >Thanks
> >
> >To check out the branch:
> >
> >cvs co -r security_14 jakarta-jetspeed
> >
> >The proposal is located in the cvs at:
> >
> >http://cvs.apache.org/viewcvs/jakarta-jetspeed/proposals/Secu
rity.txt?r
>e
>v=1.5&content-type=text/vnd.viewcvs-markup
>
>
A note for people looking at the proposal: The version in head is *not*
the latest. Use the cvs or the one in the checkout with the branch.
>
>
>
>
>
>--
>To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security_14 Branch Merge
Posted by Santiago Gala <sg...@hisitech.com>.
David Sean Taylor wrote:
>We (Paul and I) would like to merge the new Security_14 branch into the
>cvs main branch.
>All the unit tests have passed.
>Could you please review the branch before we merge.
>We would like to merge the branch in by Tuesday June 25.
>
>
I have been looking at the branch, but I have not been able to clarify
some important issues:
- Is there any way to have groups of pages (realms, turbine's groups)
having different permissions for users with the same role? Going back to
the current turbine model, can I have users having role "admin" in the
group "production" having no "admin" rights in different groups, for
instance, in the "global" group or in a "sales" group? This is mandatory
for any portal where there are different pages for different kinds of
users without having a mess of "productionadmin", "salesuser",
"salesadmin", etc. roles, and even more mess with the administration of
the PSML resources and portlets.
- I can't understand how the "group" thing in the Security proposal fits
in. I need more time to study it.
- Do you feel that functional testing has gone far enough? I have not
had time to compare both implementations, let it alone to run it with
any realistic portal.
I think merging the code while we still don't have any (positive or
negative) feed back is risky.
I still have ongoing changes related with the current security model,
and I would like to be sure that the new model is at least as expressive
as the previous one.
Regards, Santiago
>Thanks
>
>To check out the branch:
>
>cvs co -r security_14 jakarta-jetspeed
>
>The proposal is located in the cvs at:
>
>http://cvs.apache.org/viewcvs/jakarta-jetspeed/proposals/Security.txt?re
>v=1.5&content-type=text/vnd.viewcvs-markup
>
>
A note for people looking at the proposal: The version in head is *not*
the latest. Use the cvs or the one in the checkout with the branch.
>
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problems setting content type to application/vnd.ms-excel
Posted by Santiago Gala <sg...@hisitech.com>.
Jeff Marshall wrote:
> I am trying to sent the content type in a portlet doExcelselect method
> using :
> <<<
> MimeType mt = new MimeType("application/vnd.ms-excel");
> // rundata.setContentType( mt.getContentType() );
> // rundata.setCharSet( mt.getCharSet() );
> rundata.setContentType("application/vnd.ms-excel");
> //
> rundata.getResponse().setContentType("application/vnd.ms-excel");
> VelocityPortlet portlet =
> (VelocityPortlet)context.get("portlet");
> Log.debug("portlet supports type "+portlet.supportsType(mt));
>
> // implementation junk
>
> // just before return
> Log.debug("doExcelselect content type is
> "+rundata.getContentType());
>
> The portlet.supportsType() returns true, and the last debug
> rundata.getContentType() returns application/vnd.ms-excel.
>
> Does this logic work?
The problem is that typically a portlet is shown together with a set of
other portlets, and (in jetspeed's current implementation) also inside a
Turbine page, with navigations. All of this code should work with the
same markup type.
To achieve this, you will need to specify your page to use a "blank"
layout, with no navigations, and a portlet without title or other
decoration.
In current Jetspeed code, ContentType is set in the JetspeedVelocityPage
and JetspeedLayout code, according to the CapabilityMap.
>
> The idea is to build an html table, set the content type to
> application/vnd.ms-excel, and let the browser show the spreadsheet
> (I.E) or ask for an application (Netscape).
The "text/tab-separated-values" IANA Media type could be better suited
for this purpose, but I wonder is Excel would support it appropriately
without reconfiguration.
>
> This works in other (non-Jetspeed) servlets, and I am wondering if
> anyone has had success with this, or something like it.
>
> Thanks
> Jeff
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Problems setting content type to application/vnd.ms-excel
Posted by Jeff Marshall <jm...@libertysite.com>.
I am trying to sent the content type in a portlet doExcelselect method
using :
<<<
MimeType mt = new MimeType("application/vnd.ms-excel");
// rundata.setContentType( mt.getContentType() );
// rundata.setCharSet( mt.getCharSet() );
rundata.setContentType("application/vnd.ms-excel");
// rundata.getResponse().setContentType("application/vnd.ms-excel");
VelocityPortlet portlet = (VelocityPortlet)context.get("portlet");
Log.debug("portlet supports type "+portlet.supportsType(mt));
// implementation junk
// just before return
Log.debug("doExcelselect content type is
"+rundata.getContentType());
The portlet.supportsType() returns true, and the last debug
rundata.getContentType() returns application/vnd.ms-excel.
Does this logic work?
The idea is to build an html table, set the content type to
application/vnd.ms-excel, and let the browser show the spreadsheet (I.E)
or ask for an application (Netscape).
This works in other (non-Jetspeed) servlets, and I am wondering if
anyone has had success with this, or something like it.
Thanks
Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security_14 Branch Merge
Posted by David Sean Taylor <da...@bluesunrise.com>.
> PS 1-0!
Hey now, 2-1! ;-Q
> -----Original Message-----
> From: Chris Kimpton [mailto:kimptoc_mail@yahoo.com]
> Sent: Friday, June 21, 2002 12:12 AM
> To: Jetspeed Developers List
> Subject: Re: Security_14 Branch Merge
>
>
> Hi,
>
> I am not going to get a chance to look at before then - go
> for it and let the world decide ;-)
>
> Chris
>
> PS 1-0!
>
> --- David Sean Taylor <da...@bluesunrise.com> wrote:
> > We (Paul and I) would like to merge the new Security_14 branch into
> > the cvs main branch.
> > All the unit tests have passed.
> > Could you please review the branch before we merge.
> > We would like to merge the branch in by Tuesday June 25.
> >
> > Thanks
> >
> > To check out the branch:
> >
> > cvs co -r security_14 jakarta-jetspeed
> >
> > The proposal is located in the cvs at:
> >
> >
> http://cvs.apache.org/viewcvs/jakarta-jetspeed/proposals/Secur
ity.txt?re
> v=1.5&content-type=text/vnd.viewcvs-markup
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
=====
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security_14 Branch Merge
Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,
I am not going to get a chance to look at before then - go for it and
let the world decide ;-)
Chris
PS 1-0!
--- David Sean Taylor <da...@bluesunrise.com> wrote:
> We (Paul and I) would like to merge the new Security_14 branch into
> the
> cvs main branch.
> All the unit tests have passed.
> Could you please review the branch before we merge.
> We would like to merge the branch in by Tuesday June 25.
>
> Thanks
>
> To check out the branch:
>
> cvs co -r security_14 jakarta-jetspeed
>
> The proposal is located in the cvs at:
>
>
http://cvs.apache.org/viewcvs/jakarta-jetspeed/proposals/Security.txt?re
> v=1.5&content-type=text/vnd.viewcvs-markup
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
=====
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>