buildbot success in on ofbiz-trunk-framework-plugins

[buildbot]

The Buildbot has detected a restored build on builder 
ofbiz-trunk-framework-plugins while building . Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk-framework-plugins/builds/596

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: orcus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 
'on-ofbiz-framework-commit' triggered this build
Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1812794
Blamelist: mbrohl

Build succeeded!

Sincerely,
 -The Buildbot

buildbot failure in on ofbiz-trunk-framework-plugins

[buildbot]

The Buildbot has detected a new failure on builder 
ofbiz-trunk-framework-plugins while building . Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk-framework-plugins/builds/595

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: orcus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz-plugins-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/ofbiz-plugins/trunk] 1812790
Blamelist: mbrohl

BUILD FAILED: failed shell_4

Sincerely,
 -The Buildbot

Re: [Discussion] documentation framework for OFBiz

[Taher Alkhateeb]

Thank you folks for your feedback. Based on everyone's input, I think
perhaps a good way to move forward is by creating a JIRA and making a
patch for a PoC.

I think altering the OFBiz help system for now might be a bigger task,
so for a start, I think I will write some documentation in multiple
places and then let gradle consolidate that into an output manual.
Then, based on feedback from you we decide on the next step.

So I will proceed with creating a JIRA for an initial PoC. Again,
thank you for your thoughts, all constructive and valuable.

On Wed, Oct 18, 2017 at 11:47 AM, Jacques Le Roux
 wrote:
> Hi Sharan,
>
> Yes I'm pretty sure we will still need the wiki. For technical points which
> don't specially fit in source and also some kind of user documentation, but
> the less the better.
>
> Jacques
>
>
> Le 18/10/2017 à 10:28, Sharan Foga a écrit :
>>
>> Hi
>>
>> I would say the first and easier focus is to complete the online help.
>> Telling people how to use the screens and applications is a basic
>> requirement that we haven't fulfilled for OFBiz yet.  Once we have that then
>> we can see how it can be expanded to incorporate more general details. I
>> think the issue we have had over the years is that OFBiz is so big that it's
>> difficult to know where to start.
>>
>> At least if we can give people information about the application they are
>> using, and how to use the screens, then that will give them enough to get
>> going. For content we could review the existing help that we have and update
>> it into a standard format or template so that it is consistent.
>>
>> We may also find that we still need the wiki for something so let's see
>> what happens
>>
>> Thanks
>> Sharan
>>
>> On 2017-10-17 13:21, Jacques Le Roux  wrote:
>>>
>>> Yes thanks Taher to have picked this again,
>>>
>>> I agree with all what have been said so far.
>>>
>>> You know my preference for asscidoc and asciidoctor. Using the
>>> asciidoctor Gradle plugin seems logical to me.
>>>
>>> I'm all for having all the documentation inside the source. I had even
>>> created a Jira for that https://issues.apache.org/jira/browse/OFBIZ-9423
>>>
>>> Questions:
>>>
>>>   1. Should we continue to provide an online help? Would we reuse/upgrade
>>> the current one?
>>>   2. Where to put the common documentation? In common or commonext
>>> component or in a new documentation folder? Later seems easier for newbies,
>>> name
>>>  says all.
>>>   3. I use pandoc to create (from some .md files) md.html files in
>>> tools\wiki-files imported in wiki pages. I regularly use a .bat for that.
>>> Would we
>>>  replace also our current .md files?
>>>
>>> Jacques
>>>
>>>
>>> Le 17/10/2017 à 11:25, Michael Brohl a écrit :
>>>
 Big +1 for this initiative!

 I have not much to add to Taher's proposal and Sharan's viewpoint.

 I assume that we can use any Asciidoc editor and need not to use
 Asciidoctor?

 I think we have to decide what we will do with our Wiki based
 documentation then. If we have up-to-date documentation in the components
 and can
 generate up-to-date documentation every night, pretty much of the Wiki
 documentation would be obsolete. A simple link to the generated
 documentation
 would be enough, right?

 For new code in framework and plugins, I would strongly recommend to
 have mandatory documentation as part of the first commit to the codebase to
 assure a good initial start.

 I think we should just start with a proof-of-concept by moving some
 small part of the documentation to Asciidoc and into the codebase.

 Would be a great starting point for new contributors also.

 Best regards,

 Michael


 Am 17.10.17 um 10:30 schrieb Sharan Foga:
>
> Hi Taher
>
> It's great that this conversation has started again. It would be great
> to actually start to do something about the integrated help system within
> OFBiz itself. We have found limitations with the docbook implementation
> we have, so now have a better idea of what we want to achieve.
>
> In the past we've talked a lot about DITA but to me it seemed a lot
> more complex to understand, structure and generally get started. I've
> briefly
> played about with Ascidoc and it seems pretty simple enough to get the
> hang of and that to me is an important thing. I also like the idea of 
> being
> able to render multiple formats (and it would be good to make them look
> nicer and easier to read).
>
> Getting a good and functioning help framework into our codebase is long
> overdue and I'm sure will add some great benefits and also encourage
> documentation contributions from our community.
>
> Big +1 from me!
>
> Thanks
> Sharan
>
>
> On 17/10/17 10:01, Taher Alkhateeb wrote:
>>
>> 

Content Security Policy HTTP security header

[Jacques Le Roux]

Hi,

At https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Secure+HTTP+Headers 
I have summarize my work on HTTP Security Headers

I have done the easy part, ie all headers but Content-Security-Policy. They are 
grouped in RequestHandler.renderView() just before rendering the view

For Content-Security-Policy I'd like to use the safer one OOTB ie: 
resp.setHeader("Content-Security-Policy", "default-src 'self'");

This means that all resources links should be local. The resources types are 
script, object (plugins), style, img, media, frame, font, connect and form.

No need to say that it's very ambitious and not for today.

The 1st task to handle is to remove as much as possible JavaScript snippets and 
have as much as possible JavaScript files.

There are already few Jiras about that and we are slowly heading in the right 
direction.

It's not sure we can reach this very ambitious goal and the good news is that 
it's not a problem if we don't.

When we will hit cases where local it's not possible then we can define so 
called nonce to be sure the resources are loaded from the right place.

In no case we should OOTB use the lazy unsafe-inline and eval-inline.

To not block anything for the moment I have committed a simple most restrictive 
Content-Security-Policy-Report-Only header at r1812720

Then we can look at the issues using browsers tools (there are so much)

The next step is to report the errors (when there will not be too much) in the 
log using a report-uri

And ultimately to use OOTB the most simple and constraining policy, with 
exceptions of course (as ever).

Note: if we encounter performance issue we can comment out the current 
Content-Security-Policy-Report-Only

Jacques