You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/10/23 14:41:46 UTC
[proposal] Doco
First of all, sorry for the massive cross-post, but I think it is going
to be a great opportunity for all the communities involved to show off
their potentials with the apache infrastructure.
The proposal is about the creation of a content management system for
apache projects, codenamed "Doco"
The features will be:
1) super-easy editing (should satisfy wiki lovers)
2) minimal, efficient and secure workflow (should satisfy board@
security concerns)
3) should allow the creation of static content (should satisfy
infrastructure@ and mirror@ concerns)
4) should not be a distributed product (should avoid sensations of
forking from existing projects)
5) should reuse more than reinvent
6) should come up with structured XML content well organized in a
repository
Here is my proposed architecture:
static site <--- frontend/staging <--- repository <--- backend
Static site is httpd running on minotaur (the main ASF web)
Frontend/staging will be Forrest. The idea, in order to satify
intrastructure@ concerns is
1) forrest runs on top of the repository and generates a staged
version of the web site (not on minotaur!)
2) a cron job on minotaur will
a) download the entire site from the staging area (using rsync, wget
or similar tools)
b) commit it on the "site" module CVS
c) move it on the public site folder
The reason for such an "inverted" architecture is to avoid having an SSH
access directly from the machine that runs forrestbot. This guarantees
*COMPLETE* isolation of minotaur from the rest of the system. There is
*NO* way for somebody to hack into any parts of doco and obtain access
to minotaur.
The reason for committing a copy on CVS is to allow infrastructure@ to
have a fresh copy of the web site in case something happens and Doco is
down. [they have expressed concerns about this]
Repository will be Subversion (for now, in the future, the idea is to
move into JSR-170-based repository, but this will take a while)
Backend will be a lenya publication. It will incorporates Linotype as a
Cocoon Form widget and wiki-syntax/wysiwig cross-editing capabilities.
The workflow will be both web and/or email driven.
Here is a tentative workflow:
1) everybody can edit a page and submit the changes. the pages on the
main site will have a link that connects to the pages on the backend
(which will be probably hosted on another machine, either nagoya or moof)
2) if a user can log in (doco committer), no workflow takes place and
changes to directly into the repository. [the repository will generate
diffs for changes and send email to the "docs" list for public oversight]
3) if a user cannot log in, workflow starts:
a) the changes are stored into a local spool
b) email is sent to the 'doco committer' list, this is going to
be a private list
c) the email will have "reply-to" set to the "allow" action and a
continuation ID. and will have the CC: header set to "reject" with the
continuation ID. So, by "replying" to the email
d) by hitting "reply", the workflow will approuve the changes
e) by hitting "reply to all", the workflow will reject them with
no further action
The idea is to use the Lenya workflow manager in coordination with
James. Basically:
1) lenya sends an email to an account managed by james
2) this account is mapped to a mailing list mailet that will dispatch
this message to the people subscribed
3) the "reply-to" fields of the email sent will be mapped to another
account handled by james
4) this other account is mapped to another mailet that will parse the
"email address", extract the continuation ID, understand the action to
take and trigger an HTTP request to lenya with the action and
continuation ID that will re-initiate the workflow. [the message of the
mail is discarded]
TODO list:
1) create a lenya publication that uses linotype (the 'doco' publication)
3) configure doco with the workflow described above and write the
necessary java classes that drive it
4) write the HTTP-triggering mailet (reuse the mail list mailet in james)
5) write the subversion implementation of the "repository" component
[this will be sent back to the "repository" block in cocoon]
6) write the cron scripts for minotaur
7) install lenya, james, forrest and forrestbot on Moof.
I propose the creation of a new CVS module called "cocoon-doco" to host
the scripts, installation instructions and doco-specific code.
I also propose the discussions to take place on lenya-dev, given that
Lenya is the community focused on content management. Interested people
are invited to join lenya-dev@cocoon.apache.org.
[in case of community-oriented you reply to this email, please, keep all
listed cross-posted, but in case of technical discussions, please, let's
move it over to lenya-dev to avoid mailbombing people that don't really
care]
Awaiting for your comments.
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> First of all, sorry for the massive cross-post, but I think it is going
> to be a great opportunity for all the communities involved to show off
> their potentials with the apache infrastructure.
>
> The proposal is about the creation of a content management system for
> apache projects, codenamed "Doco"
+1 from me from the Forrest side.
What I really like of this proposal is the SOC, Separation of Concerns
between communities. I particularly like Forrest's rols, as it it
*exactly* what we have been doing till now.
..
> Frontend/staging will be Forrest. The idea, in order to satify
> intrastructure@ concerns is
>
> 1) forrest runs on top of the repository and generates a staged version
> of the web site (not on minotaur!)
>
> 2) a cron job on minotaur will
>
> a) download the entire site from the staging area (using rsync, wget
> or similar tools)
> b) commit it on the "site" module CVS
> c) move it on the public site folder
>
> The reason for such an "inverted" architecture is to avoid having an SSH
> access directly from the machine that runs forrestbot. This guarantees
> *COMPLETE* isolation of minotaur from the rest of the system. There is
> *NO* way for somebody to hack into any parts of doco and obtain access
> to minotaur.
>
> The reason for committing a copy on CVS is to allow infrastructure@ to
> have a fresh copy of the web site in case something happens and Doco is
> down. [they have expressed concerns about this]
+1 to this for now.
This is basically what ForrestBot does now, and the only thing needed is
to install it on Apache hardware, and separate it in two parts (minotaur
and moof).
...
> 7) install lenya, james, forrest and forrestbot on Moof.
Ok, this has TBD, where do we go from here?
> 6) write the cron scripts for minotaur
This is just after.
> I propose the creation of a new CVS module called "cocoon-doco" to host
> the scripts, installation instructions and doco-specific code.
+1
> I also propose the discussions to take place on lenya-dev, given that
> Lenya is the community focused on content management. Interested people
> are invited to join lenya-dev@cocoon.apache.org.
Ok.
Let's now move the task of installing the Forrestbot over to the
forrest-dev and infrastructure lists then. When it's working, we'll let
you know.
> [in case of community-oriented you reply to this email, please, keep all
> listed cross-posted, but in case of technical discussions, please, let's
> move it over to lenya-dev to avoid mailbombing people that don't really
> care]
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [proposal] Doco
Posted by Tony Collen <co...@umn.edu>.
Stefano Mazzocchi wrote:
<snip/>
> Sounds like a plan to me.
>
>> http://james.seng.cc/archives/000145.html seems to be a standalone
>> Movable Type implementation. Sourceforge is down ATM so I can't check
>> on the license and usability of the Sapience code.
This looks like a fun problem to solve. I assume the "noise" in the
image would be to throw off any text-recognition software?
>
>
> Ok
>
>> This doesn't help a lot of course, but as we seem to be converging
>> into making rich-text editing "just another Woody widget" [1], we
>> might as well add this one to the list of TODOs for cool Woody/cForms.
>
>
> Totally +1
>
>> [1] Spoiling Bruno's "lonesome hacking cowboy" thought train, I just
>> want to confirm that he actually started working on this.
My thought train.... generate a random string in the flow, save it, and
somehow stitch together a larger jpeg/svg of the string, maybe even in
an <svg:text> tag to start out with some sort of prototype. sendPage to
a form, and have the form submit back into the continuation, and keep
trying to "authenticate" until the string matches.
>
>
> Yey!!!
>
>> He's still in a grumpy "friggin' stupid and unstable web browsers and
>> Javascript as a development hosting environment" mood, though, so
>> please light a candle for him. ;-)
>
>
> I can do more: I'm willing to help!! Bruno, ask me if you need anything
> (even privately, if you think it's better)
My gears are turning, I'll report back if I get anything.
>
> --
> Stefano.
>
Regards,
Tony
Re: HTML editor widget (was Re: [proposal] Doco)
Posted by Bruno Dumon <br...@outerthought.org>.
On Mon, 2003-11-03 at 14:59, Marc van Kempen wrote:
> Bruno Dumon wrote:
> > On Sat, 2003-11-01 at 16:20, Marc van Kempen wrote:
> >
> >>Bruno Dumon wrote:
> >>
> >>>On Fri, 2003-10-31 at 22:54, Marc van Kempen wrote:
> >>>
> >>>
> >>>>Bruno Dumon wrote:
> >>>
> >>><snip/>
> >>>
> >>>>>My first thought was to do this cleanup stuff serverside (could be as
> >>>>>simple as an XSL, which would make it easily customisable too). However
> >>>>>it seems like you want to do all that on the client side?
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>This won't work, you need valid xml to use xsl,
> >>>
> >>>
> >>>Ever heard of JTidy?
> >>>
> >>
> >>Yep, I'm not 100% sure if I tried JTidy (I'm pretty sure though), but I
> >>did try the commandline program html tidy, and this crashed on some of
> >>the html garbage that Word spits out. The last release of the program
> >>was in 2000, so I didn't place a lot of trust in it.
> >>
> >>
> >>>>and the IE html in
> >>>>particular can be very troublesome to fix.
> >>>
> >>><snip/>
> >>>
> >>>Thanks for sharing your experiences.
> >>>
> >>
> >>No problem, are you interested in my offer, or shouldn't I bother
> >>discussing it (releasing my editor as open source)?
> >
> >
> > Ah sorry, didn't pay attention to that. Of course I'm interested, but on
> > the other hand I can't promise that we'll make use of it without ever
> > having seen the code.
> >
> > What would be included? Only client side code or also the server-side
> > cleanup code?
> >
>
> Both if there is interest. It consist of the following components:
>
> - editor.js + images
> The implementation of the editor object and supporting images.
> - js-gui.js
> Javascript gui components.
>
> This will give you the editor,
> (I haven't worked out the image upload problem yet, for now you can
> write a user-defined function and configure the editor object to use
> that function. A default function is provided that will take a list of
> images and let the user choose from it in a popup form.)
>
> - HTMLFix.java
> html clean up component, accepts a text stream, spits out a text
> stream.
>
> This component fixes the html, I also wrote a component that will remove
> unwanted tags and attributes (actually it will only leave those tags and
> attributes that you want, and remove all the rest). I'd have to cut that
> out of an existing component.
>
> Actually I just discussed it, and we can release the components as open
> source
cool
> (I believe the apache license is similar to the BSD license?)
yep
>
> How shall I distribute it?
can you put in on a FTP server somewhere?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: HTML editor widget (was Re: [proposal] Doco)
Posted by Marc van Kempen <ma...@bowtie.nl>.
Bruno Dumon wrote:
> On Sat, 2003-11-01 at 16:20, Marc van Kempen wrote:
>
>>Bruno Dumon wrote:
>>
>>>On Fri, 2003-10-31 at 22:54, Marc van Kempen wrote:
>>>
>>>
>>>>Bruno Dumon wrote:
>>>
>>><snip/>
>>>
>>>>>My first thought was to do this cleanup stuff serverside (could be as
>>>>>simple as an XSL, which would make it easily customisable too). However
>>>>>it seems like you want to do all that on the client side?
>>>>>
>>>>>
>>>>>
>>>>
>>>>This won't work, you need valid xml to use xsl,
>>>
>>>
>>>Ever heard of JTidy?
>>>
>>
>>Yep, I'm not 100% sure if I tried JTidy (I'm pretty sure though), but I
>>did try the commandline program html tidy, and this crashed on some of
>>the html garbage that Word spits out. The last release of the program
>>was in 2000, so I didn't place a lot of trust in it.
>>
>>
>>>>and the IE html in
>>>>particular can be very troublesome to fix.
>>>
>>><snip/>
>>>
>>>Thanks for sharing your experiences.
>>>
>>
>>No problem, are you interested in my offer, or shouldn't I bother
>>discussing it (releasing my editor as open source)?
>
>
> Ah sorry, didn't pay attention to that. Of course I'm interested, but on
> the other hand I can't promise that we'll make use of it without ever
> having seen the code.
>
> What would be included? Only client side code or also the server-side
> cleanup code?
>
Both if there is interest. It consist of the following components:
- editor.js + images
The implementation of the editor object and supporting images.
- js-gui.js
Javascript gui components.
This will give you the editor,
(I haven't worked out the image upload problem yet, for now you can
write a user-defined function and configure the editor object to use
that function. A default function is provided that will take a list of
images and let the user choose from it in a popup form.)
- HTMLFix.java
html clean up component, accepts a text stream, spits out a text
stream.
This component fixes the html, I also wrote a component that will remove
unwanted tags and attributes (actually it will only leave those tags and
attributes that you want, and remove all the rest). I'd have to cut that
out of an existing component.
Actually I just discussed it, and we can release the components as open
source (I believe the apache license is similar to the BSD license?)
How shall I distribute it?
Regards,
Marc.
Re: HTML editor widget (was Re: [proposal] Doco)
Posted by Bruno Dumon <br...@outerthought.org>.
On Sat, 2003-11-01 at 16:20, Marc van Kempen wrote:
> Bruno Dumon wrote:
> > On Fri, 2003-10-31 at 22:54, Marc van Kempen wrote:
> >
> >>Bruno Dumon wrote:
> >
> > <snip/>
> >
> >>>My first thought was to do this cleanup stuff serverside (could be as
> >>>simple as an XSL, which would make it easily customisable too). However
> >>>it seems like you want to do all that on the client side?
> >>>
> >>>
> >>>
> >>
> >>This won't work, you need valid xml to use xsl,
> >
> >
> > Ever heard of JTidy?
> >
>
> Yep, I'm not 100% sure if I tried JTidy (I'm pretty sure though), but I
> did try the commandline program html tidy, and this crashed on some of
> the html garbage that Word spits out. The last release of the program
> was in 2000, so I didn't place a lot of trust in it.
>
> >
> >> and the IE html in
> >>particular can be very troublesome to fix.
> >
> > <snip/>
> >
> > Thanks for sharing your experiences.
> >
>
> No problem, are you interested in my offer, or shouldn't I bother
> discussing it (releasing my editor as open source)?
Ah sorry, didn't pay attention to that. Of course I'm interested, but on
the other hand I can't promise that we'll make use of it without ever
having seen the code.
What would be included? Only client side code or also the server-side
cleanup code?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: HTML editor widget (was Re: [proposal] Doco)
Posted by Marc van Kempen <ma...@bowtie.nl>.
Bruno Dumon wrote:
> On Fri, 2003-10-31 at 22:54, Marc van Kempen wrote:
>
>>Bruno Dumon wrote:
>
> <snip/>
>
>>>My first thought was to do this cleanup stuff serverside (could be as
>>>simple as an XSL, which would make it easily customisable too). However
>>>it seems like you want to do all that on the client side?
>>>
>>>
>>>
>>
>>This won't work, you need valid xml to use xsl,
>
>
> Ever heard of JTidy?
>
Yep, I'm not 100% sure if I tried JTidy (I'm pretty sure though), but I
did try the commandline program html tidy, and this crashed on some of
the html garbage that Word spits out. The last release of the program
was in 2000, so I didn't place a lot of trust in it.
>
>> and the IE html in
>>particular can be very troublesome to fix.
>
> <snip/>
>
> Thanks for sharing your experiences.
>
No problem, are you interested in my offer, or shouldn't I bother
discussing it (releasing my editor as open source)?
Regards,
Marc.
Re: HTML editor widget (was Re: [proposal] Doco)
Posted by Bruno Dumon <br...@outerthought.org>.
On Fri, 2003-10-31 at 22:54, Marc van Kempen wrote:
> Bruno Dumon wrote:
<snip/>
> >My first thought was to do this cleanup stuff serverside (could be as
> >simple as an XSL, which would make it easily customisable too). However
> >it seems like you want to do all that on the client side?
> >
> >
> >
> This won't work, you need valid xml to use xsl,
Ever heard of JTidy?
> and the IE html in
> particular can be very troublesome to fix.
<snip/>
Thanks for sharing your experiences.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: HTML editor widget (was Re: [proposal] Doco)
Posted by Marc van Kempen <ma...@bowtie.nl>.
Bruno Dumon wrote:
...
>* different users of the widget (like the doco project vs the project
>where we need it) will likely require different subsets of HTML to be
>used.
>
>* support for both Mozilla and IE is important. Other browsers should
>fall back to a textarea with raw HTML in it.
>
>* the HTML produced by the editor should be cleaned (i.e. not supported
>tags & attributes removed) and normalized (formatted). The goal of this
>is to deliver a nice XHTML-subset-doc for storage, and to show nice HTML
>to people editing it manually. Hopefully this will also make it possible
>to do meaningful text-based diffs.
>
>
>
I have done some work on this. I have first written a js html editor for
IE (>5.5) to be used in an XML content management system. For this we
needed to clean the html and convert it to xhtml in order to be able to
process it with xslt upon displaying pages.
One approach that I've tried is to generate the xhtml from the browser
dom page with javascript, i.e. walk the tree and recursively generate
<TAG> ... </TAG> entries, while surrounding all attributes with quotes.
This could then be postprocessed on the server by parsing it with an XML
parser and manipulating the DOM tree. This however proved to be a slight
nightmare due to js/dom bugs in IE 5.5, if you'd be willing to drop 5.5
support it would be easier, but it might also be possible to do this
using more specific IE js constructions with which I'm not particular
familiar.
Eventually we ended up doing this completely server side, I wrote one
component to fix the html to be xhtml and after that I use an XML parser
to remove all unwanted attributes and tags.
The biggest problem while handling the html is that you also have to
parse Word html that is pasted into the editor, and the html that Word
produces is truly gruesome!
While the server side solution works well for all html garbage that I
have encountered until now, it is not completely satisfactory because
when you paste the html into the editor you're looking at the
unprocessed html, when it has been processed by the server a lot will
have been removed and it can look rather different. One could try to
explain this to the user, but it's better to filter the html directly
after pasting it, so the user will not get confused.
I'm now in the process of writing an editor component that can handle IE
and Mozilla. It is in a working state, but the code needs to cleaned and
some stuff needs to be written (a table editor, a url editor, etc.), it
is however for a closed source system. I could discuss it to see if we
would be willing to release it as open source.
>My first thought was to do this cleanup stuff serverside (could be as
>simple as an XSL, which would make it easily customisable too). However
>it seems like you want to do all that on the client side?
>
>
>
This won't work, you need valid xml to use xsl, and the IE html in
particular can be very troublesome to fix.
>* Currently in e.g. Linotype the source for the editor (thus of the
>iframe) is fetched separately from the main page. This is harder to do
>with cforms since then the pipeline from which the content is fetched
>should also have access to the cforms Form which is stored somewhere in
>a variable in a flowscript. For the cforms widget it would be easier I
>think to embed the HTML directly in the page (e.g. as a Javascript
>variable). This also makes it possible to assign the content either to
>the html editor or the textarea depending on what the client supports.
>
>* Automatic image upload: still need to think more about this. After
>pressing the submit button (and afterwards possibly showing the form
>again), the images will need to become available in the URL space. How
>that's done will probably differ from application to application so we
>could put that behaviour behind an interface.
>
>
>
This is an interesting problem, Stefano talked about embedding it into
the document, how would you want to do this? That would be the best
solution for an embeddable component!
>* wiki syntax support: we have no need for this, so don't expect any
>effort from me on that.
>
>
>
Regards,
Marc.
Re: HTML editor widget (was Re: [proposal] Doco)
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Bruno Dumon wrote:
> I've only just started with some little javascript experiments, so it's
> not like any code has been written yet.
You can look at
http://bitfluxeditor.org/
for a start.
> * support for both Mozilla and IE is important.
That's going to give one or two headaches more :-)
J.Pietschmann
Re: HTML editor widget (was Re: [proposal] Doco)
Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2003-10-30 at 10:34, Stefano Mazzocchi wrote:
> On Wednesday, Oct 29, 2003, at 11:40 Europe/Rome, Bruno Dumon wrote:
>
> > I've only just started with some little javascript experiments, so it's
> > not like any code has been written yet.
>
> ok, but it's great to see you doing this
>
> > Here are some first random thoughts:
> >
> > * different users of the widget (like the doco project vs the project
> > where we need it) will likely require different subsets of HTML to be
> > used.
>
> True, even if, for XHTML, you can support different modules. For
> example, I didn't support tables in Linotype.
>
> > * support for both Mozilla and IE is important. Other browsers should
> > fall back to a textarea with raw HTML in it.
>
> yes
>
> > * the HTML produced by the editor should be cleaned (i.e. not supported
> > tags & attributes removed) and normalized (formatted). The goal of this
> > is to deliver a nice XHTML-subset-doc for storage, and to show nice
> > HTML
> > to people editing it manually. Hopefully this will also make it
> > possible
> > to do meaningful text-based diffs.
>
> Yep
>
> > My first thought was to do this cleanup stuff serverside (could be as
> > simple as an XSL, which would make it easily customisable too). However
> > it seems like you want to do all that on the client side?
>
> Linotype already includes a DOM serializer, I think it already does
> some pretty formatting and already has the ability to distinguish
> between whitespace-safe elements and non.
>
> > * Currently in e.g. Linotype the source for the editor (thus of the
> > iframe) is fetched separately from the main page. This is harder to do
> > with cforms since then the pipeline from which the content is fetched
> > should also have access to the cforms Form which is stored somewhere in
> > a variable in a flowscript. For the cforms widget it would be easier I
> > think to embed the HTML directly in the page (e.g. as a Javascript
> > variable). This also makes it possible to assign the content either to
> > the html editor or the textarea depending on what the client supports.
>
> I thought about that too: my solution would be to have woody draw the
> widget as an empty <iframe> and then fill it up at page load time from
> some client-side javascript.
>
> In theory it's easy, in practice, I expect tons of bugs and
> incompatibilities between browsers (but haven't tried yet)
I think it's feasible.
I found this thing called "htmlArea", which is some javascript that
exploits the html editors in both IE and Mozilla, and it does things
like that without trouble.
See here:
http://www.interactivetools.com/products/htmlarea/
and here for an online demo:
http://dynarch.com/mishoo/htmlarea.epl
I'm wondering if maybe we should start from that one (it's BSD-style
licensed).
> Another thing I wanted to try is to embed the icons right into the page
> instead of having them fetched from outside, this makes is easier since
> you don't have to mount your icons somewhere in your URI space.
>
> > * Automatic image upload: still need to think more about this. After
> > pressing the submit button (and afterwards possibly showing the form
> > again), the images will need to become available in the URL space. How
> > that's done will probably differ from application to application so we
> > could put that behaviour behind an interface.
>
> hmmm, what aobut giving back the uploaded "Parts" back into the object
> model that is accessible to the flowscript. the flow will handle them
> and put them in the proper place... at this point, the flow will have
> to be able to call a "link translation" on the page.
something like that, yes. I'll come back to this after I've been able to
put some thought to it.
> > * wiki syntax support: we have no need for this, so don't expect any
> > effort from me on that.
>
> Fair enough, but please keep in mind that the editor will have "multi
> views" and need to be defined in the description of the widget for that
> particular form.
ok.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: HTML editor widget (was Re: [proposal] Doco)
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Oct 29, 2003, at 11:40 Europe/Rome, Bruno Dumon wrote:
> I've only just started with some little javascript experiments, so it's
> not like any code has been written yet.
ok, but it's great to see you doing this
> Here are some first random thoughts:
>
> * different users of the widget (like the doco project vs the project
> where we need it) will likely require different subsets of HTML to be
> used.
True, even if, for XHTML, you can support different modules. For
example, I didn't support tables in Linotype.
> * support for both Mozilla and IE is important. Other browsers should
> fall back to a textarea with raw HTML in it.
yes
> * the HTML produced by the editor should be cleaned (i.e. not supported
> tags & attributes removed) and normalized (formatted). The goal of this
> is to deliver a nice XHTML-subset-doc for storage, and to show nice
> HTML
> to people editing it manually. Hopefully this will also make it
> possible
> to do meaningful text-based diffs.
Yep
> My first thought was to do this cleanup stuff serverside (could be as
> simple as an XSL, which would make it easily customisable too). However
> it seems like you want to do all that on the client side?
Linotype already includes a DOM serializer, I think it already does
some pretty formatting and already has the ability to distinguish
between whitespace-safe elements and non.
> * Currently in e.g. Linotype the source for the editor (thus of the
> iframe) is fetched separately from the main page. This is harder to do
> with cforms since then the pipeline from which the content is fetched
> should also have access to the cforms Form which is stored somewhere in
> a variable in a flowscript. For the cforms widget it would be easier I
> think to embed the HTML directly in the page (e.g. as a Javascript
> variable). This also makes it possible to assign the content either to
> the html editor or the textarea depending on what the client supports.
I thought about that too: my solution would be to have woody draw the
widget as an empty <iframe> and then fill it up at page load time from
some client-side javascript.
In theory it's easy, in practice, I expect tons of bugs and
incompatibilities between browsers (but haven't tried yet)
Another thing I wanted to try is to embed the icons right into the page
instead of having them fetched from outside, this makes is easier since
you don't have to mount your icons somewhere in your URI space.
> * Automatic image upload: still need to think more about this. After
> pressing the submit button (and afterwards possibly showing the form
> again), the images will need to become available in the URL space. How
> that's done will probably differ from application to application so we
> could put that behaviour behind an interface.
hmmm, what aobut giving back the uploaded "Parts" back into the object
model that is accessible to the flowscript. the flow will handle them
and put them in the proper place... at this point, the flow will have
to be able to call a "link translation" on the page.
> * wiki syntax support: we have no need for this, so don't expect any
> effort from me on that.
Fair enough, but please keep in mind that the editor will have "multi
views" and need to be defined in the description of the widget for that
particular form.
--
Stefano.
HTML editor widget (was Re: [proposal] Doco)
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2003-10-28 at 19:20, Stefano Mazzocchi wrote:
>
> > [1] Spoiling Bruno's "lonesome hacking cowboy" thought train, I just
> > want to confirm that he actually started working on this.
>
> Yey!!!
>
> > He's still in a grumpy "friggin' stupid and unstable web browsers and
> > Javascript as a development hosting environment"
for the record: I've never said any of that.
> mood, though, so
> > please light a candle for him. ;-)
>
> I can do more: I'm willing to help!! Bruno, ask me if you need anything
> (even privately, if you think it's better)
I've only just started with some little javascript experiments, so it's
not like any code has been written yet.
Here are some first random thoughts:
* different users of the widget (like the doco project vs the project
where we need it) will likely require different subsets of HTML to be
used.
* support for both Mozilla and IE is important. Other browsers should
fall back to a textarea with raw HTML in it.
* the HTML produced by the editor should be cleaned (i.e. not supported
tags & attributes removed) and normalized (formatted). The goal of this
is to deliver a nice XHTML-subset-doc for storage, and to show nice HTML
to people editing it manually. Hopefully this will also make it possible
to do meaningful text-based diffs.
My first thought was to do this cleanup stuff serverside (could be as
simple as an XSL, which would make it easily customisable too). However
it seems like you want to do all that on the client side?
* Currently in e.g. Linotype the source for the editor (thus of the
iframe) is fetched separately from the main page. This is harder to do
with cforms since then the pipeline from which the content is fetched
should also have access to the cforms Form which is stored somewhere in
a variable in a flowscript. For the cforms widget it would be easier I
think to embed the HTML directly in the page (e.g. as a Javascript
variable). This also makes it possible to assign the content either to
the html editor or the textarea depending on what the client supports.
* Automatic image upload: still need to think more about this. After
pressing the submit button (and afterwards possibly showing the form
again), the images will need to become available in the URL space. How
that's done will probably differ from application to application so we
could put that behaviour behind an interface.
* wiki syntax support: we have no need for this, so don't expect any
effort from me on that.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
Moving to Cocoon...
A little context: Steven suggested to take a look at
>> http://kokochi.com:8080/sapience/test.jsp
and implement the above in Doco to avoid automatic crawlers to spam us
thru the editing interface.
On Tuesday, Oct 28, 2003, at 16:26 Europe/Rome, Steven Noels wrote:
> Stefano Mazzocchi wrote:
>
>> That is a *very good point* and I think you are perfectly right: we
>> should put it into Doco. Any idea on how to do it?
>
> *blush*
LOL
> In my layman's thinking, I would envision this as some special Woody
> widget which generates a random image for display, makes it available
> across some session-specific URI and does validation of the associated
> verification field on submit. Housekeeping of these temporary
> resources will be the main burden, plus some Java2D hacking, which
> apparently has been explained in DrDobbs already. Maybe the
> continuation id can be used for the temporary URI.
Sounds like a plan to me.
> http://james.seng.cc/archives/000145.html seems to be a standalone
> Movable Type implementation. Sourceforge is down ATM so I can't check
> on the license and usability of the Sapience code.
Ok
> This doesn't help a lot of course, but as we seem to be converging
> into making rich-text editing "just another Woody widget" [1], we
> might as well add this one to the list of TODOs for cool Woody/cForms.
Totally +1
> [1] Spoiling Bruno's "lonesome hacking cowboy" thought train, I just
> want to confirm that he actually started working on this.
Yey!!!
> He's still in a grumpy "friggin' stupid and unstable web browsers and
> Javascript as a development hosting environment" mood, though, so
> please light a candle for him. ;-)
I can do more: I'm willing to help!! Bruno, ask me if you need anything
(even privately, if you think it's better)
--
Stefano.
Re: [proposal] Doco
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> That is a *very good point* and I think you are perfectly right: we
> should put it into Doco. Any idea on how to do it?
*blush*
In my layman's thinking, I would envision this as some special Woody
widget which generates a random image for display, makes it available
across some session-specific URI and does validation of the associated
verification field on submit. Housekeeping of these temporary resources
will be the main burden, plus some Java2D hacking, which apparently has
been explained in DrDobbs already. Maybe the continuation id can be used
for the temporary URI.
http://james.seng.cc/archives/000145.html seems to be a standalone
Movable Type implementation. Sourceforge is down ATM so I can't check on
the license and usability of the Sapience code.
This doesn't help a lot of course, but as we seem to be converging into
making rich-text editing "just another Woody widget" [1], we might as
well add this one to the list of TODOs for cool Woody/cForms.
[1] Spoiling Bruno's "lonesome hacking cowboy" thought train, I just
want to confirm that he actually started working on this. He's still in
a grumpy "friggin' stupid and unstable web browsers and Javascript as a
development hosting environment" mood, though, so please light a candle
for him. ;-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [proposal] Doco
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> That is a *very good point* and I think you are perfectly right: we
> should put it into Doco. Any idea on how to do it?
*blush*
In my layman's thinking, I would envision this as some special Woody
widget which generates a random image for display, makes it available
across some session-specific URI and does validation of the associated
verification field on submit. Housekeeping of these temporary resources
will be the main burden, plus some Java2D hacking, which apparently has
been explained in DrDobbs already. Maybe the continuation id can be used
for the temporary URI.
http://james.seng.cc/archives/000145.html seems to be a standalone
Movable Type implementation. Sourceforge is down ATM so I can't check on
the license and usability of the Sapience code.
This doesn't help a lot of course, but as we seem to be converging into
making rich-text editing "just another Woody widget" [1], we might as
well add this one to the list of TODOs for cool Woody/cForms.
[1] Spoiling Bruno's "lonesome hacking cowboy" thought train, I just
want to confirm that he actually started working on this. He's still in
a grumpy "friggin' stupid and unstable web browsers and Javascript as a
development hosting environment" mood, though, so please light a candle
for him. ;-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> That is a *very good point* and I think you are perfectly right: we
> should put it into Doco. Any idea on how to do it?
*blush*
In my layman's thinking, I would envision this as some special Woody
widget which generates a random image for display, makes it available
across some session-specific URI and does validation of the associated
verification field on submit. Housekeeping of these temporary resources
will be the main burden, plus some Java2D hacking, which apparently has
been explained in DrDobbs already. Maybe the continuation id can be used
for the temporary URI.
http://james.seng.cc/archives/000145.html seems to be a standalone
Movable Type implementation. Sourceforge is down ATM so I can't check on
the license and usability of the Sapience code.
This doesn't help a lot of course, but as we seem to be converging into
making rich-text editing "just another Woody widget" [1], we might as
well add this one to the list of TODOs for cool Woody/cForms.
[1] Spoiling Bruno's "lonesome hacking cowboy" thought train, I just
want to confirm that he actually started working on this. He's still in
a grumpy "friggin' stupid and unstable web browsers and Javascript as a
development hosting environment" mood, though, so please light a candle
for him. ;-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Image-Based Authentication
Posted by Tony Collen <co...@umn.edu>.
Bertrand Delacretaz wrote:
>> Hrm, or how about I just toss it in scratchpad for now? :)
>
>
> +1
Added, check the scratchpad samples.
tony
Re: Image-Based Authentication
Posted by Bertrand Delacretaz <bd...@apache.org>.
> Hrm, or how about I just toss it in scratchpad for now? :)
+1
-Bertrand
Re: Image-Based Authentication
Posted by Tony Collen <co...@umn.edu>.
Bertrand Delacretaz wrote:
> How about a new "misc-samples" block for hard to categorize, yet useful
> samples?
>
> This could also be a home for the recently proposed sitemap viewer
> (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24294) .
Hrm, or how about I just toss it in scratchpad for now? :)
>
> -Bertrand
>
Tony
Re: Image-Based Authentication
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Vendredi, 31 oct 2003, à 17:03 Europe/Zurich, Tony Collen a écrit :
> ...I was thinking to put it in the Flow block samples. If I do this
> will it break anything with the anteater tests? (Reading
> src/webapp/samples/flow/README.txt).
How about a new "misc-samples" block for hard to categorize, yet useful
samples?
This could also be a home for the recently proposed sitemap viewer
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24294) .
-Bertrand
Re: Image-Based Authentication
Posted by Tony Collen <co...@umn.edu>.
Joerg Heinicke wrote:
> On 31.10.2003 08:33, Reinhard Poetz wrote:
>
>> Why don't you add it to the Cocoon CVS?
>>
>> a) general samples block (Petstore, image based auth, ...)
>> b) autentication framework block
>> c) SVG block
>>
>> I would be +1 for b) and +0,5 for the two others.
>>
>> What do others think?
>>
>> Reinhard
>
>
> +1 for a): with a comment that batik must be activated.
> +0.5 for b): isn't the authentication framework to specific?
> +0 for c): has not much todo with generating SVG itself.
I was thinking to put it in the Flow block samples. If I do this will it break anything with the
anteater tests? (Reading src/webapp/samples/flow/README.txt).
Tony
Re: Image-Based Authentication
Posted by Joerg Heinicke <jh...@virbus.de>.
On 31.10.2003 08:33, Reinhard Poetz wrote:
> Why don't you add it to the Cocoon CVS?
>
> a) general samples block (Petstore, image based auth, ...)
> b) autentication framework block
> c) SVG block
>
> I would be +1 for b) and +0,5 for the two others.
>
> What do others think?
>
> Reinhard
+1 for a): with a comment that batik must be activated.
+0.5 for b): isn't the authentication framework to specific?
+0 for c): has not much todo with generating SVG itself.
Joerg
Re: Image-Based Authentication
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Oct 31, 2003, at 13:28 Europe/Rome, Andrew Savory wrote:
> Hi,
>
> On Friday, Oct 31, 2003, at 07:33 Europe/London, Reinhard Poetz wrote:
>
>> Why don't you add it to the Cocoon CVS?
>>
>> a) general samples block (Petstore, image based auth, ...)
>> b) autentication framework block
>> c) SVG block
>>
>> I would be +1 for b) and +0,5 for the two others.
>>
>> What do others think?
>
> Definitely!
+1 I'm going to use it for Doco!
--
Stefano.
Re: Image-Based Authentication
Posted by Andrew Savory <an...@luminas.co.uk>.
Hi,
On Friday, Oct 31, 2003, at 07:33 Europe/London, Reinhard Poetz wrote:
> Why don't you add it to the Cocoon CVS?
>
> a) general samples block (Petstore, image based auth, ...)
> b) autentication framework block
> c) SVG block
>
> I would be +1 for b) and +0,5 for the two others.
>
> What do others think?
Definitely!
Andrew.
RE: Image-Based Authentication
Posted by Reinhard Poetz <re...@apache.org>.
Why don't you add it to the Cocoon CVS?
a) general samples block (Petstore, image based auth, ...)
b) autentication framework block
c) SVG block
I would be +1 for b) and +0,5 for the two others.
What do others think?
Reinhard
> -----Original Message-----
> From: Tony Collen [mailto:colle006@umn.edu]
> Sent: Thursday, October 30, 2003 10:46 PM
> To: dev@cocoon.apache.org
> Subject: Re: Image-Based Authentication
>
>
> Alright, here is the complete guide to how I got image-based
> authentication working. I refactored it to not use
> interceptions, as well.
>
> If there are any questions, please ask! :)
>
> Here is the sitemap snippet:
>
> <map:match pattern="">
> <map:call function="main"/>
> </map:match>
>
> <map:match pattern="form/*.flow">
> <map:call continuation="{1}"/>
> </map:match>
>
> <map:match pattern="*.jxt">
> <map:generate type="jxt" src="documents/{1}.jxt"/>
> <map:serialize type="xhtml"/>
> </map:match>
>
> <map:match pattern="auth/*.jpg">
> <map:call continuation="{1}">
> <map:parameter name="msg" value="image"/>
> </map:call>
> </map:match>
>
> <map:match pattern="internal/auth.jpg">
> <map:generate type="jxt" src="documents/auth-jxt.svg"/>
> <map:serialize type="svg2jpeg"/>
> </map:match>
>
>
> Here is the associated Flowscript:
>
>
> function main() {
>
> var secret = generateSecret();
>
> while (true) {
> cocoon.sendPageAndWait("main.jxt", {secret:secret});
>
> if (cocoon.parameters.msg == "image") {
> cocoon.sendPage("internal/auth.jpg", {text:secret});
> return;
> } else {
>
> var input = cocoon.request.get("secret");
>
> if (input == secret) {
> break;
> }
> }
> }
>
> cocoon.sendPage("/image/success.jxt", {secret:secret});
>
> }
>
> function generateSecret() {
>
> var characters =
> "!@#$%^&*(){}[]<>.,ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890";
>
> var passwordlength = 7;
>
> var password = "";
> var randomnumber = 0;
>
> for (var n = 0; n < passwordlength; n++) {
> randomnumber = Math.floor(characters.length*Math.random());
> password +=
> characters.substring(randomnumber,randomnumber + 1)
> }
>
> return password;
> }
>
>
> And here are the appropriate files (mostly jxtemplates):
>
> main.jxt:
>
> <?xml version="1.0"?>
> <html xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
> <head>
> <title>image authentication</title>
> </head>
> <body>
>
> <h1>Image-based authentication</h1>
>
> <p>As a security measure, please enter the string you
> see below.</p>
>
> <img src="/image/auth/${continuation.id}.jpg"/>
>
> <form method="post" action="/image/form/${continuation.id}.flow">
> <input type="text" name="secret"/>
> <input type="submit"/>
> </form>
>
>
> </body>
> </html>
>
> success.jxt:
>
> <?xml version="1.0"?>
> <html xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
> <head>
> <title>image authentication</title>
> </head>
> <body>
>
> <h1>Success!</h1>
> <p>The code was obviously ${secret}</p>
> <p>This sample demonstrates how you would implement an
> image-based
> authentication using flow and the intercepted flowscript.</p>
> <p>This is most commonly used to keep robots or spiders
> out of an
> area, but
> you don't neccesarily care about humans.</p>
>
>
> </body>
> </html>
>
> auth-jxt.svg:
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <svg width="200" height="75">
> <defs>
> <filter id="blur2">
> <feGaussianBlur stdDeviation="2"/>
> </filter>
> </defs>
> <g id="imagegroup">
> <text
> style="fill:#0086B3;font-size:42;font-family:TrebuchetMS-Bold;
> filter:url(#blur2);"
> x="0" y="48">${text}</text>
> </g>
> </svg>
>
>
>
>
> Regards,
>
> Tony
>
Re: Image-Based Authentication
Posted by Tony Collen <co...@umn.edu>.
Alright, here is the complete guide to how I got image-based
authentication working. I refactored it to not use interceptions, as well.
If there are any questions, please ask! :)
Here is the sitemap snippet:
<map:match pattern="">
<map:call function="main"/>
</map:match>
<map:match pattern="form/*.flow">
<map:call continuation="{1}"/>
</map:match>
<map:match pattern="*.jxt">
<map:generate type="jxt" src="documents/{1}.jxt"/>
<map:serialize type="xhtml"/>
</map:match>
<map:match pattern="auth/*.jpg">
<map:call continuation="{1}">
<map:parameter name="msg" value="image"/>
</map:call>
</map:match>
<map:match pattern="internal/auth.jpg">
<map:generate type="jxt" src="documents/auth-jxt.svg"/>
<map:serialize type="svg2jpeg"/>
</map:match>
Here is the associated Flowscript:
function main() {
var secret = generateSecret();
while (true) {
cocoon.sendPageAndWait("main.jxt", {secret:secret});
if (cocoon.parameters.msg == "image") {
cocoon.sendPage("internal/auth.jpg", {text:secret});
return;
} else {
var input = cocoon.request.get("secret");
if (input == secret) {
break;
}
}
}
cocoon.sendPage("/image/success.jxt", {secret:secret});
}
function generateSecret() {
var characters =
"!@#$%^&*(){}[]<>.,ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890";
var passwordlength = 7;
var password = "";
var randomnumber = 0;
for (var n = 0; n < passwordlength; n++) {
randomnumber = Math.floor(characters.length*Math.random());
password += characters.substring(randomnumber,randomnumber + 1)
}
return password;
}
And here are the appropriate files (mostly jxtemplates):
main.jxt:
<?xml version="1.0"?>
<html xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
<head>
<title>image authentication</title>
</head>
<body>
<h1>Image-based authentication</h1>
<p>As a security measure, please enter the string you see below.</p>
<img src="/image/auth/${continuation.id}.jpg"/>
<form method="post" action="/image/form/${continuation.id}.flow">
<input type="text" name="secret"/>
<input type="submit"/>
</form>
</body>
</html>
success.jxt:
<?xml version="1.0"?>
<html xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
<head>
<title>image authentication</title>
</head>
<body>
<h1>Success!</h1>
<p>The code was obviously ${secret}</p>
<p>This sample demonstrates how you would implement an image-based
authentication using flow and the intercepted flowscript.</p>
<p>This is most commonly used to keep robots or spiders out of an
area, but
you don't neccesarily care about humans.</p>
</body>
</html>
auth-jxt.svg:
<?xml version="1.0" encoding="UTF-8"?>
<svg width="200" height="75">
<defs>
<filter id="blur2">
<feGaussianBlur stdDeviation="2"/>
</filter>
</defs>
<g id="imagegroup">
<text
style="fill:#0086B3;font-size:42;font-family:TrebuchetMS-Bold;filter:url(#blur2);"
x="0" y="48">${text}</text>
</g>
</svg>
Regards,
Tony
Re: Image-Based Authentication (Was: Re: [proposal] Doco)
Posted by Tony Collen <co...@umn.edu>.
Oh, and I forgot to add (if it isn't terribly obvious) that it's not a Woody widget, but more of a
proof-of-concept to see if I could actually do it :)
Tony
Re: Image-Based Authentication (Was: Re: [proposal] Doco)
Posted by Tony Collen <co...@umn.edu>.
Torsten Curdt wrote:
>> I spent an afternoon implementing it. It's a complicated beast, and it
>> uses the intercepted flowscript in a big huge ugly hack... BUT... it
>> works, which makes me happy :) Check it out at [1] -- please go easy
>> on it since this is my personal box at home and on my cablemodem. I
>> will clean it up and add it to the samples once I get my CVS problems
>> straightened out.
>
>
> very cool ...but why was the intercepted flowscript necessary here?
To be honest, I couldn't get it to work with "regular" FS, so I used a brute force way of getting it
to work. It's ugly, and there's probably a simpler way of doing it -- in fact... PLEASE find a
better way of doing it :)
Let me see if I can explain, since I don't have my code here with me right now.
<map:match pattern="">
<map:call function="main"/>
</map:match>
function main() {
var secret = generateSecret();
while (true) {
cocoon.sendPageAndWait("main");
if (cocoon.request.get("secret") == secret) {
break;
}
cocoon.sendPage("success");
}
}
The problem comes in when we need to generate an image based off the same continuation ID that we
get from the first sendPageAndWait. For instance, say we have the following pipeline to generate an
image, and we want the requested image to actually be the continuation ID.
<map:match pattern="auth/*.jpg">
<map:call continuation="{1}"/>
</map:match>
Ok, simple enough, but then the problem is that once we jump back into the continuation (which is
the same as the one we get from the first sendPageAndWait), how do we know that we should be serving
an image instead of letting the loop continue? If we use intercepted flow, we can check for this.
Changing the above snippet to:
<map:match pattern="auth/*.jpg">
<map:call continuation="{1}">
<!-- bigass hack -->
<map:parameter name="msg" value="doImage"/>
</map:call>
</map:match>
Then we write the interceptions for the main() method above:
// callbacks.js
function main() {
continueExecution(): {
if (cocoon.parameters.msg == "doImage") {
cocoon.sendPage("internal/" + secret + ".jpg");
}
}
}
This is probably breaking some sort of good design practice... it's already approaching spaghetti
code status ;)
Anyway, whenever the continuation is restarted, continueExecution() is run, and we obviously check
to see if we're getting a parameter named msg with a value of doImage, and if so, we sendPage to a
secret url that actually generates the image:
<!-- this would most likely be in an internal-only pipeline -->
<map:match pattern="internal/*.jpg">
<map:generate src="docs/foo.xml"/>
<map:transform src="xslt/foo2svg.xsl">
<map:parameter name="secret" value="{1}"/>
</map:transform>
<map:serialize type="svg2jpeg"/>
</map:match>
Pretty self-explanatory... here we just pass the wildcard match to the XSLT which in turn adds the
appropriate <svg:text> element with the secret code. There's a lot of little details missing here
since I don't have all the stuff in front of me. There has to be a much much simpler way of doing
this, while also obscuring the URL of the image to generate. Using continuation ID's seemed the
most straightforward way to me, but it ended up also being quite complex.
Regards,
Tony
Re: Image-Based Authentication (Was: Re: [proposal] Doco)
Posted by Torsten Curdt <tc...@vafer.org>.
> I spent an afternoon implementing it. It's a complicated beast, and it
> uses the intercepted flowscript in a big huge ugly hack... BUT... it
> works, which makes me happy :) Check it out at [1] -- please go easy on
> it since this is my personal box at home and on my cablemodem. I will
> clean it up and add it to the samples once I get my CVS problems
> straightened out.
very cool ...but why was the intercepted flowscript necessary here?
--
Torsten
Image-Based Authentication (Was: Re: [proposal] Doco)
Posted by Tony Collen <co...@umn.edu>.
Stefano Mazzocchi wrote:
> On Tuesday, Oct 28, 2003, at 13:10 Europe/Rome, Steven Noels wrote:
<snip/>
>> We have seen similar abuse on the Cocoon wiki as well. Rather than
>> completely offload the burden of moderation to a bunch of people, we
>> should come up with an upfront facility for blocking automated abuse.
>> Similar to the facilities found in MSN Hotmail, Paypal and others who
>> use some generated image to validate sign up for their system, having
>> something like this Sapience thing might reduce the moderation burden
>> in the long run.
>>
>> It's cool for sure, but it might be some good way to make sure only
>> humans edit content, and not a bunch of malevolent bots.
>
>
> That is a *very good point* and I think you are perfectly right: we
> should put it into Doco. Any idea on how to do it?
I spent an afternoon implementing it. It's a complicated beast, and it
uses the intercepted flowscript in a big huge ugly hack... BUT... it
works, which makes me happy :) Check it out at [1] -- please go easy on
it since this is my personal box at home and on my cablemodem. I will
clean it up and add it to the samples once I get my CVS problems
straightened out.
[1] http://tinyurl.com/ss9z
> --
> Stefano.
Regards,
Tony
Re: [proposal] Doco
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> That is a *very good point* and I think you are perfectly right: we
> should put it into Doco. Any idea on how to do it?
*blush*
In my layman's thinking, I would envision this as some special Woody
widget which generates a random image for display, makes it available
across some session-specific URI and does validation of the associated
verification field on submit. Housekeeping of these temporary resources
will be the main burden, plus some Java2D hacking, which apparently has
been explained in DrDobbs already. Maybe the continuation id can be used
for the temporary URI.
http://james.seng.cc/archives/000145.html seems to be a standalone
Movable Type implementation. Sourceforge is down ATM so I can't check on
the license and usability of the Sapience code.
This doesn't help a lot of course, but as we seem to be converging into
making rich-text editing "just another Woody widget" [1], we might as
well add this one to the list of TODOs for cool Woody/cForms.
[1] Spoiling Bruno's "lonesome hacking cowboy" thought train, I just
want to confirm that he actually started working on this. He's still in
a grumpy "friggin' stupid and unstable web browsers and Javascript as a
development hosting environment" mood, though, so please light a candle
for him. ;-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 28, 2003, at 13:10 Europe/Rome, Steven Noels wrote:
> Stefano Mazzocchi wrote:
>
>>> Doco came to my mind when finding
>>> http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
>> Can I be anal for a sec?
>
> LOL. Sure, as long as you wipe properly afterwards, no problem here.
> :-)
>
>> cool, but what do we do with it?
>
> Well, since people had to come up with anti-spam measures for weblog
> comments, because of some nitwits which abuse the comment facility of
> modern weblog engines using automated tools, to raise Google rankings
> of spam-linked websites, I figure the same will start happening with
> any light-weight content contribution tool in the upcoming months.
>
> We have seen similar abuse on the Cocoon wiki as well. Rather than
> completely offload the burden of moderation to a bunch of people, we
> should come up with an upfront facility for blocking automated abuse.
> Similar to the facilities found in MSN Hotmail, Paypal and others who
> use some generated image to validate sign up for their system, having
> something like this Sapience thing might reduce the moderation burden
> in the long run.
>
> It's cool for sure, but it might be some good way to make sure only
> humans edit content, and not a bunch of malevolent bots.
That is a *very good point* and I think you are perfectly right: we
should put it into Doco. Any idea on how to do it?
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 28, 2003, at 13:10 Europe/Rome, Steven Noels wrote:
> Stefano Mazzocchi wrote:
>
>>> Doco came to my mind when finding
>>> http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
>> Can I be anal for a sec?
>
> LOL. Sure, as long as you wipe properly afterwards, no problem here.
> :-)
>
>> cool, but what do we do with it?
>
> Well, since people had to come up with anti-spam measures for weblog
> comments, because of some nitwits which abuse the comment facility of
> modern weblog engines using automated tools, to raise Google rankings
> of spam-linked websites, I figure the same will start happening with
> any light-weight content contribution tool in the upcoming months.
>
> We have seen similar abuse on the Cocoon wiki as well. Rather than
> completely offload the burden of moderation to a bunch of people, we
> should come up with an upfront facility for blocking automated abuse.
> Similar to the facilities found in MSN Hotmail, Paypal and others who
> use some generated image to validate sign up for their system, having
> something like this Sapience thing might reduce the moderation burden
> in the long run.
>
> It's cool for sure, but it might be some good way to make sure only
> humans edit content, and not a bunch of malevolent bots.
That is a *very good point* and I think you are perfectly right: we
should put it into Doco. Any idea on how to do it?
--
Stefano.
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 28, 2003, at 13:10 Europe/Rome, Steven Noels wrote:
> Stefano Mazzocchi wrote:
>
>>> Doco came to my mind when finding
>>> http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
>> Can I be anal for a sec?
>
> LOL. Sure, as long as you wipe properly afterwards, no problem here.
> :-)
>
>> cool, but what do we do with it?
>
> Well, since people had to come up with anti-spam measures for weblog
> comments, because of some nitwits which abuse the comment facility of
> modern weblog engines using automated tools, to raise Google rankings
> of spam-linked websites, I figure the same will start happening with
> any light-weight content contribution tool in the upcoming months.
>
> We have seen similar abuse on the Cocoon wiki as well. Rather than
> completely offload the burden of moderation to a bunch of people, we
> should come up with an upfront facility for blocking automated abuse.
> Similar to the facilities found in MSN Hotmail, Paypal and others who
> use some generated image to validate sign up for their system, having
> something like this Sapience thing might reduce the moderation burden
> in the long run.
>
> It's cool for sure, but it might be some good way to make sure only
> humans edit content, and not a bunch of malevolent bots.
That is a *very good point* and I think you are perfectly right: we
should put it into Doco. Any idea on how to do it?
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 28, 2003, at 13:10 Europe/Rome, Steven Noels wrote:
> Stefano Mazzocchi wrote:
>
>>> Doco came to my mind when finding
>>> http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
>> Can I be anal for a sec?
>
> LOL. Sure, as long as you wipe properly afterwards, no problem here.
> :-)
>
>> cool, but what do we do with it?
>
> Well, since people had to come up with anti-spam measures for weblog
> comments, because of some nitwits which abuse the comment facility of
> modern weblog engines using automated tools, to raise Google rankings
> of spam-linked websites, I figure the same will start happening with
> any light-weight content contribution tool in the upcoming months.
>
> We have seen similar abuse on the Cocoon wiki as well. Rather than
> completely offload the burden of moderation to a bunch of people, we
> should come up with an upfront facility for blocking automated abuse.
> Similar to the facilities found in MSN Hotmail, Paypal and others who
> use some generated image to validate sign up for their system, having
> something like this Sapience thing might reduce the moderation burden
> in the long run.
>
> It's cool for sure, but it might be some good way to make sure only
> humans edit content, and not a bunch of malevolent bots.
That is a *very good point* and I think you are perfectly right: we
should put it into Doco. Any idea on how to do it?
--
Stefano.
Re: [proposal] Doco
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
>> Doco came to my mind when finding
>> http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
>
>
> Can I be anal for a sec?
LOL. Sure, as long as you wipe properly afterwards, no problem here. :-)
> cool, but what do we do with it?
Well, since people had to come up with anti-spam measures for weblog
comments, because of some nitwits which abuse the comment facility of
modern weblog engines using automated tools, to raise Google rankings of
spam-linked websites, I figure the same will start happening with any
light-weight content contribution tool in the upcoming months.
We have seen similar abuse on the Cocoon wiki as well. Rather than
completely offload the burden of moderation to a bunch of people, we
should come up with an upfront facility for blocking automated abuse.
Similar to the facilities found in MSN Hotmail, Paypal and others who
use some generated image to validate sign up for their system, having
something like this Sapience thing might reduce the moderation burden in
the long run.
It's cool for sure, but it might be some good way to make sure only
humans edit content, and not a bunch of malevolent bots.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
>> Doco came to my mind when finding
>> http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
>
>
> Can I be anal for a sec?
LOL. Sure, as long as you wipe properly afterwards, no problem here. :-)
> cool, but what do we do with it?
Well, since people had to come up with anti-spam measures for weblog
comments, because of some nitwits which abuse the comment facility of
modern weblog engines using automated tools, to raise Google rankings of
spam-linked websites, I figure the same will start happening with any
light-weight content contribution tool in the upcoming months.
We have seen similar abuse on the Cocoon wiki as well. Rather than
completely offload the burden of moderation to a bunch of people, we
should come up with an upfront facility for blocking automated abuse.
Similar to the facilities found in MSN Hotmail, Paypal and others who
use some generated image to validate sign up for their system, having
something like this Sapience thing might reduce the moderation burden in
the long run.
It's cool for sure, but it might be some good way to make sure only
humans edit content, and not a bunch of malevolent bots.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [proposal] Doco
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
>> Doco came to my mind when finding
>> http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
>
>
> Can I be anal for a sec?
LOL. Sure, as long as you wipe properly afterwards, no problem here. :-)
> cool, but what do we do with it?
Well, since people had to come up with anti-spam measures for weblog
comments, because of some nitwits which abuse the comment facility of
modern weblog engines using automated tools, to raise Google rankings of
spam-linked websites, I figure the same will start happening with any
light-weight content contribution tool in the upcoming months.
We have seen similar abuse on the Cocoon wiki as well. Rather than
completely offload the burden of moderation to a bunch of people, we
should come up with an upfront facility for blocking automated abuse.
Similar to the facilities found in MSN Hotmail, Paypal and others who
use some generated image to validate sign up for their system, having
something like this Sapience thing might reduce the moderation burden in
the long run.
It's cool for sure, but it might be some good way to make sure only
humans edit content, and not a bunch of malevolent bots.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
>> Doco came to my mind when finding
>> http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
>
>
> Can I be anal for a sec?
LOL. Sure, as long as you wipe properly afterwards, no problem here. :-)
> cool, but what do we do with it?
Well, since people had to come up with anti-spam measures for weblog
comments, because of some nitwits which abuse the comment facility of
modern weblog engines using automated tools, to raise Google rankings of
spam-linked websites, I figure the same will start happening with any
light-weight content contribution tool in the upcoming months.
We have seen similar abuse on the Cocoon wiki as well. Rather than
completely offload the burden of moderation to a bunch of people, we
should come up with an upfront facility for blocking automated abuse.
Similar to the facilities found in MSN Hotmail, Paypal and others who
use some generated image to validate sign up for their system, having
something like this Sapience thing might reduce the moderation burden in
the long run.
It's cool for sure, but it might be some good way to make sure only
humans edit content, and not a bunch of malevolent bots.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 28, 2003, at 10:11 Europe/Rome, Steven Noels wrote:
> Stefano Mazzocchi wrote:
>
>> 2) minimal, efficient and secure workflow (should satisfy board@
>> security concerns)
>
> FWIW:
>
> Doco came to my mind when finding
> http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
Can I be anal for a sec? cool, but what do we do with it?
> --
Stefano.
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 28, 2003, at 10:11 Europe/Rome, Steven Noels wrote:
> Stefano Mazzocchi wrote:
>
>> 2) minimal, efficient and secure workflow (should satisfy board@
>> security concerns)
>
> FWIW:
>
> Doco came to my mind when finding
> http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
Can I be anal for a sec? cool, but what do we do with it?
> --
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 28, 2003, at 10:11 Europe/Rome, Steven Noels wrote:
> Stefano Mazzocchi wrote:
>
>> 2) minimal, efficient and secure workflow (should satisfy board@
>> security concerns)
>
> FWIW:
>
> Doco came to my mind when finding
> http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
Can I be anal for a sec? cool, but what do we do with it?
> --
Stefano.
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 28, 2003, at 10:11 Europe/Rome, Steven Noels wrote:
> Stefano Mazzocchi wrote:
>
>> 2) minimal, efficient and secure workflow (should satisfy board@
>> security concerns)
>
> FWIW:
>
> Doco came to my mind when finding
> http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
Can I be anal for a sec? cool, but what do we do with it?
> --
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> 2) minimal, efficient and secure workflow (should satisfy board@
> security concerns)
FWIW:
Doco came to my mind when finding
http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> First of all, sorry for the massive cross-post, but I think it is going
> to be a great opportunity for all the communities involved to show off
> their potentials with the apache infrastructure.
>
> The proposal is about the creation of a content management system for
> apache projects, codenamed "Doco"
+1 from me from the Forrest side.
What I really like of this proposal is the SOC, Separation of Concerns
between communities. I particularly like Forrest's rols, as it it
*exactly* what we have been doing till now.
..
> Frontend/staging will be Forrest. The idea, in order to satify
> intrastructure@ concerns is
>
> 1) forrest runs on top of the repository and generates a staged version
> of the web site (not on minotaur!)
>
> 2) a cron job on minotaur will
>
> a) download the entire site from the staging area (using rsync, wget
> or similar tools)
> b) commit it on the "site" module CVS
> c) move it on the public site folder
>
> The reason for such an "inverted" architecture is to avoid having an SSH
> access directly from the machine that runs forrestbot. This guarantees
> *COMPLETE* isolation of minotaur from the rest of the system. There is
> *NO* way for somebody to hack into any parts of doco and obtain access
> to minotaur.
>
> The reason for committing a copy on CVS is to allow infrastructure@ to
> have a fresh copy of the web site in case something happens and Doco is
> down. [they have expressed concerns about this]
+1 to this for now.
This is basically what ForrestBot does now, and the only thing needed is
to install it on Apache hardware, and separate it in two parts (minotaur
and moof).
...
> 7) install lenya, james, forrest and forrestbot on Moof.
Ok, this has TBD, where do we go from here?
> 6) write the cron scripts for minotaur
This is just after.
> I propose the creation of a new CVS module called "cocoon-doco" to host
> the scripts, installation instructions and doco-specific code.
+1
> I also propose the discussions to take place on lenya-dev, given that
> Lenya is the community focused on content management. Interested people
> are invited to join lenya-dev@cocoon.apache.org.
Ok.
Let's now move the task of installing the Forrestbot over to the
forrest-dev and infrastructure lists then. When it's working, we'll let
you know.
> [in case of community-oriented you reply to this email, please, keep all
> listed cross-posted, but in case of technical discussions, please, let's
> move it over to lenya-dev to avoid mailbombing people that don't really
> care]
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Oct 27, 2003, at 16:22 Europe/Rome, Gianugo Rabellino wrote:
> Stefano Mazzocchi wrote:
>
>>>> Slide is dead, is has always been and there is nobody really
>>>> willing to change this.
>>>> JSR170 is still a moving target much worse than Subversion. The
>>>> reference implementation is available at
>>>> jakarta-slide/proposals/jcrri, but it moves along with the spec
>>>> and, believe me, there are a *lot* of things that are going to
>>>> change in the future.
>>>> [I know this because I've been here in Basel for the last 4 days
>>>> talking exactly about this]
>>>
>>>
>>> OK then. Two very good reasons (to me) to switch to a WebDAV++
>>> server, meaning plain WebDAV on the backend plus components in user
>>> space (like versioning and, maybe - if you don't want to use
>>> Catacomb, searching).
>> "components in user space"?
>
> Yes, very bad wording. :-) The idea is that if the repository doesn't
> support versioning, you can do it on your own, just as you did with
> Linotype (after all, we just need linear versioning). Same goes for
> searching: it's pretty trivial to implement a DASL layer on a WebDAV
> server proxied by Cocoon.
Ah, gotcha now. I agree.
>>>> But I am probably too lazy to write a cliuent API for subversion so
>>>> I might well switch to something else if the client APIs are
>>>> already written.
>>>> WDYT?
>>>
>>>
>>> WebDAV, WebDAV, WebDAV! :-))
>> Ok, what do you suggest then? [first hand help in setting up the
>> server would be even more appreciated! I can have Pier give you an
>> account on moof if you want]
>
> Go ahead, I did it so many times that it will be a piece of cake.
Cool. I'll ask Fred or Pier to give you an account.
> Once we have a (controlled) DAV server to play with, we can start
> working on top of it, adding all the required functionalities. I'm
> sure that me, Guido and Unico will happily join you in this effort for
> the DAV backend.
Very well. the more we are, the better.
> (next on my agenda: make Doco ESI aware and convince someone to
> develop mod_esi: seamless www mirroring worldwide. I guess
> infrastructure would just love it :-)).
I think so to. Akamai for the masses ;-)
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Gianugo Rabellino <gi...@apache.org>.
Stefano Mazzocchi wrote:
>>> Slide is dead, is has always been and there is nobody really willing
>>> to change this.
>>> JSR170 is still a moving target much worse than Subversion. The
>>> reference implementation is available at
>>> jakarta-slide/proposals/jcrri, but it moves along with the spec and,
>>> believe me, there are a *lot* of things that are going to change in
>>> the future.
>>> [I know this because I've been here in Basel for the last 4 days
>>> talking exactly about this]
>>
>>
>> OK then. Two very good reasons (to me) to switch to a WebDAV++ server,
>> meaning plain WebDAV on the backend plus components in user space
>> (like versioning and, maybe - if you don't want to use Catacomb,
>> searching).
>
>
> "components in user space"?
Yes, very bad wording. :-) The idea is that if the repository doesn't
support versioning, you can do it on your own, just as you did with
Linotype (after all, we just need linear versioning). Same goes for
searching: it's pretty trivial to implement a DASL layer on a WebDAV
server proxied by Cocoon.
>>> But I am probably too lazy to write a cliuent API for subversion so I
>>> might well switch to something else if the client APIs are already
>>> written.
>>> WDYT?
>>
>>
>> WebDAV, WebDAV, WebDAV! :-))
>
>
> Ok, what do you suggest then? [first hand help in setting up the server
> would be even more appreciated! I can have Pier give you an account on
> moof if you want]
Go ahead, I did it so many times that it will be a piece of cake.
Once we have a (controlled) DAV server to play with, we can start
working on top of it, adding all the required functionalities. I'm sure
that me, Guido and Unico will happily join you in this effort for the
DAV backend.
(next on my agenda: make Doco ESI aware and convince someone to develop
mod_esi: seamless www mirroring worldwide. I guess infrastructure would
just love it :-)).
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Oct 26, 2003, at 18:31 Europe/Rome, Gianugo Rabellino wrote:
> Stefano Mazzocchi wrote:
>> On Friday, Oct 24, 2003, at 09:58 Europe/Rome, Gianugo Rabellino
>> wrote:
>>> Ciao Stefano,
>>>
>>>> First of all, sorry for the massive cross-post, but I think it is
>>>> going to be a great opportunity for all the communities involved to
>>>> show off their potentials with the apache infrastructure.
>>>> The proposal is about the creation of a content management system
>>>> for apache projects, codenamed "Doco"
>>>
>>>
>>> first of all, thanks for the proposal. I particularirly appreciate
>>> the effort in ensuring Apache wide acceptance (even though I still
>>> think that something should change inside the foundation wrt web
>>> publishing issues if we want to move forward, but that's another
>>> point).
>> in order to move forward, we have to gain respect, we have to show
>> functionality and care for infrastructural concerns. java people are
>> great at the first, but normally lack the second. it is time we show
>> the infrastructure team we can do something that is both
>> pretty/useful yet solid and safe.
>
> Point taken, and can't agree more on java people being a bit green on
> infrastructure issues. As a former sysadm, I can guarantee how hard
> has been dealing with java projects in the past. ;-)
I think it is time to show that java is not evil just because it's java.
>> fter this, we will attack the problem of having more dynamism at the
>> frontend, but this phase two of the game. respect is not immediate to
>> earn.
>>> Technically wise, I have a major concern with your proposed
>>> architecture, which is about the Subversion usage.
>> I was expecting that ;-)
>
> I knew you were going to reply just that ;-)
eheh
>>> While I am a major svn fan (I use it whenever possible as a CVS
>>> replacement), I really don't think that it belongs here. Subversion,
>>> if considered as a repository server on its own, has a set of
>>> serious drawbacks:
>>>
>>> 1. it's not meant to be used (except for vanilla RFC2518 operations)
>>> without an svn client;
>> true
>>> 2. it uses a set of proprietary extensions to WebDAV which, besides,
>>> are due to disappear sometimes in favor of real DeltaV.
>> might be true, but there is no real DeltaV server anyway, so I find
>> this point rather moot.
>
> Well, if you consider that _eventually_ Subversion will support
> DeltaV, I find rather unuseful to spread blood, sweat and tears (the
> svn protocol for versioning is quite hard) in something that will be
> (eventually) abandoned.
true. good point.
>>> 3. it requires quite a deal of work to implement a native java
>>> access layer: so far all the java apps/libs dealing with subversion
>>> are either JNI wrappers around the C library or command line
>>> wrappers who call svn directly (yuck).
>> yes, I dislike the JNI approach as well, even if I perfectly
>> understand why they do it.
>>> Maybe I'm missing domething from the overall picture but I, for one,
>>> would avoid messing up with a non-standard, still somehow unstable
>>> and hard-to-deal-with platform such as Subversion.
>> yes, I think you are missing one big thing: psycology.
>
> Yes, I see that point too. But I'm still afraid that it would require
> just too much pain for the gain. Doco should, as much as possible,
> *use* an existing repository, not focus on accessing it: there are
> quite a few things to do already, without having to focus on the
> repository itself. ATM, the effort required to talk to a subversion
> server is, IMO, just too much.
Since I know that you have investigated just that and I haven't (I have
just sniffed some trafic between the client and the server, just to
have an idea), I think you are in a better position than I am to judge
this.
>>> Especially when you consider that we might want to move to JSR170
>>> sometimes and that *right now* we have two alternatives on the table
>>> when thinking of plain WebDAV:
>>>
>>> 1. Slide. It's more Apachey than Subversion, and this might be a
>>> boost to the Slide community which is pretty stuck. Slide, besides,
>>> will be the JSR170 RI, which is an added bonus.
>> Slide is dead, is has always been and there is nobody really willing
>> to change this.
>> JSR170 is still a moving target much worse than Subversion. The
>> reference implementation is available at
>> jakarta-slide/proposals/jcrri, but it moves along with the spec and,
>> believe me, there are a *lot* of things that are going to change in
>> the future.
>> [I know this because I've been here in Basel for the last 4 days
>> talking exactly about this]
>
> OK then. Two very good reasons (to me) to switch to a WebDAV++ server,
> meaning plain WebDAV on the backend plus components in user space
> (like versioning and, maybe - if you don't want to use Catacomb,
> searching).
"components in user space"?
>>> 2. mod_dav with or without Catacomb. Catacomb requires a SQL server
>>> (with our latest additions it could well be Postgres, tough we do
>>> have MySQL working on ASF infrastructure) and will get you all the
>>> required functionality (WebDAV + DASL + linear DeltaV) OOTB.
>> Catacomb was (and still is) my second choice.
>>> Now, I might be missing something from the picture: could you please
>>> enlighten me on the reason to choose Subversion as the main
>>> repository for Doco?
>> Simple, it is going to please the infrastructure guys ;-)
>
> Weeeell, I can see that, but I guess that mod_dav would be OK to them
> too. :-)
True.
>> But I am probably too lazy to write a client API for subversion so I
>> might well switch to something else if the client APIs are already
>> written.
>> WDYT?
>
> WebDAV, WebDAV, WebDAV! :-))
Ok, what do you suggest then? [first hand help in setting up the server
would be even more appreciated! I can have Pier give you an account on
moof if you want]
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Gianugo Rabellino <gi...@apache.org>.
Stefano Mazzocchi wrote:
>
> On Friday, Oct 24, 2003, at 09:58 Europe/Rome, Gianugo Rabellino wrote:
>
>> Ciao Stefano,
>>
>>> First of all, sorry for the massive cross-post, but I think it is
>>> going to be a great opportunity for all the communities involved to
>>> show off their potentials with the apache infrastructure.
>>> The proposal is about the creation of a content management system for
>>> apache projects, codenamed "Doco"
>>
>>
>> first of all, thanks for the proposal. I particularirly appreciate the
>> effort in ensuring Apache wide acceptance (even though I still think
>> that something should change inside the foundation wrt web publishing
>> issues if we want to move forward, but that's another point).
>
>
> in order to move forward, we have to gain respect, we have to show
> functionality and care for infrastructural concerns. java people are
> great at the first, but normally lack the second. it is time we show the
> infrastructure team we can do something that is both pretty/useful yet
> solid and safe.
Point taken, and can't agree more on java people being a bit green on
infrastructure issues. As a former sysadm, I can guarantee how hard has
been dealing with java projects in the past. ;-)
> After this, we will attack the problem of having more dynamism at the
> frontend, but this phase two of the game. respect is not immediate to earn.
>
>> Technically wise, I have a major concern with your proposed
>> architecture, which is about the Subversion usage.
>
>
> I was expecting that ;-)
I knew you were going to reply just that ;-)
>
>> While I am a major svn fan (I use it whenever possible as a CVS
>> replacement), I really don't think that it belongs here. Subversion,
>> if considered as a repository server on its own, has a set of serious
>> drawbacks:
>>
>> 1. it's not meant to be used (except for vanilla RFC2518 operations)
>> without an svn client;
>
> true
>
>> 2. it uses a set of proprietary extensions to WebDAV which, besides,
>> are due to disappear sometimes in favor of real DeltaV.
>
>
> might be true, but there is no real DeltaV server anyway, so I find this
> point rather moot.
Well, if you consider that _eventually_ Subversion will support DeltaV,
I find rather unuseful to spread blood, sweat and tears (the svn
protocol for versioning is quite hard) in something that will be
(eventually) abandoned.
>> 3. it requires quite a deal of work to implement a native java access
>> layer: so far all the java apps/libs dealing with subversion are
>> either JNI wrappers around the C library or command line wrappers who
>> call svn directly (yuck).
>
>
> yes, I dislike the JNI approach as well, even if I perfectly understand
> why they do it.
>
>> Maybe I'm missing domething from the overall picture but I, for one,
>> would avoid messing up with a non-standard, still somehow unstable and
>> hard-to-deal-with platform such as Subversion.
>
>
> yes, I think you are missing one big thing: psycology.
>
Yes, I see that point too. But I'm still afraid that it would require
just too much pain for the gain. Doco should, as much as possible, *use*
an existing repository, not focus on accessing it: there are quite a few
things to do already, without having to focus on the repository itself.
ATM, the effort required to talk to a subversion server is, IMO, just
too much.
>> Especially when you consider that we might want to move to JSR170
>> sometimes and that *right now* we have two alternatives on the table
>> when thinking of plain WebDAV:
>>
>> 1. Slide. It's more Apachey than Subversion, and this might be a boost
>> to the Slide community which is pretty stuck. Slide, besides, will be
>> the JSR170 RI, which is an added bonus.
>
>
> Slide is dead, is has always been and there is nobody really willing to
> change this.
>
> JSR170 is still a moving target much worse than Subversion. The
> reference implementation is available at jakarta-slide/proposals/jcrri,
> but it moves along with the spec and, believe me, there are a *lot* of
> things that are going to change in the future.
>
> [I know this because I've been here in Basel for the last 4 days talking
> exactly about this]
OK then. Two very good reasons (to me) to switch to a WebDAV++ server,
meaning plain WebDAV on the backend plus components in user space (like
versioning and, maybe - if you don't want to use Catacomb, searching).
>> 2. mod_dav with or without Catacomb. Catacomb requires a SQL server
>> (with our latest additions it could well be Postgres, tough we do have
>> MySQL working on ASF infrastructure) and will get you all the required
>> functionality (WebDAV + DASL + linear DeltaV) OOTB.
>
>
> Catacomb was (and still is) my second choice.
>
>> Now, I might be missing something from the picture: could you please
>> enlighten me on the reason to choose Subversion as the main repository
>> for Doco?
>
>
> Simple, it is going to please the infrastructure guys ;-)
Weeeell, I can see that, but I guess that mod_dav would be OK to them
too. :-)
> But I am probably too lazy to write a client API for subversion so I
> might well switch to something else if the client APIs are already written.
>
> WDYT?
>
WebDAV, WebDAV, WebDAV! :-))
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Oct 24, 2003, at 09:58 Europe/Rome, Gianugo Rabellino wrote:
> Ciao Stefano,
>
>> First of all, sorry for the massive cross-post, but I think it is
>> going to be a great opportunity for all the communities involved to
>> show off their potentials with the apache infrastructure.
>> The proposal is about the creation of a content management system for
>> apache projects, codenamed "Doco"
>
> first of all, thanks for the proposal. I particularirly appreciate the
> effort in ensuring Apache wide acceptance (even though I still think
> that something should change inside the foundation wrt web publishing
> issues if we want to move forward, but that's another point).
in order to move forward, we have to gain respect, we have to show
functionality and care for infrastructural concerns. java people are
great at the first, but normally lack the second. it is time we show
the infrastructure team we can do something that is both pretty/useful
yet solid and safe.
After this, we will attack the problem of having more dynamism at the
frontend, but this phase two of the game. respect is not immediate to
earn.
> Technically wise, I have a major concern with your proposed
> architecture, which is about the Subversion usage.
I was expecting that ;-)
> While I am a major svn fan (I use it whenever possible as a CVS
> replacement), I really don't think that it belongs here. Subversion,
> if considered as a repository server on its own, has a set of serious
> drawbacks:
>
> 1. it's not meant to be used (except for vanilla RFC2518 operations)
> without an svn client;
true
> 2. it uses a set of proprietary extensions to WebDAV which, besides,
> are due to disappear sometimes in favor of real DeltaV.
might be true, but there is no real DeltaV server anyway, so I find
this point rather moot.
> 3. it requires quite a deal of work to implement a native java access
> layer: so far all the java apps/libs dealing with subversion are
> either JNI wrappers around the C library or command line wrappers who
> call svn directly (yuck).
yes, I dislike the JNI approach as well, even if I perfectly understand
why they do it.
> Maybe I'm missing domething from the overall picture but I, for one,
> would avoid messing up with a non-standard, still somehow unstable and
> hard-to-deal-with platform such as Subversion.
yes, I think you are missing one big thing: psycology.
> Especially when you consider that we might want to move to JSR170
> sometimes and that *right now* we have two alternatives on the table
> when thinking of plain WebDAV:
>
> 1. Slide. It's more Apachey than Subversion, and this might be a boost
> to the Slide community which is pretty stuck. Slide, besides, will be
> the JSR170 RI, which is an added bonus.
Slide is dead, is has always been and there is nobody really willing to
change this.
JSR170 is still a moving target much worse than Subversion. The
reference implementation is available at jakarta-slide/proposals/jcrri,
but it moves along with the spec and, believe me, there are a *lot* of
things that are going to change in the future.
[I know this because I've been here in Basel for the last 4 days
talking exactly about this]
> 2. mod_dav with or without Catacomb. Catacomb requires a SQL server
> (with our latest additions it could well be Postgres, tough we do have
> MySQL working on ASF infrastructure) and will get you all the required
> functionality (WebDAV + DASL + linear DeltaV) OOTB.
Catacomb was (and still is) my second choice.
> Now, I might be missing something from the picture: could you please
> enlighten me on the reason to choose Subversion as the main repository
> for Doco?
Simple, it is going to please the infrastructure guys ;-)
But I am probably too lazy to write a client API for subversion so I
might well switch to something else if the client APIs are already
written.
WDYT?
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Gianugo Rabellino <gi...@apache.org>.
Ciao Stefano,
> First of all, sorry for the massive cross-post, but I think it is going
> to be a great opportunity for all the communities involved to show off
> their potentials with the apache infrastructure.
>
> The proposal is about the creation of a content management system for
> apache projects, codenamed "Doco"
first of all, thanks for the proposal. I particularirly appreciate the
effort in ensuring Apache wide acceptance (even though I still think
that something should change inside the foundation wrt web publishing
issues if we want to move forward, but that's another point).
Technically wise, I have a major concern with your proposed
architecture, which is about the Subversion usage. While I am a major
svn fan (I use it whenever possible as a CVS replacement), I really
don't think that it belongs here. Subversion, if considered as a
repository server on its own, has a set of serious drawbacks:
1. it's not meant to be used (except for vanilla RFC2518 operations)
without an svn client;
2. it uses a set of proprietary extensions to WebDAV which, besides, are
due to disappear sometimes in favor of real DeltaV.
3. it requires quite a deal of work to implement a native java access
layer: so far all the java apps/libs dealing with subversion are either
JNI wrappers around the C library or command line wrappers who call svn
directly (yuck).
Maybe I'm missing domething from the overall picture but I, for one,
would avoid messing up with a non-standard, still somehow unstable and
hard-to-deal-with platform such as Subversion. Especially when you
consider that we might want to move to JSR170 sometimes and that *right
now* we have two alternatives on the table when thinking of plain WebDAV:
1. Slide. It's more Apachey than Subversion, and this might be a boost
to the Slide community which is pretty stuck. Slide, besides, will be
the JSR170 RI, which is an added bonus.
2. mod_dav with or without Catacomb. Catacomb requires a SQL server
(with our latest additions it could well be Postgres, tough we do have
MySQL working on ASF infrastructure) and will get you all the required
functionality (WebDAV + DASL + linear DeltaV) OOTB.
Now, I might be missing something from the picture: could you please
enlighten me on the reason to choose Subversion as the main repository
for Doco?
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> First of all, sorry for the massive cross-post, but I think it is going
> to be a great opportunity for all the communities involved to show off
> their potentials with the apache infrastructure.
>
> The proposal is about the creation of a content management system for
> apache projects, codenamed "Doco"
+1 from me from the Forrest side.
What I really like of this proposal is the SOC, Separation of Concerns
between communities. I particularly like Forrest's rols, as it it
*exactly* what we have been doing till now.
..
> Frontend/staging will be Forrest. The idea, in order to satify
> intrastructure@ concerns is
>
> 1) forrest runs on top of the repository and generates a staged version
> of the web site (not on minotaur!)
>
> 2) a cron job on minotaur will
>
> a) download the entire site from the staging area (using rsync, wget
> or similar tools)
> b) commit it on the "site" module CVS
> c) move it on the public site folder
>
> The reason for such an "inverted" architecture is to avoid having an SSH
> access directly from the machine that runs forrestbot. This guarantees
> *COMPLETE* isolation of minotaur from the rest of the system. There is
> *NO* way for somebody to hack into any parts of doco and obtain access
> to minotaur.
>
> The reason for committing a copy on CVS is to allow infrastructure@ to
> have a fresh copy of the web site in case something happens and Doco is
> down. [they have expressed concerns about this]
+1 to this for now.
This is basically what ForrestBot does now, and the only thing needed is
to install it on Apache hardware, and separate it in two parts (minotaur
and moof).
...
> 7) install lenya, james, forrest and forrestbot on Moof.
Ok, this has TBD, where do we go from here?
> 6) write the cron scripts for minotaur
This is just after.
> I propose the creation of a new CVS module called "cocoon-doco" to host
> the scripts, installation instructions and doco-specific code.
+1
> I also propose the discussions to take place on lenya-dev, given that
> Lenya is the community focused on content management. Interested people
> are invited to join lenya-dev@cocoon.apache.org.
Ok.
Let's now move the task of installing the Forrestbot over to the
forrest-dev and infrastructure lists then. When it's working, we'll let
you know.
> [in case of community-oriented you reply to this email, please, keep all
> listed cross-posted, but in case of technical discussions, please, let's
> move it over to lenya-dev to avoid mailbombing people that don't really
> care]
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [proposal] Doco
Posted by Geoff Howard <co...@leverageweb.com>.
Vadim Gritsenko wrote:
> Geoff Howard wrote:
>
>>>> The one part that stands out to me as a weak link is the "reply"
>>>> vs. "reply to all" mechanism. It seems prone to human errors and to
>>>> things like vacation messages. How would conflicts be handled (one
>>>> person rejects and one approves)?
>>>
> ...
>
>> I agree that the accept=Reply, reject=Reply To All feels a little
>> hacky but I also see there's not a lot of great options. Would
>> subject line = approve/reject be a better compromise? Maybe the
>> default line could have "accept" and no subject would mean "reject".
>> So reply would mean accept and delete the subject and reply would
>> mean reject?
>
>
> Background: that's how current apache mail list moderation system
> works. Anybody who moderated any apache list will feel at home with
> proposed system.
Ah, that does change things in my mind. My only experience with
moderation of our lists is when I send with the wrong address :) and am
a moderat-ee!
Geoff
Re: [proposal] Doco
Posted by Vadim Gritsenko <va...@verizon.net>.
Geoff Howard wrote:
>>> The one part that stands out to me as a weak link is the "reply" vs.
>>> "reply to all" mechanism. It seems prone to human errors and to
>>> things like vacation messages. How would conflicts be handled (one
>>> person rejects and one approves)?
>>
...
> I agree that the accept=Reply, reject=Reply To All feels a little
> hacky but I also see there's not a lot of great options. Would
> subject line = approve/reject be a better compromise? Maybe the
> default line could have "accept" and no subject would mean "reject".
> So reply would mean accept and delete the subject and reply would mean
> reject?
Background: that's how current apache mail list moderation system works.
Anybody who moderated any apache list will feel at home with proposed
system.
Vadim
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Saturday, Oct 25, 2003, at 00:37 Europe/Rome, Geoff Howard wrote:
>> This is still much easier than the current workflow with applying a
>> patch, committing to CVS, and so on, but less error prone than the
>> above approach.
>
> Again, does anyone really think the choice of this method should delay
> forward progress at all?
nah, don't worry, this is not delaying anything. Discussion is always
good, it keeps ideas sane.
--
Stefano.
Re: [proposal] Doco
Posted by Geoff Howard <co...@leverageweb.com>.
Joerg Heinicke wrote:
> Stefano wrote
>
>>> c) the email will have "reply-to" set to the "allow" action and
>>> a continuation ID. and will have the CC: header set to "reject" with
>>> the continuation ID. So, by "replying" to the email
>>> d) by hitting "reply", the workflow will approuve the changes
>>> e) by hitting "reply to all", the workflow will reject them
>>> with no further action
>
> Kenny Smith wrote:
>
>> Hi Stefano,
>>
>> I think the overall concept for this project is pretty cool and very
>> well thought out.
I agree. _Great_ proposal.
>> The one part that stands out to me as a weak link is the "reply" vs.
>> "reply to all" mechanism. It seems prone to human errors and to things
>> like vacation messages. How would conflicts be handled (one person
>> rejects and one approves)?
>>
>> At the very least, I would provide a mechanism that allows changes to
>> be just as easily revoked as they were approved so that late that one
>> night when someone accidentally hits "reply to all" instead of "reply"
>> that they can easily fix it.
>
> I can only join. Email workflow is bad in general, but additionally the
> above system is to much error prone. We should at least use the body
> with an explicite "accept" and "reject" in it. This can't be done by
> accident, while it can happen for sending a mail. But even this I don't
> like much. What about authorization? Are the committers registered with
> specific mail addresses? What happens if the preferred address changes?
I agree that the accept=Reply, reject=Reply To All feels a little hacky
but I also see there's not a lot of great options. Would subject line =
approve/reject be a better compromise? Maybe the default line could
have "accept" and no subject would mean "reject". So reply would mean
accept and delete the subject and reply would mean reject?
At the end of the day, I'd live with any of the proposals on the table.
The overall system is such a big step forward that I'd rather pick
anything that works technically and just go with it for now. It's not a
large group of people to communicate with to change the system later.
> I would like to see a little application, where a link in the mail
> points directly to the resource. The committer has to login and accept
> or reject the change. So conflict situations can also be much better
> handled and reverting changes should also be easier to be implemented.
I think Stefano has a good point on this - you can process offline and
"commit" when you next synch mail.
> This is still much easier than the current workflow with applying a
> patch, committing to CVS, and so on, but less error prone than the above
> approach.
Again, does anyone really think the choice of this method should delay
forward progress at all?
Geoff
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Oct 27, 2003, at 01:35 Europe/Rome, David Crossley wrote:
> Stefano Mazzocchi wrote:
>> Steven Noels wrote:
>>> Stefano Mazzocchi wrote:
> <snip what="stuff about wiki vandalism and annoyance"/>
>>
>> Different would be to have "f**k [insert your favorite public figure
>> here]" or child pornography passing thru the system, but in order to
>> happen, the chain of events that should happen are:
>>
>> 1) somebody does that kind of vandalism (so far, happened only a few
>> times)
>> 2) a moderator sends "reply-to" instead of "reply-to-all" and *NO
>> OTHER MODERATOR* does anything (the probability of this event is, IMO,
>> already rare, redundancy of moderation should also reduce errors)
>
> Unless i am mistaken, when there are multiple moderators then the
> first moderation action wins and subsequent actions have no effect.
> Redundancy of moderators just ensures that multiple people are always
> watching.
Not if moderation requires a lazy consensus approach, say at least 3 +1
and no -1. WDYT?
--
Stefano.
Re: [proposal] Doco
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
> Steven Noels wrote:
> > Stefano Mazzocchi wrote:
<snip what="stuff about wiki vandalism and annoyance"/>
>
> Different would be to have "f**k [insert your favorite public figure
> here]" or child pornography passing thru the system, but in order to
> happen, the chain of events that should happen are:
>
> 1) somebody does that kind of vandalism (so far, happened only a few
> times)
> 2) a moderator sends "reply-to" instead of "reply-to-all" and *NO
> OTHER MODERATOR* does anything (the probability of this event is, IMO,
> already rare, redundancy of moderation should also reduce errors)
Unless i am mistaken, when there are multiple moderators then the
first moderation action wins and subsequent actions have no effect.
Redundancy of moderators just ensures that multiple people are always
watching.
--David
> 3) the change is approved, approuval email is sent back to the
> moderators list and nobody goes to the backend of the system to revert
> the changes for 24 hours (again, pretty unlikely that I would receive
> an email that says "this change was accepted by "blah" see the diff
> inside" and I would just sit and watch... the 24 hour period should be
> enough to get at least one other moderator see it... keep in mind that
> moderators don't need to be necessarely committers)
>
> It is not impossible that such a chain of events happen. But it is not
> so prone to errors as it might seem at first sight. [well, at least
> that's my impression, practice might prove me dead wrong]
>
> > > That workflow is designed to prevent the vandalist acts but
> > > without slowing down the creative process.
> >
> > We definitely need some form of oversight. The current 'mass push' to
> > a mailing list appears to be working quite well IMHO.
>
> We need "pre-emptive oversight" if we want to have the slight chance of
> having the ASF infrastructure team allow us to use such a system in
> practice.
>
> --
> Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
> Steven Noels wrote:
> > Stefano Mazzocchi wrote:
<snip what="stuff about wiki vandalism and annoyance"/>
>
> Different would be to have "f**k [insert your favorite public figure
> here]" or child pornography passing thru the system, but in order to
> happen, the chain of events that should happen are:
>
> 1) somebody does that kind of vandalism (so far, happened only a few
> times)
> 2) a moderator sends "reply-to" instead of "reply-to-all" and *NO
> OTHER MODERATOR* does anything (the probability of this event is, IMO,
> already rare, redundancy of moderation should also reduce errors)
Unless i am mistaken, when there are multiple moderators then the
first moderation action wins and subsequent actions have no effect.
Redundancy of moderators just ensures that multiple people are always
watching.
--David
> 3) the change is approved, approuval email is sent back to the
> moderators list and nobody goes to the backend of the system to revert
> the changes for 24 hours (again, pretty unlikely that I would receive
> an email that says "this change was accepted by "blah" see the diff
> inside" and I would just sit and watch... the 24 hour period should be
> enough to get at least one other moderator see it... keep in mind that
> moderators don't need to be necessarely committers)
>
> It is not impossible that such a chain of events happen. But it is not
> so prone to errors as it might seem at first sight. [well, at least
> that's my impression, practice might prove me dead wrong]
>
> > > That workflow is designed to prevent the vandalist acts but
> > > without slowing down the creative process.
> >
> > We definitely need some form of oversight. The current 'mass push' to
> > a mailing list appears to be working quite well IMHO.
>
> We need "pre-emptive oversight" if we want to have the slight chance of
> having the ASF infrastructure team allow us to use such a system in
> practice.
>
> --
> Stefano.
Re: [proposal] Doco
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
> Steven Noels wrote:
> > Stefano Mazzocchi wrote:
<snip what="stuff about wiki vandalism and annoyance"/>
>
> Different would be to have "f**k [insert your favorite public figure
> here]" or child pornography passing thru the system, but in order to
> happen, the chain of events that should happen are:
>
> 1) somebody does that kind of vandalism (so far, happened only a few
> times)
> 2) a moderator sends "reply-to" instead of "reply-to-all" and *NO
> OTHER MODERATOR* does anything (the probability of this event is, IMO,
> already rare, redundancy of moderation should also reduce errors)
Unless i am mistaken, when there are multiple moderators then the
first moderation action wins and subsequent actions have no effect.
Redundancy of moderators just ensures that multiple people are always
watching.
--David
> 3) the change is approved, approuval email is sent back to the
> moderators list and nobody goes to the backend of the system to revert
> the changes for 24 hours (again, pretty unlikely that I would receive
> an email that says "this change was accepted by "blah" see the diff
> inside" and I would just sit and watch... the 24 hour period should be
> enough to get at least one other moderator see it... keep in mind that
> moderators don't need to be necessarely committers)
>
> It is not impossible that such a chain of events happen. But it is not
> so prone to errors as it might seem at first sight. [well, at least
> that's my impression, practice might prove me dead wrong]
>
> > > That workflow is designed to prevent the vandalist acts but
> > > without slowing down the creative process.
> >
> > We definitely need some form of oversight. The current 'mass push' to
> > a mailing list appears to be working quite well IMHO.
>
> We need "pre-emptive oversight" if we want to have the slight chance of
> having the ASF infrastructure team allow us to use such a system in
> practice.
>
> --
> Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
> Steven Noels wrote:
> > Stefano Mazzocchi wrote:
<snip what="stuff about wiki vandalism and annoyance"/>
>
> Different would be to have "f**k [insert your favorite public figure
> here]" or child pornography passing thru the system, but in order to
> happen, the chain of events that should happen are:
>
> 1) somebody does that kind of vandalism (so far, happened only a few
> times)
> 2) a moderator sends "reply-to" instead of "reply-to-all" and *NO
> OTHER MODERATOR* does anything (the probability of this event is, IMO,
> already rare, redundancy of moderation should also reduce errors)
Unless i am mistaken, when there are multiple moderators then the
first moderation action wins and subsequent actions have no effect.
Redundancy of moderators just ensures that multiple people are always
watching.
--David
> 3) the change is approved, approuval email is sent back to the
> moderators list and nobody goes to the backend of the system to revert
> the changes for 24 hours (again, pretty unlikely that I would receive
> an email that says "this change was accepted by "blah" see the diff
> inside" and I would just sit and watch... the 24 hour period should be
> enough to get at least one other moderator see it... keep in mind that
> moderators don't need to be necessarely committers)
>
> It is not impossible that such a chain of events happen. But it is not
> so prone to errors as it might seem at first sight. [well, at least
> that's my impression, practice might prove me dead wrong]
>
> > > That workflow is designed to prevent the vandalist acts but
> > > without slowing down the creative process.
> >
> > We definitely need some form of oversight. The current 'mass push' to
> > a mailing list appears to be working quite well IMHO.
>
> We need "pre-emptive oversight" if we want to have the slight chance of
> having the ASF infrastructure team allow us to use such a system in
> practice.
>
> --
> Stefano.
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Oct 24, 2003, at 15:57 Europe/Rome, Steven Noels wrote:
> Stefano Mazzocchi wrote:
>
>> In the entire history of the wiki, we had only a few cases of severe
>> vandalism on our wiki.
>
> Please don't over-generalize, Stefano. We have weekly 'annoyances' on
> the Cocoon Wiki ATM, but some people happen to clean them up sooner
> rather than later. I know the Wiki appears to be running smoothly, but
> it requires energy and handholding at times - these times even that
> much that I'm still hunting for some free moment to move it to moof.
> Ditto with moderation: I have at the very least 20 spam mails and
> viruses awaiting me in my moderation inbox (from all Cocoon lists) on
> a daily basis, some days more.
I'm sorry, I didn't make myself clear with the above:
my point was not that a document management system doesn't need work to
operate (being a wiki or something more complex doesn't matter), but
that since the "severe" vandalism (that vandalism that would be
"embarassing" for us in front of our public and in front of the ASF
board/members/infrastructure) frequency is very low, the "error
prone"-ness of the system (as was implied) has to be normalized with
that severity frequency.
I mean: if you get "look mom, I can modify an apache site" on
cocoon.apache.org because somebody wrongly hit reply instead of
reply-to-all, then nobody does anything for 24 hours and the above gets
published is not a big deal.
Different would be to have "f**k [insert your favorite public figure
here]" or child pornography passing thru the system, but in order to
happen, the chain of events that should happen are:
1) somebody does that kind of vandalism (so far, happened only a few
times)
2) a moderator sends "reply-to" instead of "reply-to-all" and *NO
OTHER MODERATOR* does anything (the probability of this event is, IMO,
already rare, redundancy of moderation should also reduce errors)
3) the change is approved, approuval email is sent back to the
moderators list and nobody goes to the backend of the system to revert
the changes for 24 hours (again, pretty unlikely that I would receive
an email that says "this change was accepted by "blah" see the diff
inside" and I would just sit and watch... the 24 hour period should be
enough to get at least one other moderator see it... keep in mind that
moderators don't need to be necessarely committers)
It is not impossible that such a chain of events happen. But it is not
so prone to errors as it might seem at first sight. [well, at least
that's my impression, practice might prove me dead wrong]
> > That workflow is designed to prevent the vandalist acts but
> > without slowing down the creative process.
>
> We definitely need some form of oversight. The current 'mass push' to
> a mailing list appears to be working quite well IMHO.
We need "pre-emptive oversight" if we want to have the slight chance of
having the ASF infrastructure team allow us to use such a system in
practice.
--
Stefano.
Re: [proposal] Doco
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> In the entire history of the wiki, we had only a few cases of severe
> vandalism on our wiki.
Please don't over-generalize, Stefano. We have weekly 'annoyances' on
the Cocoon Wiki ATM, but some people happen to clean them up sooner
rather than later. I know the Wiki appears to be running smoothly, but
it requires energy and handholding at times - these times even that much
that I'm still hunting for some free moment to move it to moof. Ditto
with moderation: I have at the very least 20 spam mails and viruses
awaiting me in my moderation inbox (from all Cocoon lists) on a daily
basis, some days more.
> That workflow is designed to prevent the vandalist acts but
> without slowing down the creative process.
We definitely need some form of oversight. The current 'mass push' to a
mailing list appears to be working quite well IMHO.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [proposal] Doco
Posted by Upayavira <uv...@upaya.co.uk>.
Vadim Gritsenko wrote:
> Upayavira wrote:
>
>> Joerg Heinicke wrote:
>> ...
>>
>>> Is offline/online still an issue?
>>
>>
>>
>> It is for me. Much of my Cocoon work (and some of my mailing list
>> reading) is done on a train to and from work, without net access. I
>> am equally concerned about whether I'll be able to work on the 'doco'
>> system myself without net access.
>
>
>
> I joined "the Cocoon train club" this week too
Welcome to the club! And welcome back!
Regards, Upayavira
Re: [proposal] Doco
Posted by Vadim Gritsenko <va...@verizon.net>.
Upayavira wrote:
> Joerg Heinicke wrote:
> ...
>
>> Is offline/online still an issue?
>
>
> It is for me. Much of my Cocoon work (and some of my mailing list
> reading) is done on a train to and from work, without net access. I am
> equally concerned about whether I'll be able to work on the 'doco'
> system myself without net access.
I joined "the Cocoon train club" this week too
Vadim
Re: [proposal] Doco
Posted by Upayavira <uv...@upaya.co.uk>.
Bertrand Delacretaz wrote:
> Le Samedi, 25 oct 2003, à 17:56 Europe/Zurich, Upayavira a écrit :
>
>> Joerg Heinicke wrote:
>> ...
>>
>>> Is offline/online still an issue?
>>
>>
>> It is for me. Much of my Cocoon work (and some of my mailing list
>> reading) is done on a train to and from work, without net access. I
>> am equally concerned about whether I'll be able to work on the 'doco'
>> system myself without net access.
>
>
> Same here. It'll take some time until we get reliable cheap fast wi-fi
> on trains I guess!
Especially the London Underground! (Although I have heard rumours that
in a few years they'll make mobiles work underground. Not sure whether
that's good or bad :-\ )
Upayavira
Re: [proposal] Doco
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Samedi, 25 oct 2003, à 17:56 Europe/Zurich, Upayavira a écrit :
> Joerg Heinicke wrote:
> ...
>
>> Is offline/online still an issue?
>
> It is for me. Much of my Cocoon work (and some of my mailing list
> reading) is done on a train to and from work, without net access. I am
> equally concerned about whether I'll be able to work on the 'doco'
> system myself without net access.
Same here. It'll take some time until we get reliable cheap fast wi-fi
on trains I guess!
-Bertrand
Re: [proposal] Doco
Posted by Upayavira <uv...@upaya.co.uk>.
Joerg Heinicke wrote:
...
> Is offline/online still an issue?
It is for me. Much of my Cocoon work (and some of my mailing list
reading) is done on a train to and from work, without net access. I am
equally concerned about whether I'll be able to work on the 'doco'
system myself without net access.
Regards, Upayavira
Re: [proposal] Doco
Posted by Geoff Howard <co...@leverageweb.com>.
Joerg Heinicke wrote:
> On 26.10.2003 01:49, Stefano Mazzocchi wrote:
>
>>>>> We should at least use the body with an explicite "accept" and
>>>>> "reject" in it. This can't be done by accident, while it can
>>>>> happen for sending a mail.
>>>>
>>>
>>> But why not at least explicite "accept"/"reject" in the subject or
>>> the body of a mail?
>>
>> saves you a couple of seconds per email. the easier the job, the more
>> people will do it.
>> more than errors, I'm concerned to people not moderating things thru.
>
Since 98.4% of all messages are going to be accepted (I've done careful
statistical analysis ;) ) you can get almost to the lazy status with
the subject line parsing if you use the reply to accept, reply with
modified /deleted subject to reject.
...
>> I say we try my lazy ass solution first and then, in case we find
>> problems with it, we change.
>> deal?
>
>
> Man, you must really be lazy ;-) So, yes, let's try your solution first.
And again, I'm fine either way but am obviously still partial to getting
rid of the reply-all in favor of the subject line.
Geoff
Re: [proposal] Doco
Posted by Joerg Heinicke <jh...@virbus.de>.
On 26.10.2003 01:49, Stefano Mazzocchi wrote:
>
>>>> We should at least use the body with an explicite "accept" and
>>>> "reject" in it. This can't be done by accident, while it can happen
>>>> for sending a mail.
>>
>>
>> But why not at least explicite "accept"/"reject" in the subject or the
>> body of a mail?
>
>
> saves you a couple of seconds per email. the easier the job, the more
> people will do it.
>
> more than errors, I'm concerned to people not moderating things thru.
>
>>>> I would like to see a little application, where a link in the mail
>>>> points directly to the resource. The committer has to login and
>>>> accept or reject the change. So conflict situations can also be much
>>>> better handled and reverting changes should also be easier to be
>>>> implemented.
>>>
>>> I dislike this, it stops me from doing auditing offline.
>>
>>
>> Is offline/online still an issue?
>
>
> It is for me. I want a system that works for me, does not force me to
> work for the system.
>
>> Furthermore we only talk about minutes if not seconds per day: the
>> mails are sent, you can read offline and decide whether to accept or
>> reject,, go online, click on the link in the mail, login, click
>> "accept" or "reject", finished. Even on the wiki not more than ten
>> pages change per day. We are many more committers.
>
>
> suppose that I'm online and reading email.
>
> your solution requires me to: move my hand on the mouse, click on the
> link [this opens the browser that will automatically fill the login page
> with my login/password], click login, approuve the change, go back to my
> email client.
>
> my solution requires two keystrokes
>
> your solution is easy enough, but I'm way more lazy than you can
> possibly imagine... I know me and I know that many fellow cocooners are
> as lazy as I am, this means that I will end up avoiding doing
> moderation, or forgetting altogether.
>
> this will result in a few people doing the moderation task only,
> increasing by orders of magnitude the errorprone-ness of the system and
> decreasing fault-tollerance by reducing distribution of laber and
> redundancy.
>
> I say we try my lazy ass solution first and then, in case we find
> problems with it, we change.
>
> deal?
Man, you must really be lazy ;-) So, yes, let's try your solution first.
Joerg
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Saturday, Oct 25, 2003, at 16:43 Europe/Rome, Joerg Heinicke wrote:
> On 24.10.2003 15:47, Stefano Mazzocchi wrote:
>> Joerg Heinicke wrote:
>>> We should at least use the body with an explicite "accept" and
>>> "reject" in it. This can't be done by accident, while it can happen
>>> for sending a mail.
>
> But why not at least explicite "accept"/"reject" in the subject or the
> body of a mail?
saves you a couple of seconds per email. the easier the job, the more
people will do it.
more than errors, I'm concerned to people not moderating things thru.
>>> I would like to see a little application, where a link in the mail
>>> points directly to the resource. The committer has to login and
>>> accept or reject the change. So conflict situations can also be much
>>> better handled and reverting changes should also be easier to be
>>> implemented.
>> I dislike this, it stops me from doing auditing offline.
>
> Is offline/online still an issue?
It is for me. I want a system that works for me, does not force me to
work for the system.
> Furthermore we only talk about minutes if not seconds per day: the
> mails are sent, you can read offline and decide whether to accept or
> reject,, go online, click on the link in the mail, login, click
> "accept" or "reject", finished. Even on the wiki not more than ten
> pages change per day. We are many more committers.
suppose that I'm online and reading email.
your solution requires me to: move my hand on the mouse, click on the
link [this opens the browser that will automatically fill the login
page with my login/password], click login, approuve the change, go back
to my email client.
my solution requires two keystrokes
your solution is easy enough, but I'm way more lazy than you can
possibly imagine... I know me and I know that many fellow cocooners are
as lazy as I am, this means that I will end up avoiding doing
moderation, or forgetting altogether.
this will result in a few people doing the moderation task only,
increasing by orders of magnitude the errorprone-ness of the system and
decreasing fault-tollerance by reducing distribution of laber and
redundancy.
I say we try my lazy ass solution first and then, in case we find
problems with it, we change.
deal?
--
Stefano.
Re: [proposal] Doco
Posted by Joerg Heinicke <jh...@virbus.de>.
On 24.10.2003 15:47, Stefano Mazzocchi wrote:
> Joerg Heinicke wrote:
>
>> We should at least use the body with an explicite "accept" and
>> "reject" in it. This can't be done by accident, while it can happen
>> for sending a mail.
But why not at least explicite "accept"/"reject" in the subject or the
body of a mail?
>> I would like to see a little application, where a link in the mail
>> points directly to the resource. The committer has to login and accept
>> or reject the change. So conflict situations can also be much better
>> handled and reverting changes should also be easier to be implemented.
>
>
> I dislike this, it stops me from doing auditing offline.
Is offline/online still an issue?
Furthermore we only talk about minutes if not seconds per day: the mails
are sent, you can read offline and decide whether to accept or reject,,
go online, click on the link in the mail, login, click "accept" or
"reject", finished. Even on the wiki not more than ten pages change per
day. We are many more committers.
Joerg
Re: [proposal] Doco
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> In the entire history of the wiki, we had only a few cases of severe
> vandalism on our wiki.
Please don't over-generalize, Stefano. We have weekly 'annoyances' on
the Cocoon Wiki ATM, but some people happen to clean them up sooner
rather than later. I know the Wiki appears to be running smoothly, but
it requires energy and handholding at times - these times even that much
that I'm still hunting for some free moment to move it to moof. Ditto
with moderation: I have at the very least 20 spam mails and viruses
awaiting me in my moderation inbox (from all Cocoon lists) on a daily
basis, some days more.
> That workflow is designed to prevent the vandalist acts but
> without slowing down the creative process.
We definitely need some form of oversight. The current 'mass push' to a
mailing list appears to be working quite well IMHO.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> In the entire history of the wiki, we had only a few cases of severe
> vandalism on our wiki.
Please don't over-generalize, Stefano. We have weekly 'annoyances' on
the Cocoon Wiki ATM, but some people happen to clean them up sooner
rather than later. I know the Wiki appears to be running smoothly, but
it requires energy and handholding at times - these times even that much
that I'm still hunting for some free moment to move it to moof. Ditto
with moderation: I have at the very least 20 spam mails and viruses
awaiting me in my moderation inbox (from all Cocoon lists) on a daily
basis, some days more.
> That workflow is designed to prevent the vandalist acts but
> without slowing down the creative process.
We definitely need some form of oversight. The current 'mass push' to a
mailing list appears to be working quite well IMHO.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
Joerg Heinicke wrote:
> Stefano wrote
>
>>> c) the email will have "reply-to" set to the "allow" action and
>>> a continuation ID. and will have the CC: header set to "reject" with
>>> the continuation ID. So, by "replying" to the email
>>> d) by hitting "reply", the workflow will approuve the changes
>>> e) by hitting "reply to all", the workflow will reject them
>>> with no further action
>
>
> Kenny Smith wrote:
>
>> Hi Stefano,
>>
>> I think the overall concept for this project is pretty cool and very
>> well thought out.
>>
>> The one part that stands out to me as a weak link is the "reply" vs.
>> "reply to all" mechanism. It seems prone to human errors and to things
>> like vacation messages. How would conflicts be handled (one person
>> rejects and one approves)?
>>
>> At the very least, I would provide a mechanism that allows changes to
>> be just as easily revoked as they were approved so that late that one
>> night when someone accidentally hits "reply to all" instead of "reply"
>> that they can easily fix it.
>
>
> I can only join. Email workflow is bad in general, but additionally the
> above system is to much error prone.
I has worked for the apache group since 1995. Yes, there are occasional
mistakes and some message gets moderated thru even if it shouldn't, but
compared to the traffic we get this is really nothing.
> We should at least use the body
> with an explicite "accept" and "reject" in it. This can't be done by
> accident, while it can happen for sending a mail. But even this I don't
> like much. What about authorization?
only "doc committers" are subscribed.
> Are the committers registered with
> specific mail addresses?
of course, how else?
> What happens if the preferred address changes?
they tell us and we change the address.
keep in mind that most of them are committers anyway, they will have an
@apache.org address that will never change.
> I would like to see a little application, where a link in the mail
> points directly to the resource. The committer has to login and accept
> or reject the change. So conflict situations can also be much better
> handled and reverting changes should also be easier to be implemented.
I dislike this, it stops me from doing auditing offline.
> > This is still much easier than the current workflow with applying a
> patch, committing to CVS, and so on, but less error prone than the above
> approach.
In the entire history of the wiki, we had only a few cases of severe
vandalism on our wiki. That workflow is designed to prevent the
vandalist acts but without slowing down the creative process.
--
Stefano.
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
Joerg Heinicke wrote:
> Stefano wrote
>
>>> c) the email will have "reply-to" set to the "allow" action and
>>> a continuation ID. and will have the CC: header set to "reject" with
>>> the continuation ID. So, by "replying" to the email
>>> d) by hitting "reply", the workflow will approuve the changes
>>> e) by hitting "reply to all", the workflow will reject them
>>> with no further action
>
>
> Kenny Smith wrote:
>
>> Hi Stefano,
>>
>> I think the overall concept for this project is pretty cool and very
>> well thought out.
>>
>> The one part that stands out to me as a weak link is the "reply" vs.
>> "reply to all" mechanism. It seems prone to human errors and to things
>> like vacation messages. How would conflicts be handled (one person
>> rejects and one approves)?
>>
>> At the very least, I would provide a mechanism that allows changes to
>> be just as easily revoked as they were approved so that late that one
>> night when someone accidentally hits "reply to all" instead of "reply"
>> that they can easily fix it.
>
>
> I can only join. Email workflow is bad in general, but additionally the
> above system is to much error prone.
I has worked for the apache group since 1995. Yes, there are occasional
mistakes and some message gets moderated thru even if it shouldn't, but
compared to the traffic we get this is really nothing.
> We should at least use the body
> with an explicite "accept" and "reject" in it. This can't be done by
> accident, while it can happen for sending a mail. But even this I don't
> like much. What about authorization?
only "doc committers" are subscribed.
> Are the committers registered with
> specific mail addresses?
of course, how else?
> What happens if the preferred address changes?
they tell us and we change the address.
keep in mind that most of them are committers anyway, they will have an
@apache.org address that will never change.
> I would like to see a little application, where a link in the mail
> points directly to the resource. The committer has to login and accept
> or reject the change. So conflict situations can also be much better
> handled and reverting changes should also be easier to be implemented.
I dislike this, it stops me from doing auditing offline.
> > This is still much easier than the current workflow with applying a
> patch, committing to CVS, and so on, but less error prone than the above
> approach.
In the entire history of the wiki, we had only a few cases of severe
vandalism on our wiki. That workflow is designed to prevent the
vandalist acts but without slowing down the creative process.
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
Joerg Heinicke wrote:
> Stefano wrote
>
>>> c) the email will have "reply-to" set to the "allow" action and
>>> a continuation ID. and will have the CC: header set to "reject" with
>>> the continuation ID. So, by "replying" to the email
>>> d) by hitting "reply", the workflow will approuve the changes
>>> e) by hitting "reply to all", the workflow will reject them
>>> with no further action
>
>
> Kenny Smith wrote:
>
>> Hi Stefano,
>>
>> I think the overall concept for this project is pretty cool and very
>> well thought out.
>>
>> The one part that stands out to me as a weak link is the "reply" vs.
>> "reply to all" mechanism. It seems prone to human errors and to things
>> like vacation messages. How would conflicts be handled (one person
>> rejects and one approves)?
>>
>> At the very least, I would provide a mechanism that allows changes to
>> be just as easily revoked as they were approved so that late that one
>> night when someone accidentally hits "reply to all" instead of "reply"
>> that they can easily fix it.
>
>
> I can only join. Email workflow is bad in general, but additionally the
> above system is to much error prone.
I has worked for the apache group since 1995. Yes, there are occasional
mistakes and some message gets moderated thru even if it shouldn't, but
compared to the traffic we get this is really nothing.
> We should at least use the body
> with an explicite "accept" and "reject" in it. This can't be done by
> accident, while it can happen for sending a mail. But even this I don't
> like much. What about authorization?
only "doc committers" are subscribed.
> Are the committers registered with
> specific mail addresses?
of course, how else?
> What happens if the preferred address changes?
they tell us and we change the address.
keep in mind that most of them are committers anyway, they will have an
@apache.org address that will never change.
> I would like to see a little application, where a link in the mail
> points directly to the resource. The committer has to login and accept
> or reject the change. So conflict situations can also be much better
> handled and reverting changes should also be easier to be implemented.
I dislike this, it stops me from doing auditing offline.
> > This is still much easier than the current workflow with applying a
> patch, committing to CVS, and so on, but less error prone than the above
> approach.
In the entire history of the wiki, we had only a few cases of severe
vandalism on our wiki. That workflow is designed to prevent the
vandalist acts but without slowing down the creative process.
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Joerg Heinicke <jh...@virbus.de>.
Stefano wrote
>> c) the email will have "reply-to" set to the "allow" action and
>> a continuation ID. and will have the CC: header set to "reject" with
>> the continuation ID. So, by "replying" to the email
>> d) by hitting "reply", the workflow will approuve the changes
>> e) by hitting "reply to all", the workflow will reject them with
>> no further action
Kenny Smith wrote:
> Hi Stefano,
>
> I think the overall concept for this project is pretty cool and very
> well thought out.
>
> The one part that stands out to me as a weak link is the "reply" vs.
> "reply to all" mechanism. It seems prone to human errors and to things
> like vacation messages. How would conflicts be handled (one person
> rejects and one approves)?
>
> At the very least, I would provide a mechanism that allows changes to be
> just as easily revoked as they were approved so that late that one night
> when someone accidentally hits "reply to all" instead of "reply" that
> they can easily fix it.
I can only join. Email workflow is bad in general, but additionally the
above system is to much error prone. We should at least use the body with an
explicite "accept" and "reject" in it. This can't be done by accident, while
it can happen for sending a mail. But even this I don't like much. What
about authorization? Are the committers registered with specific mail
addresses? What happens if the preferred address changes?
I would like to see a little application, where a link in the mail points
directly to the resource. The committer has to login and accept or reject
the change. So conflict situations can also be much better handled and
reverting changes should also be easier to be implemented.
This is still much easier than the current workflow with applying a patch,
committing to CVS, and so on, but less error prone than the above approach.
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
Re: [proposal] Doco
Posted by Kenny Smith <ja...@journalscape.com>.
Hi Stefano,
I think the overall concept for this project is pretty cool and very
well thought out.
The one part that stands out to me as a weak link is the "reply" vs.
"reply to all" mechanism. It seems prone to human errors and to things
like vacation messages. How would conflicts be handled (one person
rejects and one approves)?
At the very least, I would provide a mechanism that allows changes to be
just as easily revoked as they were approved so that late that one night
when someone accidentally hits "reply to all" instead of "reply" that
they can easily fix it.
Kenny
> c) the email will have "reply-to" set to the "allow" action and a
> continuation ID. and will have the CC: header set to "reject" with the
> continuation ID. So, by "replying" to the email
> d) by hitting "reply", the workflow will approuve the changes
> e) by hitting "reply to all", the workflow will reject them with
> no further action
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Kenny Smith <ja...@journalscape.com>.
Hi Stefano,
I think the overall concept for this project is pretty cool and very
well thought out.
The one part that stands out to me as a weak link is the "reply" vs.
"reply to all" mechanism. It seems prone to human errors and to things
like vacation messages. How would conflicts be handled (one person
rejects and one approves)?
At the very least, I would provide a mechanism that allows changes to be
just as easily revoked as they were approved so that late that one night
when someone accidentally hits "reply to all" instead of "reply" that
they can easily fix it.
Kenny
> c) the email will have "reply-to" set to the "allow" action and a
> continuation ID. and will have the CC: header set to "reject" with the
> continuation ID. So, by "replying" to the email
> d) by hitting "reply", the workflow will approuve the changes
> e) by hitting "reply to all", the workflow will reject them with
> no further action
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> First of all, sorry for the massive cross-post, but I think it is going
> to be a great opportunity for all the communities involved to show off
> their potentials with the apache infrastructure.
>
> The proposal is about the creation of a content management system for
> apache projects, codenamed "Doco"
+1 from me from the Forrest side.
What I really like of this proposal is the SOC, Separation of Concerns
between communities. I particularly like Forrest's rols, as it it
*exactly* what we have been doing till now.
..
> Frontend/staging will be Forrest. The idea, in order to satify
> intrastructure@ concerns is
>
> 1) forrest runs on top of the repository and generates a staged version
> of the web site (not on minotaur!)
>
> 2) a cron job on minotaur will
>
> a) download the entire site from the staging area (using rsync, wget
> or similar tools)
> b) commit it on the "site" module CVS
> c) move it on the public site folder
>
> The reason for such an "inverted" architecture is to avoid having an SSH
> access directly from the machine that runs forrestbot. This guarantees
> *COMPLETE* isolation of minotaur from the rest of the system. There is
> *NO* way for somebody to hack into any parts of doco and obtain access
> to minotaur.
>
> The reason for committing a copy on CVS is to allow infrastructure@ to
> have a fresh copy of the web site in case something happens and Doco is
> down. [they have expressed concerns about this]
+1 to this for now.
This is basically what ForrestBot does now, and the only thing needed is
to install it on Apache hardware, and separate it in two parts (minotaur
and moof).
...
> 7) install lenya, james, forrest and forrestbot on Moof.
Ok, this has TBD, where do we go from here?
> 6) write the cron scripts for minotaur
This is just after.
> I propose the creation of a new CVS module called "cocoon-doco" to host
> the scripts, installation instructions and doco-specific code.
+1
> I also propose the discussions to take place on lenya-dev, given that
> Lenya is the community focused on content management. Interested people
> are invited to join lenya-dev@cocoon.apache.org.
Ok.
Let's now move the task of installing the Forrestbot over to the
forrest-dev and infrastructure lists then. When it's working, we'll let
you know.
> [in case of community-oriented you reply to this email, please, keep all
> listed cross-posted, but in case of technical discussions, please, let's
> move it over to lenya-dev to avoid mailbombing people that don't really
> care]
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Ugo Cei <u....@cbim.it>.
Stefano Mazzocchi wrote:
> The proposal is about the creation of a content management system for
> apache projects, codenamed "Doco"
<snip/>
I haven't followed this thread at all, but I've just come upon this site
that might be interesting: http://3d17.org :
"People often talk to communities, but how do communities talk back?
3D17.org aims to answer that question by allowing a large number of
people to collaboratively create some text, be it a letter, fax, or email."
There are no details about the source code or the license, but it sure
is written in Java and runs on Jetty, as can be seen from the HTTP headers.
Ugo
Re: [proposal] Doco
Posted by Kenny Smith <ja...@journalscape.com>.
Hi Stefano,
I think the overall concept for this project is pretty cool and very
well thought out.
The one part that stands out to me as a weak link is the "reply" vs.
"reply to all" mechanism. It seems prone to human errors and to things
like vacation messages. How would conflicts be handled (one person
rejects and one approves)?
At the very least, I would provide a mechanism that allows changes to be
just as easily revoked as they were approved so that late that one night
when someone accidentally hits "reply to all" instead of "reply" that
they can easily fix it.
Kenny
> c) the email will have "reply-to" set to the "allow" action and a
> continuation ID. and will have the CC: header set to "reject" with the
> continuation ID. So, by "replying" to the email
> d) by hitting "reply", the workflow will approuve the changes
> e) by hitting "reply to all", the workflow will reject them with
> no further action
Re: [proposal] Doco
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> First of all, sorry for the massive cross-post, but I think it is going
> to be a great opportunity for all the communities involved to show off
> their potentials with the apache infrastructure.
>
> The proposal is about the creation of a content management system for
> apache projects, codenamed "Doco"
+1 from me from the Forrest side.
What I really like of this proposal is the SOC, Separation of Concerns
between communities. I particularly like Forrest's rols, as it it
*exactly* what we have been doing till now.
..
> Frontend/staging will be Forrest. The idea, in order to satify
> intrastructure@ concerns is
>
> 1) forrest runs on top of the repository and generates a staged version
> of the web site (not on minotaur!)
>
> 2) a cron job on minotaur will
>
> a) download the entire site from the staging area (using rsync, wget
> or similar tools)
> b) commit it on the "site" module CVS
> c) move it on the public site folder
>
> The reason for such an "inverted" architecture is to avoid having an SSH
> access directly from the machine that runs forrestbot. This guarantees
> *COMPLETE* isolation of minotaur from the rest of the system. There is
> *NO* way for somebody to hack into any parts of doco and obtain access
> to minotaur.
>
> The reason for committing a copy on CVS is to allow infrastructure@ to
> have a fresh copy of the web site in case something happens and Doco is
> down. [they have expressed concerns about this]
+1 to this for now.
This is basically what ForrestBot does now, and the only thing needed is
to install it on Apache hardware, and separate it in two parts (minotaur
and moof).
...
> 7) install lenya, james, forrest and forrestbot on Moof.
Ok, this has TBD, where do we go from here?
> 6) write the cron scripts for minotaur
This is just after.
> I propose the creation of a new CVS module called "cocoon-doco" to host
> the scripts, installation instructions and doco-specific code.
+1
> I also propose the discussions to take place on lenya-dev, given that
> Lenya is the community focused on content management. Interested people
> are invited to join lenya-dev@cocoon.apache.org.
Ok.
Let's now move the task of installing the Forrestbot over to the
forrest-dev and infrastructure lists then. When it's working, we'll let
you know.
> [in case of community-oriented you reply to this email, please, keep all
> listed cross-posted, but in case of technical discussions, please, let's
> move it over to lenya-dev to avoid mailbombing people that don't really
> care]
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> 2) minimal, efficient and secure workflow (should satisfy board@
> security concerns)
FWIW:
Doco came to my mind when finding
http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> 2) minimal, efficient and secure workflow (should satisfy board@
> security concerns)
FWIW:
Doco came to my mind when finding
http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [proposal] Doco
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> 2) minimal, efficient and secure workflow (should satisfy board@
> security concerns)
FWIW:
Doco came to my mind when finding
http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [proposal] Doco
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Stefano,
I like the idea of putting several existing projects together for this!
Some (detail) comments follow.
> ...The features will be:
>
> 1) super-easy editing (should satisfy wiki lovers)
and should allow offline work as is possible for code now: checkout -
edit offline - sync later
> 2) minimal, efficient and secure workflow (should satisfy board@
> security concerns)
> 3) should allow the creation of static content (should satisfy
> infrastructure@ and mirror@ concerns)
Although this is needed today, it is certainly safe to assume that ASF
sites will be able to run more dynamic stuff in the (hopefully near)
future. This might influence the design, maybe postponing more advanced
features which would require lots of sweat to implement on a static
site.
> 4) should not be a distributed product (should avoid sensations of
> forking from existing projects)
> 5) should reuse more than reinvent
> 6) should come up with structured XML content well organized in a
> repository
Sounds good.
> ... 1) everybody can edit a page and submit the changes. the pages on
> the main site will have a link that connects to the pages on the
> backend (which will be probably hosted on another machine, either
> nagoya or moof)
How do you envision the creation of new pages?
Wiki-style, adding a link to a page that does not exist yet?
Might be a detail but there is certainly some impact on the workflow
and approval process.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Michael Wechner wrote:
> In order to get myself into the "Doco" discussion I have created a Wiki
> page at (I was busy moderating emails for lenya-dev ...)
>
> http://wiki.cocoondev.org/Wiki.jsp?page=Doco
>
> where I have compiled Stefano's original proposal and added issues from
> the various email threads.
thanks for doing this.
-gregor
--
Gregor J. Rothfuss
Wyona Inc. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Michael Wechner <mi...@wyona.com>.
In order to get myself into the "Doco" discussion I have created a Wiki
page at (I was busy moderating emails for lenya-dev ...)
http://wiki.cocoondev.org/Wiki.jsp?page=Doco
where I have compiled Stefano's original proposal and added issues from
the various email threads.
Would be nice if people could compile ideas into this page in order to
find consensus.
Hope this helps to get an overview and development started.
Thanks
Michi
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Michael Wechner <mi...@wyona.com>.
In order to get myself into the "Doco" discussion I have created a Wiki
page at (I was busy moderating emails for lenya-dev ...)
http://wiki.cocoondev.org/Wiki.jsp?page=Doco
where I have compiled Stefano's original proposal and added issues from
the various email threads.
Would be nice if people could compile ideas into this page in order to
find consensus.
Hope this helps to get an overview and development started.
Thanks
Michi
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
Re: [proposal] Doco
Posted by Michael Wechner <mi...@wyona.com>.
In order to get myself into the "Doco" discussion I have created a Wiki
page at (I was busy moderating emails for lenya-dev ...)
http://wiki.cocoondev.org/Wiki.jsp?page=Doco
where I have compiled Stefano's original proposal and added issues from
the various email threads.
Would be nice if people could compile ideas into this page in order to
find consensus.
Hope this helps to get an overview and development started.
Thanks
Michi
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Michael Wechner <mi...@wyona.com>.
In order to get myself into the "Doco" discussion I have created a Wiki
page at (I was busy moderating emails for lenya-dev ...)
http://wiki.cocoondev.org/Wiki.jsp?page=Doco
where I have compiled Stefano's original proposal and added issues from
the various email threads.
Would be nice if people could compile ideas into this page in order to
find consensus.
Hope this helps to get an overview and development started.
Thanks
Michi
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 28, 2003, at 11:14 Europe/Rome, Nicola Ken Barozzi
wrote:
> Stefano Mazzocchi wrote:
>
>> On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:
>>>> nah, dude, look: doco has a very precise editing access point. You
>>>> can
>>>> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
>>>> servlet upload, sql injection, cross-site-scripting, and you next
>>>> favorite attack will NOT work because the system prevents it by
>>>> design
>>>> [not saying it cannot happen, but if it does it's a bug, not a
>>>> faulty
>>>> design]
>>>
>>> FWIW, I agree. Perhaps the submit goes to a well-formedness check
>>> (or even
>>> better?, schema/dtd validation). If it fails, it doesn't even enter
>>> the
>>> approval process.
>> Absolutely. This wasn't mentioned, but planned. I will do relaxng
>> validation before allowing any xml data into the system. This should
>> be enough for documentation.
>
> Forrest also uses other files as source formats:
> cwiki (wiki)
> ihtml (cleaned html)
> ehtml (passthrough html)
> txt (text files)
Linotype will generates XHTML only and this is what forrest will have
to process.
>>> Perhaps a notification email is sent describing that an
>>> invalid submittal was sent.
>> Nah, it would just fail and log the failure. No need to spam further
>> since it might well be a bug in the editing software ;-) [I have
>> experienced a few of them as well]
>>> The user is returned an error page saying the
>>> post was rejected, in case it was just a mistake.
>>>
>>> On another note, can images/PDFs/other-binaries be uploaded?
>> Damn, forgot about this!
>> My suggestion would be to process the binary file and determine if
>> it's an image or not.
>> If not, reject it right away. [there should be *NO* need to upload
>> any other binary file ]
>
> For uploads of binary resources, we can limit them to the ones we want
> to cater for as forrest content as images. For the other types of
> things that are to be rendered as "raw", like PDFs, tarballs,
> javadocs, etc, we will have to use the same method we use now.
No. File upload will be limited to images for now. Too risky to allow
anything else.
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 28, 2003, at 11:14 Europe/Rome, Nicola Ken Barozzi
wrote:
> Stefano Mazzocchi wrote:
>
>> On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:
>>>> nah, dude, look: doco has a very precise editing access point. You
>>>> can
>>>> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
>>>> servlet upload, sql injection, cross-site-scripting, and you next
>>>> favorite attack will NOT work because the system prevents it by
>>>> design
>>>> [not saying it cannot happen, but if it does it's a bug, not a
>>>> faulty
>>>> design]
>>>
>>> FWIW, I agree. Perhaps the submit goes to a well-formedness check
>>> (or even
>>> better?, schema/dtd validation). If it fails, it doesn't even enter
>>> the
>>> approval process.
>> Absolutely. This wasn't mentioned, but planned. I will do relaxng
>> validation before allowing any xml data into the system. This should
>> be enough for documentation.
>
> Forrest also uses other files as source formats:
> cwiki (wiki)
> ihtml (cleaned html)
> ehtml (passthrough html)
> txt (text files)
Linotype will generates XHTML only and this is what forrest will have
to process.
>>> Perhaps a notification email is sent describing that an
>>> invalid submittal was sent.
>> Nah, it would just fail and log the failure. No need to spam further
>> since it might well be a bug in the editing software ;-) [I have
>> experienced a few of them as well]
>>> The user is returned an error page saying the
>>> post was rejected, in case it was just a mistake.
>>>
>>> On another note, can images/PDFs/other-binaries be uploaded?
>> Damn, forgot about this!
>> My suggestion would be to process the binary file and determine if
>> it's an image or not.
>> If not, reject it right away. [there should be *NO* need to upload
>> any other binary file ]
>
> For uploads of binary resources, we can limit them to the ones we want
> to cater for as forrest content as images. For the other types of
> things that are to be rendered as "raw", like PDFs, tarballs,
> javadocs, etc, we will have to use the same method we use now.
No. File upload will be limited to images for now. Too risky to allow
anything else.
--
Stefano.
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 28, 2003, at 11:14 Europe/Rome, Nicola Ken Barozzi
wrote:
> Stefano Mazzocchi wrote:
>
>> On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:
>>>> nah, dude, look: doco has a very precise editing access point. You
>>>> can
>>>> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
>>>> servlet upload, sql injection, cross-site-scripting, and you next
>>>> favorite attack will NOT work because the system prevents it by
>>>> design
>>>> [not saying it cannot happen, but if it does it's a bug, not a
>>>> faulty
>>>> design]
>>>
>>> FWIW, I agree. Perhaps the submit goes to a well-formedness check
>>> (or even
>>> better?, schema/dtd validation). If it fails, it doesn't even enter
>>> the
>>> approval process.
>> Absolutely. This wasn't mentioned, but planned. I will do relaxng
>> validation before allowing any xml data into the system. This should
>> be enough for documentation.
>
> Forrest also uses other files as source formats:
> cwiki (wiki)
> ihtml (cleaned html)
> ehtml (passthrough html)
> txt (text files)
Linotype will generates XHTML only and this is what forrest will have
to process.
>>> Perhaps a notification email is sent describing that an
>>> invalid submittal was sent.
>> Nah, it would just fail and log the failure. No need to spam further
>> since it might well be a bug in the editing software ;-) [I have
>> experienced a few of them as well]
>>> The user is returned an error page saying the
>>> post was rejected, in case it was just a mistake.
>>>
>>> On another note, can images/PDFs/other-binaries be uploaded?
>> Damn, forgot about this!
>> My suggestion would be to process the binary file and determine if
>> it's an image or not.
>> If not, reject it right away. [there should be *NO* need to upload
>> any other binary file ]
>
> For uploads of binary resources, we can limit them to the ones we want
> to cater for as forrest content as images. For the other types of
> things that are to be rendered as "raw", like PDFs, tarballs,
> javadocs, etc, we will have to use the same method we use now.
No. File upload will be limited to images for now. Too risky to allow
anything else.
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 28, 2003, at 11:14 Europe/Rome, Nicola Ken Barozzi
wrote:
> Stefano Mazzocchi wrote:
>
>> On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:
>>>> nah, dude, look: doco has a very precise editing access point. You
>>>> can
>>>> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
>>>> servlet upload, sql injection, cross-site-scripting, and you next
>>>> favorite attack will NOT work because the system prevents it by
>>>> design
>>>> [not saying it cannot happen, but if it does it's a bug, not a
>>>> faulty
>>>> design]
>>>
>>> FWIW, I agree. Perhaps the submit goes to a well-formedness check
>>> (or even
>>> better?, schema/dtd validation). If it fails, it doesn't even enter
>>> the
>>> approval process.
>> Absolutely. This wasn't mentioned, but planned. I will do relaxng
>> validation before allowing any xml data into the system. This should
>> be enough for documentation.
>
> Forrest also uses other files as source formats:
> cwiki (wiki)
> ihtml (cleaned html)
> ehtml (passthrough html)
> txt (text files)
Linotype will generates XHTML only and this is what forrest will have
to process.
>>> Perhaps a notification email is sent describing that an
>>> invalid submittal was sent.
>> Nah, it would just fail and log the failure. No need to spam further
>> since it might well be a bug in the editing software ;-) [I have
>> experienced a few of them as well]
>>> The user is returned an error page saying the
>>> post was rejected, in case it was just a mistake.
>>>
>>> On another note, can images/PDFs/other-binaries be uploaded?
>> Damn, forgot about this!
>> My suggestion would be to process the binary file and determine if
>> it's an image or not.
>> If not, reject it right away. [there should be *NO* need to upload
>> any other binary file ]
>
> For uploads of binary resources, we can limit them to the ones we want
> to cater for as forrest content as images. For the other types of
> things that are to be rendered as "raw", like PDFs, tarballs,
> javadocs, etc, we will have to use the same method we use now.
No. File upload will be limited to images for now. Too risky to allow
anything else.
--
Stefano.
Re: [proposal] Doco
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
>
> On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:
>
>>> nah, dude, look: doco has a very precise editing access point. You can
>>> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
>>> servlet upload, sql injection, cross-site-scripting, and you next
>>> favorite attack will NOT work because the system prevents it by design
>>> [not saying it cannot happen, but if it does it's a bug, not a faulty
>>> design]
>>
>> FWIW, I agree. Perhaps the submit goes to a well-formedness check (or
>> even
>> better?, schema/dtd validation). If it fails, it doesn't even enter the
>> approval process.
>
> Absolutely. This wasn't mentioned, but planned. I will do relaxng
> validation before allowing any xml data into the system. This should be
> enough for documentation.
Forrest also uses other files as source formats:
cwiki (wiki)
ihtml (cleaned html)
ehtml (passthrough html)
txt (text files)
>> Perhaps a notification email is sent describing that an
>> invalid submittal was sent.
>
> Nah, it would just fail and log the failure. No need to spam further
> since it might well be a bug in the editing software ;-) [I have
> experienced a few of them as well]
>
>> The user is returned an error page saying the
>> post was rejected, in case it was just a mistake.
>>
>> On another note, can images/PDFs/other-binaries be uploaded?
>
> Damn, forgot about this!
>
> My suggestion would be to process the binary file and determine if it's
> an image or not.
>
> If not, reject it right away. [there should be *NO* need to upload any
> other binary file ]
For uploads of binary resources, we can limit them to the ones we want
to cater for as forrest content as images. For the other types of things
that are to be rendered as "raw", like PDFs, tarballs, javadocs, etc, we
will have to use the same method we use now.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [proposal] Doco
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
>
> On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:
>
>>> nah, dude, look: doco has a very precise editing access point. You can
>>> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
>>> servlet upload, sql injection, cross-site-scripting, and you next
>>> favorite attack will NOT work because the system prevents it by design
>>> [not saying it cannot happen, but if it does it's a bug, not a faulty
>>> design]
>>
>> FWIW, I agree. Perhaps the submit goes to a well-formedness check (or
>> even
>> better?, schema/dtd validation). If it fails, it doesn't even enter the
>> approval process.
>
> Absolutely. This wasn't mentioned, but planned. I will do relaxng
> validation before allowing any xml data into the system. This should be
> enough for documentation.
Forrest also uses other files as source formats:
cwiki (wiki)
ihtml (cleaned html)
ehtml (passthrough html)
txt (text files)
>> Perhaps a notification email is sent describing that an
>> invalid submittal was sent.
>
> Nah, it would just fail and log the failure. No need to spam further
> since it might well be a bug in the editing software ;-) [I have
> experienced a few of them as well]
>
>> The user is returned an error page saying the
>> post was rejected, in case it was just a mistake.
>>
>> On another note, can images/PDFs/other-binaries be uploaded?
>
> Damn, forgot about this!
>
> My suggestion would be to process the binary file and determine if it's
> an image or not.
>
> If not, reject it right away. [there should be *NO* need to upload any
> other binary file ]
For uploads of binary resources, we can limit them to the ones we want
to cater for as forrest content as images. For the other types of things
that are to be rendered as "raw", like PDFs, tarballs, javadocs, etc, we
will have to use the same method we use now.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
>
> On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:
>
>>> nah, dude, look: doco has a very precise editing access point. You can
>>> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
>>> servlet upload, sql injection, cross-site-scripting, and you next
>>> favorite attack will NOT work because the system prevents it by design
>>> [not saying it cannot happen, but if it does it's a bug, not a faulty
>>> design]
>>
>> FWIW, I agree. Perhaps the submit goes to a well-formedness check (or
>> even
>> better?, schema/dtd validation). If it fails, it doesn't even enter the
>> approval process.
>
> Absolutely. This wasn't mentioned, but planned. I will do relaxng
> validation before allowing any xml data into the system. This should be
> enough for documentation.
Forrest also uses other files as source formats:
cwiki (wiki)
ihtml (cleaned html)
ehtml (passthrough html)
txt (text files)
>> Perhaps a notification email is sent describing that an
>> invalid submittal was sent.
>
> Nah, it would just fail and log the failure. No need to spam further
> since it might well be a bug in the editing software ;-) [I have
> experienced a few of them as well]
>
>> The user is returned an error page saying the
>> post was rejected, in case it was just a mistake.
>>
>> On another note, can images/PDFs/other-binaries be uploaded?
>
> Damn, forgot about this!
>
> My suggestion would be to process the binary file and determine if it's
> an image or not.
>
> If not, reject it right away. [there should be *NO* need to upload any
> other binary file ]
For uploads of binary resources, we can limit them to the ones we want
to cater for as forrest content as images. For the other types of things
that are to be rendered as "raw", like PDFs, tarballs, javadocs, etc, we
will have to use the same method we use now.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
>
> On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:
>
>>> nah, dude, look: doco has a very precise editing access point. You can
>>> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
>>> servlet upload, sql injection, cross-site-scripting, and you next
>>> favorite attack will NOT work because the system prevents it by design
>>> [not saying it cannot happen, but if it does it's a bug, not a faulty
>>> design]
>>
>> FWIW, I agree. Perhaps the submit goes to a well-formedness check (or
>> even
>> better?, schema/dtd validation). If it fails, it doesn't even enter the
>> approval process.
>
> Absolutely. This wasn't mentioned, but planned. I will do relaxng
> validation before allowing any xml data into the system. This should be
> enough for documentation.
Forrest also uses other files as source formats:
cwiki (wiki)
ihtml (cleaned html)
ehtml (passthrough html)
txt (text files)
>> Perhaps a notification email is sent describing that an
>> invalid submittal was sent.
>
> Nah, it would just fail and log the failure. No need to spam further
> since it might well be a bug in the editing software ;-) [I have
> experienced a few of them as well]
>
>> The user is returned an error page saying the
>> post was rejected, in case it was just a mistake.
>>
>> On another note, can images/PDFs/other-binaries be uploaded?
>
> Damn, forgot about this!
>
> My suggestion would be to process the binary file and determine if it's
> an image or not.
>
> If not, reject it right away. [there should be *NO* need to upload any
> other binary file ]
For uploads of binary resources, we can limit them to the ones we want
to cater for as forrest content as images. For the other types of things
that are to be rendered as "raw", like PDFs, tarballs, javadocs, etc, we
will have to use the same method we use now.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 28, 2003, at 03:01 Europe/Rome, Dave Brondsema wrote:
> Quoting Stefano Mazzocchi <st...@apache.org>:
>
>>> On another note, can images/PDFs/other-binaries be uploaded?
>>
>> Damn, forgot about this!
>>
>> My suggestion would be to process the binary file and determine if
>> it's
>> an image or not.
>>
>> If not, reject it right away. [there should be *NO* need to upload any
>> other binary file ]
>>
>
> Why do you think so?
Security.
> I think it depends on the context of the documentation.
Sure, but in our context this is simply too dangerous.
> In our use of forrest we have diagram files, MSWord files that haven't
> been
> converted yet, existing PDFs (created outside of forrest), .tgz
> downloads and
> more.
So? Doco is not an extension of forrest, it's a *user* of forrest. If
forrest can do more, great, but I don't care.
> I don't think we should limit doco to exclude binaries.
And allow people to post word files that might contain trojans? flash
files with child pornography? how are you going to validate the content
of a binary file if you can't open it on your platform?
> Likely these
> options could be enabled and disabled by site administrators, but some
> documentation sites would like to have binaries posted.
Doco is a proposal to build *our* system for *our* documentation. It's
not a general CMS, I don't want to distribute stuff from it.
Can it be used by other people later? sure, I wouldn't mind, but for
now, all I want is a system that works for us and that infrastructure
allows us to use in production.
Everything else should not be a concern now.
--
Stefano.
Re: [proposal] Doco
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Stefano Mazzocchi <st...@apache.org>:
> > On another note, can images/PDFs/other-binaries be uploaded?
>
> Damn, forgot about this!
>
> My suggestion would be to process the binary file and determine if it's
> an image or not.
>
> If not, reject it right away. [there should be *NO* need to upload any
> other binary file ]
>
Why do you think so? I think it depends on the context of the documentation.
In our use of forrest we have diagram files, MSWord files that haven't been
converted yet, existing PDFs (created outside of forrest), .tgz downloads and
more. I don't think we should limit doco to exclude binaries. Likely these
options could be enabled and disabled by site administrators, but some
documentation sites would like to have binaries posted.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - student org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:
>> nah, dude, look: doco has a very precise editing access point. You can
>> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
>> servlet upload, sql injection, cross-site-scripting, and you next
>> favorite attack will NOT work because the system prevents it by design
>> [not saying it cannot happen, but if it does it's a bug, not a faulty
>> design]
>
> FWIW, I agree. Perhaps the submit goes to a well-formedness check (or
> even
> better?, schema/dtd validation). If it fails, it doesn't even enter the
> approval process.
Absolutely. This wasn't mentioned, but planned. I will do relaxng
validation before allowing any xml data into the system. This should be
enough for documentation.
> Perhaps a notification email is sent describing that an
> invalid submittal was sent.
Nah, it would just fail and log the failure. No need to spam further
since it might well be a bug in the editing software ;-) [I have
experienced a few of them as well]
> The user is returned an error page saying the
> post was rejected, in case it was just a mistake.
>
> On another note, can images/PDFs/other-binaries be uploaded?
Damn, forgot about this!
My suggestion would be to process the binary file and determine if it's
an image or not.
If not, reject it right away. [there should be *NO* need to upload any
other binary file ]
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:
>> nah, dude, look: doco has a very precise editing access point. You can
>> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
>> servlet upload, sql injection, cross-site-scripting, and you next
>> favorite attack will NOT work because the system prevents it by design
>> [not saying it cannot happen, but if it does it's a bug, not a faulty
>> design]
>
> FWIW, I agree. Perhaps the submit goes to a well-formedness check (or
> even
> better?, schema/dtd validation). If it fails, it doesn't even enter the
> approval process.
Absolutely. This wasn't mentioned, but planned. I will do relaxng
validation before allowing any xml data into the system. This should be
enough for documentation.
> Perhaps a notification email is sent describing that an
> invalid submittal was sent.
Nah, it would just fail and log the failure. No need to spam further
since it might well be a bug in the editing software ;-) [I have
experienced a few of them as well]
> The user is returned an error page saying the
> post was rejected, in case it was just a mistake.
>
> On another note, can images/PDFs/other-binaries be uploaded?
Damn, forgot about this!
My suggestion would be to process the binary file and determine if it's
an image or not.
If not, reject it right away. [there should be *NO* need to upload any
other binary file ]
--
Stefano.
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:
>> nah, dude, look: doco has a very precise editing access point. You can
>> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
>> servlet upload, sql injection, cross-site-scripting, and you next
>> favorite attack will NOT work because the system prevents it by design
>> [not saying it cannot happen, but if it does it's a bug, not a faulty
>> design]
>
> FWIW, I agree. Perhaps the submit goes to a well-formedness check (or
> even
> better?, schema/dtd validation). If it fails, it doesn't even enter the
> approval process.
Absolutely. This wasn't mentioned, but planned. I will do relaxng
validation before allowing any xml data into the system. This should be
enough for documentation.
> Perhaps a notification email is sent describing that an
> invalid submittal was sent.
Nah, it would just fail and log the failure. No need to spam further
since it might well be a bug in the editing software ;-) [I have
experienced a few of them as well]
> The user is returned an error page saying the
> post was rejected, in case it was just a mistake.
>
> On another note, can images/PDFs/other-binaries be uploaded?
Damn, forgot about this!
My suggestion would be to process the binary file and determine if it's
an image or not.
If not, reject it right away. [there should be *NO* need to upload any
other binary file ]
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:
>> nah, dude, look: doco has a very precise editing access point. You can
>> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
>> servlet upload, sql injection, cross-site-scripting, and you next
>> favorite attack will NOT work because the system prevents it by design
>> [not saying it cannot happen, but if it does it's a bug, not a faulty
>> design]
>
> FWIW, I agree. Perhaps the submit goes to a well-formedness check (or
> even
> better?, schema/dtd validation). If it fails, it doesn't even enter the
> approval process.
Absolutely. This wasn't mentioned, but planned. I will do relaxng
validation before allowing any xml data into the system. This should be
enough for documentation.
> Perhaps a notification email is sent describing that an
> invalid submittal was sent.
Nah, it would just fail and log the failure. No need to spam further
since it might well be a bug in the editing software ;-) [I have
experienced a few of them as well]
> The user is returned an error page saying the
> post was rejected, in case it was just a mistake.
>
> On another note, can images/PDFs/other-binaries be uploaded?
Damn, forgot about this!
My suggestion would be to process the binary file and determine if it's
an image or not.
If not, reject it right away. [there should be *NO* need to upload any
other binary file ]
--
Stefano.
RE: [proposal] Doco
Posted by Robert Koberg <ro...@koberg.com>.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Monday, October 27, 2003 6:06 AM
> To: James Developers List
> Cc: dev@cocoon.apache.org; forrest-dev@xml.apache.org; lenya-
> dev@cocoon.apache.org
>
>
> On Sunday, Oct 26, 2003, at 23:33 Europe/Rome, Noel J. Bergman wrote:
>
> >> He's not questioning whether it's encrypted. His point is, doco sends
> >> an email to an address, and you respond. It gives very little
> >> control,
> >> even if there is a compromise.
> >
> > AIUI, the proposed solution would allow "anyone" to edit content, and
> > contribute it as a "patch". Content could include defacements,
> > changes to
> > .htaccess, and CGI scripts.
>
> nah, dude, look: doco has a very precise editing access point. You can
> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
> servlet upload, sql injection, cross-site-scripting, and you next
> favorite attack will NOT work because the system prevents it by design
> [not saying it cannot happen, but if it does it's a bug, not a faulty
> design]
FWIW, I agree. Perhaps the submit goes to a well-formedness check (or even
better?, schema/dtd validation). If it fails, it doesn't even enter the
approval process. Perhaps a notification email is sent describing that an
invalid submittal was sent. The user is returned an error page saying the
post was rejected, in case it was just a mistake.
On another note, can images/PDFs/other-binaries be uploaded?
-Rob
Re: [proposal] Doco
Posted by Kenny Smith <ja...@journalscape.com>.
Hi Serge,
I'm not familiar with what mozilla/thunderbird exactly is , but I use
mozilla's stadard mail client and it allows multiple outgoing servers. I
can create several outgoing servers and configure each of my incoming
accounts to send outgoing mail through any one of them. I can't set it
up so that 1 incoming account can choose between 2 outgoing on the fly
or anything, but in the configuration I can define x number of mail
servers and set my incoming accounts to use whichever.
Kenny
Serge Knystautas wrote:
> Out of curiosity, what mail client do you use that allows you to setup
> multiple outgoing servers like this? I use mozilla/thunderbird, and it
> can handle multiple incoming accounts, but all use the same outgoing
> SMTP server.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Joerg Heinicke <jh...@virbus.de>.
On 29.10.2003 00:00, Noel J. Bergman wrote:
>>what mail client do you use that allows you to setup
>>multiple outgoing servers like this?
>
>
> Outlook. I have a dozen different accounts, with different servers and/or
> identities (@apache, @devtech, @other-organizations). My brother uses
> Mozilla, and it supports similar AFAIK.
Yes, it does:
Edit > Mail & Newsgroups Account Settings > Outgoing Server (SMTP) >
Advanced
Joerg
Re: [proposal] Doco
Posted by Joerg Heinicke <jh...@virbus.de>.
On 29.10.2003 00:00, Noel J. Bergman wrote:
>>what mail client do you use that allows you to setup
>>multiple outgoing servers like this?
>
>
> Outlook. I have a dozen different accounts, with different servers and/or
> identities (@apache, @devtech, @other-organizations). My brother uses
> Mozilla, and it supports similar AFAIK.
Yes, it does:
Edit > Mail & Newsgroups Account Settings > Outgoing Server (SMTP) >
Advanced
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Joerg Heinicke <jh...@virbus.de>.
On 29.10.2003 00:00, Noel J. Bergman wrote:
>>what mail client do you use that allows you to setup
>>multiple outgoing servers like this?
>
>
> Outlook. I have a dozen different accounts, with different servers and/or
> identities (@apache, @devtech, @other-organizations). My brother uses
> Mozilla, and it supports similar AFAIK.
Yes, it does:
Edit > Mail & Newsgroups Account Settings > Outgoing Server (SMTP) >
Advanced
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [proposal] Doco
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Both Outlook and Outlook Express do support it.
Vincenzo
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: mercoledi 29 ottobre 2003 0.01
> To: James Developers List
> Cc: dev@cocoon.apache.org; forrest-dev@xml.apache.org;
> lenya-dev@cocoon.apache.org
> Subject: RE: [proposal] Doco
>
>
> > what mail client do you use that allows you to setup
> > multiple outgoing servers like this?
>
> Outlook. I have a dozen different accounts, with different servers and/or
> identities (@apache, @devtech, @other-organizations). My brother uses
> Mozilla, and it supports similar AFAIK.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [proposal] Doco
Posted by "Noel J. Bergman" <no...@devtech.com>.
> what mail client do you use that allows you to setup
> multiple outgoing servers like this?
Outlook. I have a dozen different accounts, with different servers and/or
identities (@apache, @devtech, @other-organizations). My brother uses
Mozilla, and it supports similar AFAIK.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [proposal] Doco
Posted by "Noel J. Bergman" <no...@devtech.com>.
> what mail client do you use that allows you to setup
> multiple outgoing servers like this?
Outlook. I have a dozen different accounts, with different servers and/or
identities (@apache, @devtech, @other-organizations). My brother uses
Mozilla, and it supports similar AFAIK.
--- Noel
RE: [proposal] Doco
Posted by "Noel J. Bergman" <no...@devtech.com>.
> what mail client do you use that allows you to setup
> multiple outgoing servers like this?
Outlook. I have a dozen different accounts, with different servers and/or
identities (@apache, @devtech, @other-organizations). My brother uses
Mozilla, and it supports similar AFAIK.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>I do agree it would help reducing the risk, but would all moderator's
>>SMTP server support that?
>
> Ah :-) I was expecting that the moderator would connect *directly* to
> moof, in which case only their MUA would have to support SMTP AUTH and SSL.
Out of curiosity, what mail client do you use that allows you to setup
multiple outgoing servers like this? I use mozilla/thunderbird, and it
can handle multiple incoming accounts, but all use the same outgoing
SMTP server.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>I do agree it would help reducing the risk, but would all moderator's
>>SMTP server support that?
>
> Ah :-) I was expecting that the moderator would connect *directly* to
> moof, in which case only their MUA would have to support SMTP AUTH and SSL.
Out of curiosity, what mail client do you use that allows you to setup
multiple outgoing servers like this? I use mozilla/thunderbird, and it
can handle multiple incoming accounts, but all use the same outgoing
SMTP server.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
Re: [proposal] Doco
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>I do agree it would help reducing the risk, but would all moderator's
>>SMTP server support that?
>
> Ah :-) I was expecting that the moderator would connect *directly* to
> moof, in which case only their MUA would have to support SMTP AUTH and SSL.
Out of curiosity, what mail client do you use that allows you to setup
multiple outgoing servers like this? I use mozilla/thunderbird, and it
can handle multiple incoming accounts, but all use the same outgoing
SMTP server.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [proposal] Doco
Posted by "Noel J. Bergman" <no...@devtech.com>.
> doco has a very precise editing access point. You can
> *ONLY* modify xml content.
> The unique and only security concern here is defacement.
OK. So not the full site content, just the XML content and images? So then
the exposure is "only" defacement, page hijacking through a REFRESH
meta-tag, scripting exploits, etc.
> I really appreciate your concerns and, please, keep in mind that I read
> and send my email via SSH tunnels
Same here. :-)
> I think you proposed to use SMTP over SSL for mail relay, that would
> reduce the ability of somebody to prevent sniffing the continuation-ID
> and provide that attack.
STMP AUTH over SSL. Moderators would have a password, and SSL would protect
it.
> I do agree it would help reducing the risk, but would all moderator's
> SMTP server support that?
Ah :-) I was expecting that the moderator would connect *directly* to
moof, in which case only their MUA would have to support SMTP AUTH and SSL.
> Another solution is to force moderators to digitally sign their email,
> but this would require a much more intrusive setup.
I wasn't suggesting such, no.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
RE: [proposal] Doco
Posted by "Noel J. Bergman" <no...@devtech.com>.
> doco has a very precise editing access point. You can
> *ONLY* modify xml content.
> The unique and only security concern here is defacement.
OK. So not the full site content, just the XML content and images? So then
the exposure is "only" defacement, page hijacking through a REFRESH
meta-tag, scripting exploits, etc.
> I really appreciate your concerns and, please, keep in mind that I read
> and send my email via SSH tunnels
Same here. :-)
> I think you proposed to use SMTP over SSL for mail relay, that would
> reduce the ability of somebody to prevent sniffing the continuation-ID
> and provide that attack.
STMP AUTH over SSL. Moderators would have a password, and SSL would protect
it.
> I do agree it would help reducing the risk, but would all moderator's
> SMTP server support that?
Ah :-) I was expecting that the moderator would connect *directly* to
moof, in which case only their MUA would have to support SMTP AUTH and SSL.
> Another solution is to force moderators to digitally sign their email,
> but this would require a much more intrusive setup.
I wasn't suggesting such, no.
--- Noel
RE: [proposal] Doco
Posted by "Noel J. Bergman" <no...@devtech.com>.
> doco has a very precise editing access point. You can
> *ONLY* modify xml content.
> The unique and only security concern here is defacement.
OK. So not the full site content, just the XML content and images? So then
the exposure is "only" defacement, page hijacking through a REFRESH
meta-tag, scripting exploits, etc.
> I really appreciate your concerns and, please, keep in mind that I read
> and send my email via SSH tunnels
Same here. :-)
> I think you proposed to use SMTP over SSL for mail relay, that would
> reduce the ability of somebody to prevent sniffing the continuation-ID
> and provide that attack.
STMP AUTH over SSL. Moderators would have a password, and SSL would protect
it.
> I do agree it would help reducing the risk, but would all moderator's
> SMTP server support that?
Ah :-) I was expecting that the moderator would connect *directly* to
moof, in which case only their MUA would have to support SMTP AUTH and SSL.
> Another solution is to force moderators to digitally sign their email,
> but this would require a much more intrusive setup.
I wasn't suggesting such, no.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [proposal] Doco
Posted by Robert Koberg <ro...@koberg.com>.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Monday, October 27, 2003 6:06 AM
> To: James Developers List
> Cc: dev@cocoon.apache.org; forrest-dev@xml.apache.org; lenya-
> dev@cocoon.apache.org
>
>
> On Sunday, Oct 26, 2003, at 23:33 Europe/Rome, Noel J. Bergman wrote:
>
> >> He's not questioning whether it's encrypted. His point is, doco sends
> >> an email to an address, and you respond. It gives very little
> >> control,
> >> even if there is a compromise.
> >
> > AIUI, the proposed solution would allow "anyone" to edit content, and
> > contribute it as a "patch". Content could include defacements,
> > changes to
> > .htaccess, and CGI scripts.
>
> nah, dude, look: doco has a very precise editing access point. You can
> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
> servlet upload, sql injection, cross-site-scripting, and you next
> favorite attack will NOT work because the system prevents it by design
> [not saying it cannot happen, but if it does it's a bug, not a faulty
> design]
FWIW, I agree. Perhaps the submit goes to a well-formedness check (or even
better?, schema/dtd validation). If it fails, it doesn't even enter the
approval process. Perhaps a notification email is sent describing that an
invalid submittal was sent. The user is returned an error page saying the
post was rejected, in case it was just a mistake.
On another note, can images/PDFs/other-binaries be uploaded?
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [proposal] Doco
Posted by Robert Koberg <ro...@koberg.com>.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Monday, October 27, 2003 6:06 AM
> To: James Developers List
> Cc: dev@cocoon.apache.org; forrest-dev@xml.apache.org; lenya-
> dev@cocoon.apache.org
>
>
> On Sunday, Oct 26, 2003, at 23:33 Europe/Rome, Noel J. Bergman wrote:
>
> >> He's not questioning whether it's encrypted. His point is, doco sends
> >> an email to an address, and you respond. It gives very little
> >> control,
> >> even if there is a compromise.
> >
> > AIUI, the proposed solution would allow "anyone" to edit content, and
> > contribute it as a "patch". Content could include defacements,
> > changes to
> > .htaccess, and CGI scripts.
>
> nah, dude, look: doco has a very precise editing access point. You can
> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
> servlet upload, sql injection, cross-site-scripting, and you next
> favorite attack will NOT work because the system prevents it by design
> [not saying it cannot happen, but if it does it's a bug, not a faulty
> design]
FWIW, I agree. Perhaps the submit goes to a well-formedness check (or even
better?, schema/dtd validation). If it fails, it doesn't even enter the
approval process. Perhaps a notification email is sent describing that an
invalid submittal was sent. The user is returned an error page saying the
post was rejected, in case it was just a mistake.
On another note, can images/PDFs/other-binaries be uploaded?
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
RE: [proposal] Doco
Posted by Robert Koberg <ro...@koberg.com>.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Monday, October 27, 2003 6:06 AM
> To: James Developers List
> Cc: dev@cocoon.apache.org; forrest-dev@xml.apache.org; lenya-
> dev@cocoon.apache.org
>
>
> On Sunday, Oct 26, 2003, at 23:33 Europe/Rome, Noel J. Bergman wrote:
>
> >> He's not questioning whether it's encrypted. His point is, doco sends
> >> an email to an address, and you respond. It gives very little
> >> control,
> >> even if there is a compromise.
> >
> > AIUI, the proposed solution would allow "anyone" to edit content, and
> > contribute it as a "patch". Content could include defacements,
> > changes to
> > .htaccess, and CGI scripts.
>
> nah, dude, look: doco has a very precise editing access point. You can
> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
> servlet upload, sql injection, cross-site-scripting, and you next
> favorite attack will NOT work because the system prevents it by design
> [not saying it cannot happen, but if it does it's a bug, not a faulty
> design]
FWIW, I agree. Perhaps the submit goes to a well-formedness check (or even
better?, schema/dtd validation). If it fails, it doesn't even enter the
approval process. Perhaps a notification email is sent describing that an
invalid submittal was sent. The user is returned an error page saying the
post was rejected, in case it was just a mistake.
On another note, can images/PDFs/other-binaries be uploaded?
-Rob
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Oct 26, 2003, at 23:33 Europe/Rome, Noel J. Bergman wrote:
>> He's not questioning whether it's encrypted. His point is, doco sends
>> an email to an address, and you respond. It gives very little
>> control,
>> even if there is a compromise.
>
> AIUI, the proposed solution would allow "anyone" to edit content, and
> contribute it as a "patch". Content could include defacements,
> changes to
> .htaccess, and CGI scripts.
nah, dude, look: doco has a very precise editing access point. You can
*ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
servlet upload, sql injection, cross-site-scripting, and you next
favorite attack will NOT work because the system prevents it by design
[not saying it cannot happen, but if it does it's a bug, not a faulty
design]
> So long as we can maintain oversight, this is
> OK. But if someone can spoof the oversight, then I would be concerned.
I would *NEVER* propose a system where the users can inject an
.htaccess file, even thru approuval. One single oversight mistake and
infrastructure@ shuts us down in half a second (if they ever allow the
system to run, and I personally wouldn't).
The unique and only security concern here is defacement.
> I am not trying to shoot this idea down. I think it is a good thing
> to do,
> and will really help.
I really appreciate your concerns and, please, keep in mind that I read
and send my email via SSH tunnels, so I *KNOW* what goes on my tcp/ip
stack [also, IMAP over compressed SSH is orders of magnitude faster
when you sit in italy and your imap server is in london! ;-)]
Anyway, here is a potential attack:
Doco sends email to james (localhost).
James multiplexes the email to the moderators (vanilla SMTP)
the attacker sniffs the continuation-ID
replies with the sniffed continuation-ID
James calls Doco and restarts the workflow
Doco sends back email logging the approuval
Potential sniffing places are:
1) right after the doco box (FYI, moof is located at Apple, nagoya at
Sun)
2) right before the mail server of the moderator or by people who have
enough priviledges on the moderator mail server.
The above attack is plausible and it would allow the attacker to get
stuff in the repository, but *NOT* to prevent other moderators to see
that this content has been approuved. [that would require substantial
forging of the output stream... possible as well, but much harder to
achieve]
The other moderators would see it as a mistake and get there fixing it
before the next site update.
Keep in mind that there are *two* 12 hour stages, so, even if the
attacker attacks right before the first staging (the forrestbot
execution), the moderators have 12 hours to understand that something
was wrong and login to fix things before the other stage (rsync from
minotaur) takes place.
I think you proposed to use SMTP over SSL for mail relay, that would
reduce the ability of somebody to prevent sniffing the continuation-ID
and provide that attack.
I do agree it would help reducing the risk, but would all moderator's
SMTP server support that? [keep in mind that a sniffer could understand
the list of moderators just by watching email outgoing traffic, even if
encrypted, by comparing with the list of users on the mail lists]
Another solution is to force moderators to digitally sign their email,
but this would require a much more intrusive setup.
At the end, I don't think anybody would do such an attack since:
1) it can't be proved that it was an attack (we can always say it was
a mistake of the moderators), so you can't go around feeling proud of
it or impressing friends of the cracker scene [ego is probably 99% of
the reasons to deface a web site]
2) the attacker cannot stop others from keeping oversight on what was
approuved (doco will send email *after* the moderation to keep
oversight of everthing that happened)
3) if we use the lazy consensus moderation method (require 3 accept
and no reject), the attack is just as easy, but the chance that the
moderator that the attacker would *fake* is offline for 24 hours and
cannot yell "WTF, I didn't do it" at the moderator list is much less
So, adding SSL relay wouldn't hurt, but wouldn't help much either since
we can't force moderators to have a mail server that accepts that kind
of relay (don't even know if mine does!)
at least, this is MHO.
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Oct 26, 2003, at 23:33 Europe/Rome, Noel J. Bergman wrote:
>> He's not questioning whether it's encrypted. His point is, doco sends
>> an email to an address, and you respond. It gives very little
>> control,
>> even if there is a compromise.
>
> AIUI, the proposed solution would allow "anyone" to edit content, and
> contribute it as a "patch". Content could include defacements,
> changes to
> .htaccess, and CGI scripts.
nah, dude, look: doco has a very precise editing access point. You can
*ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
servlet upload, sql injection, cross-site-scripting, and you next
favorite attack will NOT work because the system prevents it by design
[not saying it cannot happen, but if it does it's a bug, not a faulty
design]
> So long as we can maintain oversight, this is
> OK. But if someone can spoof the oversight, then I would be concerned.
I would *NEVER* propose a system where the users can inject an
.htaccess file, even thru approuval. One single oversight mistake and
infrastructure@ shuts us down in half a second (if they ever allow the
system to run, and I personally wouldn't).
The unique and only security concern here is defacement.
> I am not trying to shoot this idea down. I think it is a good thing
> to do,
> and will really help.
I really appreciate your concerns and, please, keep in mind that I read
and send my email via SSH tunnels, so I *KNOW* what goes on my tcp/ip
stack [also, IMAP over compressed SSH is orders of magnitude faster
when you sit in italy and your imap server is in london! ;-)]
Anyway, here is a potential attack:
Doco sends email to james (localhost).
James multiplexes the email to the moderators (vanilla SMTP)
the attacker sniffs the continuation-ID
replies with the sniffed continuation-ID
James calls Doco and restarts the workflow
Doco sends back email logging the approuval
Potential sniffing places are:
1) right after the doco box (FYI, moof is located at Apple, nagoya at
Sun)
2) right before the mail server of the moderator or by people who have
enough priviledges on the moderator mail server.
The above attack is plausible and it would allow the attacker to get
stuff in the repository, but *NOT* to prevent other moderators to see
that this content has been approuved. [that would require substantial
forging of the output stream... possible as well, but much harder to
achieve]
The other moderators would see it as a mistake and get there fixing it
before the next site update.
Keep in mind that there are *two* 12 hour stages, so, even if the
attacker attacks right before the first staging (the forrestbot
execution), the moderators have 12 hours to understand that something
was wrong and login to fix things before the other stage (rsync from
minotaur) takes place.
I think you proposed to use SMTP over SSL for mail relay, that would
reduce the ability of somebody to prevent sniffing the continuation-ID
and provide that attack.
I do agree it would help reducing the risk, but would all moderator's
SMTP server support that? [keep in mind that a sniffer could understand
the list of moderators just by watching email outgoing traffic, even if
encrypted, by comparing with the list of users on the mail lists]
Another solution is to force moderators to digitally sign their email,
but this would require a much more intrusive setup.
At the end, I don't think anybody would do such an attack since:
1) it can't be proved that it was an attack (we can always say it was
a mistake of the moderators), so you can't go around feeling proud of
it or impressing friends of the cracker scene [ego is probably 99% of
the reasons to deface a web site]
2) the attacker cannot stop others from keeping oversight on what was
approuved (doco will send email *after* the moderation to keep
oversight of everthing that happened)
3) if we use the lazy consensus moderation method (require 3 accept
and no reject), the attack is just as easy, but the chance that the
moderator that the attacker would *fake* is offline for 24 hours and
cannot yell "WTF, I didn't do it" at the moderator list is much less
So, adding SSL relay wouldn't hurt, but wouldn't help much either since
we can't force moderators to have a mail server that accepts that kind
of relay (don't even know if mine does!)
at least, this is MHO.
--
Stefano.
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Oct 26, 2003, at 23:33 Europe/Rome, Noel J. Bergman wrote:
>> He's not questioning whether it's encrypted. His point is, doco sends
>> an email to an address, and you respond. It gives very little
>> control,
>> even if there is a compromise.
>
> AIUI, the proposed solution would allow "anyone" to edit content, and
> contribute it as a "patch". Content could include defacements,
> changes to
> .htaccess, and CGI scripts.
nah, dude, look: doco has a very precise editing access point. You can
*ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
servlet upload, sql injection, cross-site-scripting, and you next
favorite attack will NOT work because the system prevents it by design
[not saying it cannot happen, but if it does it's a bug, not a faulty
design]
> So long as we can maintain oversight, this is
> OK. But if someone can spoof the oversight, then I would be concerned.
I would *NEVER* propose a system where the users can inject an
.htaccess file, even thru approuval. One single oversight mistake and
infrastructure@ shuts us down in half a second (if they ever allow the
system to run, and I personally wouldn't).
The unique and only security concern here is defacement.
> I am not trying to shoot this idea down. I think it is a good thing
> to do,
> and will really help.
I really appreciate your concerns and, please, keep in mind that I read
and send my email via SSH tunnels, so I *KNOW* what goes on my tcp/ip
stack [also, IMAP over compressed SSH is orders of magnitude faster
when you sit in italy and your imap server is in london! ;-)]
Anyway, here is a potential attack:
Doco sends email to james (localhost).
James multiplexes the email to the moderators (vanilla SMTP)
the attacker sniffs the continuation-ID
replies with the sniffed continuation-ID
James calls Doco and restarts the workflow
Doco sends back email logging the approuval
Potential sniffing places are:
1) right after the doco box (FYI, moof is located at Apple, nagoya at
Sun)
2) right before the mail server of the moderator or by people who have
enough priviledges on the moderator mail server.
The above attack is plausible and it would allow the attacker to get
stuff in the repository, but *NOT* to prevent other moderators to see
that this content has been approuved. [that would require substantial
forging of the output stream... possible as well, but much harder to
achieve]
The other moderators would see it as a mistake and get there fixing it
before the next site update.
Keep in mind that there are *two* 12 hour stages, so, even if the
attacker attacks right before the first staging (the forrestbot
execution), the moderators have 12 hours to understand that something
was wrong and login to fix things before the other stage (rsync from
minotaur) takes place.
I think you proposed to use SMTP over SSL for mail relay, that would
reduce the ability of somebody to prevent sniffing the continuation-ID
and provide that attack.
I do agree it would help reducing the risk, but would all moderator's
SMTP server support that? [keep in mind that a sniffer could understand
the list of moderators just by watching email outgoing traffic, even if
encrypted, by comparing with the list of users on the mail lists]
Another solution is to force moderators to digitally sign their email,
but this would require a much more intrusive setup.
At the end, I don't think anybody would do such an attack since:
1) it can't be proved that it was an attack (we can always say it was
a mistake of the moderators), so you can't go around feeling proud of
it or impressing friends of the cracker scene [ego is probably 99% of
the reasons to deface a web site]
2) the attacker cannot stop others from keeping oversight on what was
approuved (doco will send email *after* the moderation to keep
oversight of everthing that happened)
3) if we use the lazy consensus moderation method (require 3 accept
and no reject), the attack is just as easy, but the chance that the
moderator that the attacker would *fake* is offline for 24 hours and
cannot yell "WTF, I didn't do it" at the moderator list is much less
So, adding SSL relay wouldn't hurt, but wouldn't help much either since
we can't force moderators to have a mail server that accepts that kind
of relay (don't even know if mine does!)
at least, this is MHO.
--
Stefano.
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Oct 26, 2003, at 23:33 Europe/Rome, Noel J. Bergman wrote:
>> He's not questioning whether it's encrypted. His point is, doco sends
>> an email to an address, and you respond. It gives very little
>> control,
>> even if there is a compromise.
>
> AIUI, the proposed solution would allow "anyone" to edit content, and
> contribute it as a "patch". Content could include defacements,
> changes to
> .htaccess, and CGI scripts.
nah, dude, look: doco has a very precise editing access point. You can
*ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
servlet upload, sql injection, cross-site-scripting, and you next
favorite attack will NOT work because the system prevents it by design
[not saying it cannot happen, but if it does it's a bug, not a faulty
design]
> So long as we can maintain oversight, this is
> OK. But if someone can spoof the oversight, then I would be concerned.
I would *NEVER* propose a system where the users can inject an
.htaccess file, even thru approuval. One single oversight mistake and
infrastructure@ shuts us down in half a second (if they ever allow the
system to run, and I personally wouldn't).
The unique and only security concern here is defacement.
> I am not trying to shoot this idea down. I think it is a good thing
> to do,
> and will really help.
I really appreciate your concerns and, please, keep in mind that I read
and send my email via SSH tunnels, so I *KNOW* what goes on my tcp/ip
stack [also, IMAP over compressed SSH is orders of magnitude faster
when you sit in italy and your imap server is in london! ;-)]
Anyway, here is a potential attack:
Doco sends email to james (localhost).
James multiplexes the email to the moderators (vanilla SMTP)
the attacker sniffs the continuation-ID
replies with the sniffed continuation-ID
James calls Doco and restarts the workflow
Doco sends back email logging the approuval
Potential sniffing places are:
1) right after the doco box (FYI, moof is located at Apple, nagoya at
Sun)
2) right before the mail server of the moderator or by people who have
enough priviledges on the moderator mail server.
The above attack is plausible and it would allow the attacker to get
stuff in the repository, but *NOT* to prevent other moderators to see
that this content has been approuved. [that would require substantial
forging of the output stream... possible as well, but much harder to
achieve]
The other moderators would see it as a mistake and get there fixing it
before the next site update.
Keep in mind that there are *two* 12 hour stages, so, even if the
attacker attacks right before the first staging (the forrestbot
execution), the moderators have 12 hours to understand that something
was wrong and login to fix things before the other stage (rsync from
minotaur) takes place.
I think you proposed to use SMTP over SSL for mail relay, that would
reduce the ability of somebody to prevent sniffing the continuation-ID
and provide that attack.
I do agree it would help reducing the risk, but would all moderator's
SMTP server support that? [keep in mind that a sniffer could understand
the list of moderators just by watching email outgoing traffic, even if
encrypted, by comparing with the list of users on the mail lists]
Another solution is to force moderators to digitally sign their email,
but this would require a much more intrusive setup.
At the end, I don't think anybody would do such an attack since:
1) it can't be proved that it was an attack (we can always say it was
a mistake of the moderators), so you can't go around feeling proud of
it or impressing friends of the cracker scene [ego is probably 99% of
the reasons to deface a web site]
2) the attacker cannot stop others from keeping oversight on what was
approuved (doco will send email *after* the moderation to keep
oversight of everthing that happened)
3) if we use the lazy consensus moderation method (require 3 accept
and no reject), the attack is just as easy, but the chance that the
moderator that the attacker would *fake* is offline for 24 hours and
cannot yell "WTF, I didn't do it" at the moderator list is much less
So, adding SSL relay wouldn't hurt, but wouldn't help much either since
we can't force moderators to have a mail server that accepts that kind
of relay (don't even know if mine does!)
at least, this is MHO.
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [proposal] Doco
Posted by "Noel J. Bergman" <no...@devtech.com>.
> He's not questioning whether it's encrypted. His point is, doco sends
> an email to an address, and you respond. It gives very little control,
> even if there is a compromise.
AIUI, the proposed solution would allow "anyone" to edit content, and
contribute it as a "patch". Content could include defacements, changes to
.htaccess, and CGI scripts. So long as we can maintain oversight, this is
OK. But if someone can spoof the oversight, then I would be concerned.
I am not trying to shoot this idea down. I think it is a good thing to do,
and will really help.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
RE: [proposal] Doco
Posted by "Noel J. Bergman" <no...@devtech.com>.
> He's not questioning whether it's encrypted. His point is, doco sends
> an email to an address, and you respond. It gives very little control,
> even if there is a compromise.
AIUI, the proposed solution would allow "anyone" to edit content, and
contribute it as a "patch". Content could include defacements, changes to
.htaccess, and CGI scripts. So long as we can maintain oversight, this is
OK. But if someone can spoof the oversight, then I would be concerned.
I am not trying to shoot this idea down. I think it is a good thing to do,
and will really help.
--- Noel
RE: [proposal] Doco
Posted by "Noel J. Bergman" <no...@devtech.com>.
> He's not questioning whether it's encrypted. His point is, doco sends
> an email to an address, and you respond. It gives very little control,
> even if there is a compromise.
AIUI, the proposed solution would allow "anyone" to edit content, and
contribute it as a "patch". Content could include defacements, changes to
.htaccess, and CGI scripts. So long as we can maintain oversight, this is
OK. But if someone can spoof the oversight, then I would be concerned.
I am not trying to shoot this idea down. I think it is a good thing to do,
and will really help.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>don't know, maybe I'm missing something, but what do you think a
>>possible attack could be?
>
> I don't consider any traffic across the Internet to be secure unless
> encrypted. Why do you use SSH instead of telnet if packets are secure?
He's not questioning whether it's encrypted. His point is, doco sends
an email to an address, and you respond. It gives very little control,
even if there is a compromise. SSH/telnet is an entirely different (and
much larger) set of possible attacks.
--
Serge Knystautas
President
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>don't know, maybe I'm missing something, but what do you think a
>>possible attack could be?
>
> I don't consider any traffic across the Internet to be secure unless
> encrypted. Why do you use SSH instead of telnet if packets are secure?
He's not questioning whether it's encrypted. His point is, doco sends
an email to an address, and you respond. It gives very little control,
even if there is a compromise. SSH/telnet is an entirely different (and
much larger) set of possible attacks.
--
Serge Knystautas
President
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
Re: [proposal] Doco
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>don't know, maybe I'm missing something, but what do you think a
>>possible attack could be?
>
> I don't consider any traffic across the Internet to be secure unless
> encrypted. Why do you use SSH instead of telnet if packets are secure?
He's not questioning whether it's encrypted. His point is, doco sends
an email to an address, and you respond. It gives very little control,
even if there is a compromise. SSH/telnet is an entirely different (and
much larger) set of possible attacks.
--
Serge Knystautas
President
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [proposal] Doco
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > The proposed workflow institutionalizes RTC,
> RTC?
Review Then Commit. As opposed to Commit Then Review. I think there are
other variations on the phrase floating around.
> > Perhaps we could require SMTP AUTH over SSL for the
> > moderators?
> Hmmm, I don't really see how this would help. The information to secure
> is the continuation ID which is passed along with the email. If you are
> not part of the moderation list, you don't get that email.
> don't know, maybe I'm missing something, but what do you think a
> possible attack could be?
I don't consider any traffic across the Internet to be secure unless
encrypted. Why do you use SSH instead of telnet if packets are secure?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
RE: [proposal] Doco
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > The proposed workflow institutionalizes RTC,
> RTC?
Review Then Commit. As opposed to Commit Then Review. I think there are
other variations on the phrase floating around.
> > Perhaps we could require SMTP AUTH over SSL for the
> > moderators?
> Hmmm, I don't really see how this would help. The information to secure
> is the continuation ID which is passed along with the email. If you are
> not part of the moderation list, you don't get that email.
> don't know, maybe I'm missing something, but what do you think a
> possible attack could be?
I don't consider any traffic across the Internet to be secure unless
encrypted. Why do you use SSH instead of telnet if packets are secure?
--- Noel
RE: [proposal] Doco
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > The proposed workflow institutionalizes RTC,
> RTC?
Review Then Commit. As opposed to Commit Then Review. I think there are
other variations on the phrase floating around.
> > Perhaps we could require SMTP AUTH over SSL for the
> > moderators?
> Hmmm, I don't really see how this would help. The information to secure
> is the continuation ID which is passed along with the email. If you are
> not part of the moderation list, you don't get that email.
> don't know, maybe I'm missing something, but what do you think a
> possible attack could be?
I don't consider any traffic across the Internet to be secure unless
encrypted. Why do you use SSH instead of telnet if packets are secure?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Saturday, Oct 25, 2003, at 00:39 Europe/Rome, Noel J. Bergman wrote:
> Stefano,
>
> +1
>
> Looks like a good plan that takes the ForrestBot idea, builds on it,
> integrates other things, seems secure and scalable, provides the
> opportunity
> for "anyone" to help write documentation, but provides multiple points
> oversight.
Yep, that's the idea. I'm glad that you like it too.
> The proposed workflow institutionalizes RTC,
RTC?
> but the project can
> always revert a change if others disagree with the decision to approve
> the
> change.
Exactly.
> I do think that we want to try to enure that we have sufficient
> security in
> the system to prevent someone from making an unwanted change and then
> spoofing an approval.
absolutely
> Perhaps we could require SMTP AUTH over SSL for the
> moderators?
Hmmm, I don't really see how this would help. The information to secure
is the continuation ID which is passed along with the email. If you are
not part of the moderation list, you don't get that email.
don't know, maybe I'm missing something, but what do you think a
possible attack could be?
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Saturday, Oct 25, 2003, at 00:39 Europe/Rome, Noel J. Bergman wrote:
> Stefano,
>
> +1
>
> Looks like a good plan that takes the ForrestBot idea, builds on it,
> integrates other things, seems secure and scalable, provides the
> opportunity
> for "anyone" to help write documentation, but provides multiple points
> oversight.
Yep, that's the idea. I'm glad that you like it too.
> The proposed workflow institutionalizes RTC,
RTC?
> but the project can
> always revert a change if others disagree with the decision to approve
> the
> change.
Exactly.
> I do think that we want to try to enure that we have sufficient
> security in
> the system to prevent someone from making an unwanted change and then
> spoofing an approval.
absolutely
> Perhaps we could require SMTP AUTH over SSL for the
> moderators?
Hmmm, I don't really see how this would help. The information to secure
is the continuation ID which is passed along with the email. If you are
not part of the moderation list, you don't get that email.
don't know, maybe I'm missing something, but what do you think a
possible attack could be?
--
Stefano.
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Saturday, Oct 25, 2003, at 00:39 Europe/Rome, Noel J. Bergman wrote:
> Stefano,
>
> +1
>
> Looks like a good plan that takes the ForrestBot idea, builds on it,
> integrates other things, seems secure and scalable, provides the
> opportunity
> for "anyone" to help write documentation, but provides multiple points
> oversight.
Yep, that's the idea. I'm glad that you like it too.
> The proposed workflow institutionalizes RTC,
RTC?
> but the project can
> always revert a change if others disagree with the decision to approve
> the
> change.
Exactly.
> I do think that we want to try to enure that we have sufficient
> security in
> the system to prevent someone from making an unwanted change and then
> spoofing an approval.
absolutely
> Perhaps we could require SMTP AUTH over SSL for the
> moderators?
Hmmm, I don't really see how this would help. The information to secure
is the continuation ID which is passed along with the email. If you are
not part of the moderation list, you don't get that email.
don't know, maybe I'm missing something, but what do you think a
possible attack could be?
--
Stefano.
Re: [proposal] Doco
Posted by Stefano Mazzocchi <st...@apache.org>.
On Saturday, Oct 25, 2003, at 00:39 Europe/Rome, Noel J. Bergman wrote:
> Stefano,
>
> +1
>
> Looks like a good plan that takes the ForrestBot idea, builds on it,
> integrates other things, seems secure and scalable, provides the
> opportunity
> for "anyone" to help write documentation, but provides multiple points
> oversight.
Yep, that's the idea. I'm glad that you like it too.
> The proposed workflow institutionalizes RTC,
RTC?
> but the project can
> always revert a change if others disagree with the decision to approve
> the
> change.
Exactly.
> I do think that we want to try to enure that we have sufficient
> security in
> the system to prevent someone from making an unwanted change and then
> spoofing an approval.
absolutely
> Perhaps we could require SMTP AUTH over SSL for the
> moderators?
Hmmm, I don't really see how this would help. The information to secure
is the continuation ID which is passed along with the email. If you are
not part of the moderation list, you don't get that email.
don't know, maybe I'm missing something, but what do you think a
possible attack could be?
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
RE: [proposal] Doco
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano,
+1
Looks like a good plan that takes the ForrestBot idea, builds on it,
integrates other things, seems secure and scalable, provides the opportunity
for "anyone" to help write documentation, but provides multiple points
oversight. The proposed workflow institutionalizes RTC, but the project can
always revert a change if others disagree with the decision to approve the
change.
I do think that we want to try to enure that we have sufficient security in
the system to prevent someone from making an unwanted change and then
spoofing an approval. Perhaps we could require SMTP AUTH over SSL for the
moderators?
--- Noel
RE: [proposal] Doco
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano,
+1
Looks like a good plan that takes the ForrestBot idea, builds on it,
integrates other things, seems secure and scalable, provides the opportunity
for "anyone" to help write documentation, but provides multiple points
oversight. The proposed workflow institutionalizes RTC, but the project can
always revert a change if others disagree with the decision to approve the
change.
I do think that we want to try to enure that we have sufficient security in
the system to prevent someone from making an unwanted change and then
spoofing an approval. Perhaps we could require SMTP AUTH over SSL for the
moderators?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [proposal] Doco
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Hi Stefano,
I like the idea of putting several existing projects together for this!
Some (detail) comments follow.
> ...The features will be:
>
> 1) super-easy editing (should satisfy wiki lovers)
and should allow offline work as is possible for code now: checkout -
edit offline - sync later
> 2) minimal, efficient and secure workflow (should satisfy board@
> security concerns)
> 3) should allow the creation of static content (should satisfy
> infrastructure@ and mirror@ concerns)
Although this is needed today, it is certainly safe to assume that ASF
sites will be able to run more dynamic stuff in the (hopefully near)
future. This might influence the design, maybe postponing more advanced
features which would require lots of sweat to implement on a static
site.
> 4) should not be a distributed product (should avoid sensations of
> forking from existing projects)
> 5) should reuse more than reinvent
> 6) should come up with structured XML content well organized in a
> repository
Sound good.
> ... 1) everybody can edit a page and submit the changes. the pages on
> the main site will have a link that connects to the pages on the
> backend (which will be probably hosted on another machine, either
> nagoya or moof)
How do you envision the creation of new pages?
Wiki-style, adding a link to a page that does not exist yet?
Might be a detail but there is certainly some impact on the workflow
and approval process.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
RE: [proposal] Doco
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano,
+1
Looks like a good plan that takes the ForrestBot idea, builds on it,
integrates other things, seems secure and scalable, provides the opportunity
for "anyone" to help write documentation, but provides multiple points
oversight. The proposed workflow institutionalizes RTC, but the project can
always revert a change if others disagree with the decision to approve the
change.
I do think that we want to try to enure that we have sufficient security in
the system to prevent someone from making an unwanted change and then
spoofing an approval. Perhaps we could require SMTP AUTH over SSL for the
moderators?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org