Daniel Fagerstrom wrote:
Maybe I should have stated my asumptions, (instead of just having them in my
mind while writing ;) ):
1. In many applications it is your DB content or your documents that is the
natural unit of protectection, rahter than their various combinations and
Peter Royal wrote:
On Wednesday 06 February 2002 07:06 pm, Stefano Mazzocchi wrote:
my personal opinion is that I don't see anything that justifies the
inclusion of AC at the sitemap level since AC is just another action.
i agree. it would make a great pluggable webapp though.
Oh,
That's precisely what I'd like to avoid : write an authenticator for
each and every servlet engine my app has to run on, including those
I
know nothing about :(
This is IMHO a major problem in J2EE. Could JAAS help here ?
IIRC, JAAS know is part of the J2EE. Am I right? Then yes, it
. However if you want to be able to ask Cocoon about
security, ls -l, as you sugested in your RT (Cocoon as OS), it seems
nescesary to have an explicit description of the AC rules. This would
also be useful if one want WebDAV access to Cocoon (where ls -l
corresponds to PROPFIND with some kind of ACL
From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED]]
Greg Weinger wrote:
snip/
Browsers know about the HTTP authentication protocol, and if you
use
that,
they will send you username and password automatically.
Where do you retrieve them? AFAIK they're not available in the
Servlet
Vadim Gritsenko wrote:
snip/
The main problem, I think, is that HTTP requests on their own do not
have the concept a user built into it, which is necessary to perform
user-based access control.
They have, see (ftp://ftp.isi.edu/in-notes/rfc2617.txt), for all the
technical details ;). But it
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
Vadim Gritsenko wrote:
snip/
The main problem, I think, is that HTTP requests on their own do
not
have the concept a user built into it, which is necessary to
perform
user-based access control.
They have, see
snip/
But the servlet spec doesn't allow a servlet to set the user
credentials
in the container.
It will be set for you by the container.
Servlet spec 2.3, SRV.12.5.3 Form Based Authentication:
4. The container attempts to authenticate the user
using the information from the
From: Greg Weinger [mailto:[EMAIL PROTECTED]]
snip/
But the servlet spec doesn't allow a servlet to set the user
credentials in the container.
It will be set for you by the container.
Servlet spec 2.3, SRV.12.5.3 Form Based Authentication:
4. The container attempts to
Vadim Gritsenko wrote:
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
Vadim Gritsenko wrote:
snip/
But the servlet spec doesn't allow a servlet to set the user
credential in the container.
It will be set for you by the container.
There'a misunderstanding here : if authentication is
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
Vadim Gritsenko wrote:
But the servlet spec doesn't allow a servlet to set the user
credential in the container.
It will be set for you by the container.
There'a misunderstanding here : if authentication is performed by an
Action,
On Wed, 6 Feb 2002, Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
So, how can access control (AC) be integrated in Cocoon? And how much
would integration of AC need to affect the current architecture?
These are good questions. I don't have solid answers, but some comments
to share
Hi,
- Original Message -
From: Stefano Mazzocchi [EMAIL PROTECTED]
Daniel Fagerstrom wrote:
snip/
To conclude: I belive that a request URI based AC system have clear
advantages compared to pipeline based AC, and that it could be added
to Cocoon without effecting the contracts
So, how can access control (AC) be integrated in Cocoon? And how
much
would integration of AC need to affect the current architecture?
And, prior to this, what justifies integrating AC into the sitemap
semantic?
How do we determine if AC is something that warrants being promoted to
the
Greg Weinger wrote:
You beat me to the punch, dammit! ;-) Actually, I hadnt thought of
resource-based security, an interesting concept. I strongly
feel that Cocoon
needs to make ACL functionality available, in a clean way. Why
does Tomcat
provide its own database security mechanism?
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
So, how can access control (AC) be integrated in Cocoon? And how much
would integration of AC need to affect the current architecture?
These are good questions. I don't have solid answers, but some comments
to share hoping to sparkle
Greg Weinger wrote:
I see two propositions:
1. Access Control should be integrated into the sitemap.
2. The sitemap is sufficient; we can provide out-of-the-box AC
withthe existing framework, or address that in the upcoming
componentized Cocoon
On Wednesday 06 February 2002 07:06 pm, Stefano Mazzocchi wrote:
my personal opinion is that I don't see anything that justifies the
inclusion of AC at the sitemap level since AC is just another action.
i agree. it would make a great pluggable webapp though.
a blocklet if you will; some
Daniel Fagerstrom wrote:
So, how can access control (AC) be integrated in Cocoon? And how much
would integration of AC need to affect the current architecture?
These are good questions. I don't have solid answers, but some comments
to share hoping to sparkle discussion in the right direction.
On Monday 04 February 2002 02:03 am, Daniel Fagerstrom wrote:
snip/
Protection of resources
---
So what would it mean to protect the resources that are used to
fulfill a request to Cocoon? Consider the following pipeline:
map:match pattern=foo.html
map:generate
To conclude: I belive that a request URI based AC system have
clear advantages compared to pipeline based AC, and that it
could be added to Cocoon without effecting the contracts at
all. I also think that the correct way of handling security
is a resource based system, and that a such
You beat me to the punch, dammit! ;-) Actually, I hadnt thought of
resource-based security, an interesting concept. I strongly feel that Cocoon
needs to make ACL functionality available, in a clean way. Why does Tomcat
provide its own database security mechanism? They're trying to fill a
Colin Britton wrote
snip/
Have you looked at SAML
http://www.oasis-open.org/committees/security/
I took a short look at it and got the impression that it was mainly about
authentication and communication about security, rather than about access
control. I will try to take a deeper look at.
I
Paul Hammant wrote:
I am primarily proposing that we decouple the Cocoon concepts from the
servlet API. We make the usable outside a servlet context. We do
provide a number of ways of wrapping Cocoon as a servlet, but generalize
the real APIs
Interesting enough, Paul, this is already here
On 03.02.2002 02:18:47, Michael Hartle [EMAIL PROTECTED] wrote:
. . .
Last but not least this results into enabling Cocoon in a J2EE
environment, for example.
. . .
I'd rather consider the JMS thing separately from a full J2EE environment - JMS bus
clients by themselves are very easy to
On 02.02.2002 17:14:56, Brian Topping [EMAIL PROTECTED] wrote:
. . .
Methinks JMS is too slow for this as a generalized transport.
. . .
It all depends on how fast/slow the back-end processes are. If we're speaking of a
database query + XSLT pipelines on the back-end, the JMS exchange can be
Brian Topping wrote:
[sorry if this has been discussed before...]
I've put some thought into something similar in the CMS space, but
didn't really realize that it might have been on the same path as the
Cocoon as OS thread until just a few minutes ago. A Cocoon
underlayment of sorts,
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
I mean: if part of a CMS is built as cocoon webapp (and I think we all
see why this would be a benefit, both on the frontend and on the
backend), it should be possible for this webapp not only to
specify its
sitemap and what cocoon
Stefano et al,
I'm reading this thread with interest. If I may add a view as someone
who is most interested in Phoenix and the apps hosted on it.
Consider JAMES (the mail server) what if it wanted to render HTML
emails/news postings with XSP/XSL. There are ways that it could work
On Saturday 02 February 2002 16:49, Paul Hammant wrote:
. . .
I see the separation of Cocoon into three/four core parts:
. . .
2.1) A lightweight servlet that delagates via RMI or JNDI (you folks
heard of AltRMI yet) to the engine elsewhere
. . .
I don't know much about Phoenix but this rings
-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 02, 2002 10:56 AM
The ultimate scalable mechanism IMHO is sending requests to a
JMS bus queue,
where they can be picked up by a farm of engines for processing.
Methinks JMS is too
Bertrand Delacretaz wrote:
The ultimate scalable mechanism IMHO is sending requests to a JMS bus queue,
where they can be picked up by a farm of engines for processing.
(er, no, I'm not volunteering to implement it right now, just thinking
outloud ;-)
Last but not least this results into
that might really make it accessible to the masses. And it
would be a blast to work on!
Brian
-Original Message-
From: Greg Weinger [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 28, 2002 10:00 PM
To: [EMAIL PROTECTED]
Subject: [RT] Cocoon as OS
One of the most intriguing and provocative
Greg Weinger wrote:
If I understood correctly, your stream of thought was something on the
line of:
1) Unix uses pipelines, Cocoon uses pipelines.
2) Unix has interactive shells to compose those pipelines (or the
ability to run scripts for those shells), why shouldn't cocoon have
On Wed, 30 Jan 2002, Stefano Mazzocchi wrote:
3) The analogy of the sitemap to a filesystem (the sitemap is like a
specialized filesystem for URIs) could be a very powerful explanation
to first-time and beginner cocoon users. Maybe I should have said,
Sitemap as Filesystem instead of
Matt Sergeant wrote:
On Wed, 30 Jan 2002, Stefano Mazzocchi wrote:
3) The analogy of the sitemap to a filesystem (the sitemap is like a
specialized filesystem for URIs) could be a very powerful explanation
to first-time and beginner cocoon users. Maybe I should have said,
On Wed, 30 Jan 2002, Stefano Mazzocchi wrote:
Matt Sergeant wrote:
On Wed, 30 Jan 2002, Stefano Mazzocchi wrote:
3) The analogy of the sitemap to a filesystem (the sitemap is like a
specialized filesystem for URIs) could be a very powerful explanation
to first-time and
On Wed, 30 Jan 2002, Stefano Mazzocchi wrote:
I agree with you, but only one thing: httpd.conf seems to suggest
one2one URI2filesystem matching and only a module provides rewriting
Well it's hard to call mod_alias a module - I can't imagine many serious
Apache server being compiled without
[snipped lots of wild yet very interesting thoughts]
If I understood correctly, your stream of thought was something on the
line of:
1) Unix uses pipelines, Cocoon uses pipelines.
2) Unix has interactive shells to compose those pipelines (or the
ability to run scripts for those shells), why
If I understood correctly, your stream of thought was something on the
line of:
1) Unix uses pipelines, Cocoon uses pipelines.
2) Unix has interactive shells to compose those pipelines (or the
ability to run scripts for those shells), why shouldn't cocoon have
the
same concept?
3) The
-Original Message-
From: Greg Weinger [mailto:[EMAIL PROTECTED]]
Sent: dinsdag 29 januari 2002 22:28
To: [EMAIL PROTECTED]
Subject: RE: [RT] Cocoon as OS
Some of these thoughts started out from thinking about the question,
What is Cocoon? which I do because I'm always trying
One of the most intriguing and provocative comparisons I've heard about
Cocoon is to Unix, in that it provides a host of small
generic components that can be piped together to create new output. Cocoon is like an operating system for
web resources.
This analogy got me started on a line
42 matches
Mail list logo
