Hi guys,
I think we need to an agreement on how to handle the default Tomcat security which disables the usage of / and \ in URLs (even URL-encoded). See http://www.tomcatexpert.com/blog/2011/11/02/best-practices-securing-apache-…
We have 2 main options:
* Option 1: Tell users to disable this security feature of Tomcat: http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security. In this case we just need to review our code to ensure we’re not subject to directory traversal attacks (see https://en.wikipedia.org/wiki/Directory_traversal_attack).
* Option 2: Decide to make it easy for Tomcat users (since it’s probably the typical servlet container used by our users) and to not use / and \ in our URLs.
Option 2 means modifying our code. There are various possibilities:
* A) Replace the “/“ and “\” characters by other characters in URLs and modify our URL Serialization code (implementations of XWikiURLFactory) and our URL parsing code (URL modules).
* B) Use a different encoding. Marius has used Base64 encoding for http://jira.xwiki.org/browse/XWIKI-11528. However this cannot be a generic solution since it leads to large URLs and also makes the URL not legible anymore. So this solution could only be for internal URLs.
* Other?
For A), it could b a character like ‘|' for ‘/' (and thus “||" if you want to have a real ‘|') and ‘~’ for ‘\’ (and “~~” if you want to have a real ‘\’).
So there are 2 questions in this thread:
* Do we want to be Tomcat-friendly?
* If so, what strategy do we apply?
WDYT?
Thanks
-Vincent
Hello there !
I had some issue about WYSIWYG editor, I explain :
I wanted to add a link toward a xWiki page using the "Research" tab
But sometimes I had access to the field and sometimes I didn't.
It seemed pretty random to me, but then i realize it was caused by the
"Allow Realtime Collaboration"
When it was checked, i couldn't access to the research field"
when it was unchecked i could.
So i solve my issue, I though that maybe you guys should be aware of that !
here's two screenshots to show you :
[image: Images intégrées 1]
--
*Vianney Deneux*
Élève ingénieur à Telecom Lille
Engineering Student at Telecom Lille
<http://www.telecom-lille1.eu/>06 28 34 53 84
<http://www.nounou-top.fr/>
Hello devs,
Would someone be kind to validate my extension on nexus, please?
extension id : application-rightsui-simplifier
vesion: 1.0
Thanks,
Paul Pantiru
I devs,
I just started as an experiment a contrib project dedicated to provide
contrib oriented parent poms on
https://github.com/xwiki-contrib/parent.
Right now it contains a pom to use for extension depending on
commons/rendering (parent-commons) and one for extension depending on
platform (parent-platform) and also a release script.
I just did a release for current LTS branch (6.4). If you want to
release parent for other branches please create corresponding branch.
--
Thomas Mortagne
The XWiki development team is proud to announce the availability of XWiki
7.3.
This is a stabilisation release focusing on the Nested Pages feature which
was introduced in XWiki 7.2.
Lots of polishing has been done for the Nested Pages feature integration,
targeting the consequences on the UI redesign and the changes at
applications level. The release includes a couple of bug fixes, a few
dependency upgrades and new UI extension points available for extension
developers.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki73
The following people have contributed code to this release:
Clemens Robbenhaar
Ecaterina Moraru (Valica)
Eduard Moraru
Gabriela Smeria
Guillaume Delhumeau
Jean SIMARD
Manuel Smeria
Marius Dumitru Florea
Pascal Bastien
Sergiu Dumitriu
Thomas Mortagne
Vincent Massol
Thanks for your support
-The XWiki dev team
Hi devs,
I see at http://www.xwiki.org/xwiki/bin/view/Main/License that we say: “The wiki documents (all the documents in the default .xar archive) are distributed under Creative Commons (CC-BY)”.
However currently all our wiki pages in GitHub (the XML files) are licensed under LGPL 2.1
Do we need to change the license for all those XML files?
Thanks
-Vincent
Today we are supposed to release 7.3Final.
Since there was a delay in releasing 7.3RC1 by one week, I propose to delay
the release for 3 days to 11/11 (in order to include the planned issues,
manage tests, etc.) In the worst case scenario, 7.3 should be released on
13/11. The sooner we release, the better for the 7.4 timeframe.
This week of delay was already considered as buffer in the Roadmap for 7.3
planning (see the Roadmap mail from 24 Sep).
Until further notice, the initial planned dates for 7.4 remain the same:
7.4M1: 30 November 2015 (2 weeks)
7.4M2: 14 December 2015 (2 weeks)
7.4RC1: 21 December 2015 (1 week)
7.4final: 28 December 2015 (1 week)
Note that these dates will be hard to achieve with all the Christmas
holidays.
Thanks,
Caty
Hi devs,
As you know our goal is to use myxwiki.org as a real life test platform to validate releases of XWiki.
Current Situation
==================
However this is currently not working very well for 2 reasons:
1) We’re always lagging behind on the version installed on myxwiki.org. Right now it’s 7.1.2 and our last released version is 7.3M2. Thus if we notice a problem on myxwiki.org, it’ll be fixed only in much later versions and myxwiki.org is not playing its role of helping validate releases before we release final versions.
2) We don’t really monitor the performance of myxwiki.org.
3) We don’t really analyse issues that can happen on it because we don’t check the logs.
Thus I think we need to find a better process for benefitting from myxwiki.org.
Question
=========
Are we still interested in benefitting from myxwiki.org for testing our releases?
If not, then stop reading at this point :)
If we are, then I’m making some proposals below.
Proposal
=========
For 1):
I’d like to propose to add a step in our ReleasePlan template as the last step:
- Check the myxwiki.org upgrade roster and ping the next person to update myxwiki.org
So the idea would be to not make the RM do the upgrade since he/she already has a lot to do to release XWiki but to make him/her responsible for pinging someone to do it. Then we would take turn to upgrade it (in a similar fashion as we do for releasing XWiki).
Note that I believe this would also make us work on making it simpler to perform XWiki upgrades and this would benefit our users. We would eat our own dog food basically :)
For 2):
Here are ideas of what we could monitor and receive alerts when they go beyond a given threshold:
- the average response times users get on it,
- when a specific requests takes more than N seconds (this would also allow us to find wiki pages written by our users and which take too much CPU thus making the farm slower than it should be),
- its uptime
- the memory used
For 3):
I think we could set up some elastic search/kibana solution as we had set up at some point (this makes it nice to browse and search for logs) and then send automatic mails to the devs list or IRC when exception happen. This would have the nice benefit of making us work on fixing the code and not generating exceptions when we have only warnings that don’t impact the stability of the platform.
WDYT?
If we agree, then we’ll need to discuss how to setup 2 and 3.
Thanks
-Vincent
The XWiki development team is proud to announce the availability of XWiki
7.3 Release Candidate 1. This release candidate includes a couple of bug
fixes and a few dependency upgrades, as well as some improvements related
to Nested Pages. The extension developers should check the new UI extension
points available for the top menu.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki73RC1
The following people have contributed code to this release:
Clemens Robbenhaar
Ecaterina Moraru (Valica)
Eduard Moraru
Guillaume Delhumeau
Marius Dumitru Florea
Thomas Mortagne
Vincent Massol
Thanks for your support
-The XWiki dev team