xwiki-devs

xwiki-devs@xwiki.org

9399 discussions

[xwiki-devs] [VOTE] Leave CSRF protection enabled by default in 3.2 final

by Alex Busenius

Hello devs, As you know, the 3.2 branch currently has CSRF protection enabled by default for testing purposes. The tests are working fine with it since a couple of months now, and there were only some non-critical bugs found and fixed during that time. The only currently unresolved problem I'm aware of right now is http://jira.xwiki.org/browse/XWIKI-6784 I have some quick test for it locally, but I had very little time recently to clean it up and commit. The 3.2-M* and 3.2-rc* releases have the CSRF protection enabled and have been tested on myxwiki.org without big problems. CSRF protection is important security improvement and we should encourage users to enable it. Nevertheless, enabling it by default is a potentially dangerous change, since it will expose problems with not-CSRF protection aware third party extensions after the update, and therefore needs to be voted about. Related bugs (fixed): http://jira.xwiki.org/browse/XWIKI-4873 http://jira.xwiki.org/browse/XWIKI-6773 Here is my +1 for leaving it enabled. WDYT? Thanks Alex

14 years

[xwiki-devs] Fwd: [ANNOUNCEMENT] Apache Commons IO 2.1 Released

by Vincent Massol

See below Begin forwarded message: > From: Gary Gregory <ggregory(a)apache.org> > Subject: [ANNOUNCEMENT] Apache Commons IO 2.1 Released > Date: October 10, 2011 5:13:43 PM GMT+02:00 > To: announce(a)apache.org, dev(a)commons.apache.org, user(a)commons.apache.org > > The Commons IO team is pleased to announce the Commons IO 2.1 release! > > The Commons IO library contains utility classes, stream implementations, file filters, file comparators and endian classes. > > This is a drop-in replacement for 2.0.1. A list of the 7 new features, 1 change and 7 bug fixes in this release are found in the > release notes and below. > > https://commons.apache.org/io/changes-report.html#a2.1 > > For general information on Commons IO please visit the website: > > http://commons.apache.org/io/ > > The latest version may be downloaded from the following page: > > http://commons.apache.org/io/download_io.cgi > > Thanks again to all involved in the release, both Commons users and > Commons developers. > > = New features since 2.0.1 = > > o Use standard Maven directory layout Issue: IO-285. Thanks to ggregory. > o Add IOUtils API toString for URL and URI to get contents Issue: IO-284. Thanks to ggregory. Could be useful to replace our XWiki.getURLContent() implementation. Thanks -Vincent > o Add API FileUtils.copyFile(File input, OutputStream output) Issue: IO-282. Thanks to ggregory. > o FileAlterationObserver has no getter for FileFilter Issue: IO-262. > o Add FileUtils.getFile API with varargs parameter Issue: IO-261. > o Add new APPEND parameter for writing string into files Issue: IO-182. > o Add new read method "toByteArray" to handle InputStream with known size. Issue: IO-251. Thanks to Marco Albini. > > = Fixed Bugs since 2.0.1 = > > o Dubious use of mkdirs() return code Issue: IO-280. Thanks to sebb. > o ReaderInputStream enters infinite loop when it encounters an unmappable character Issue: IO-277. > o FileUtils.moveFile() JavaDoc should specify FileExistsException thrown Issue: IO-264. > o ClassLoaderObjectInputStream does not handle Proxy classes Issue: IO-260. > o Tailer returning partial lines when reaching EOF before EOL Issue: IO-274. Thanks to Frank Grimes. > o FileUtils.copyFile() throws IOException when copying large files to a shared directory (on Windows) Issue: IO-266. Thanks to Igor Smereka. > o FileSystemUtils.freeSpaceKb throws exception for Windows volumes with no visible files. > Improve coverage by also looking for hidden files. Issue: IO-263. Thanks to Gil Adam. > > = Changes since 2.0.1 = > > o FileAlterationMonitor.stop(boolean allowIntervalToFinish) Issue: IO-259. > > Gary, on behalf of the Apache Commons community > -- > E-Mail: garydgregory(a)gmail.com | ggregory(a)apache.org > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > Spring Batch in Action: http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory

14 years

[xwiki-devs] [Announcement] XWiki Enterprise 3.2 Release Candidate 1 Released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Enterprise 3.2 Release Candidate 1. This is the first (and hopefully last) release candidate for the 3.2 series. Apart from a few minor bugfixes, this version brings the Workspace Manager as a standard feature of the platform, as an alternative way of using virtual wikis, compared to XEM. See http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise32RC1 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 1 month

[xwiki-devs] XEclipse RESTification

by Fabio Mancinelli

Hi everybody, I've just merged the work done by Jun Han in the master branch of the XEclipse repo (https://github.com/xwiki/xwiki-eclipse) Jun has worked during the summer for this GSoC project. Here it is a summary of what has been done, as summarized by Jun: Major work is listed below: 1. Implement an abstract storage layer independent of xmlrpc or rest backend 2. New storage implementation using the XWiki REST API 3. Multiwiki support in the navigator view (using the updated REST API storage) 4. Improve user interface and responsiveness 5. Use JSON library in local storage to replace XML 6. Add operations (add/delete/edit) of page, objects, attachments, class, revision, tag, translation, and comments supported by current REST API Fixed Issues include (not complete): 1. XWiki Eclipse XECLIPSE-154 Grab space operation fails on Spaces named in cyrillic 2. XWiki Eclipse XECLIPSE-137 Open version problem 3. XWiki Eclipse XECLIPSE-131 Error when clicking on a List type object field in the outline view 4. XWiki Eclipse XECLIPSE-41 Display references to document's attachments 5. XWiki Eclipse XECLIPSE-150 Move the build system to Tycho 6. XWiki Eclipse XECLIPSE-145 Maven-based build of XEclipse requires customization to work out of the box 7. XWiki Eclipse XECLIPSE-51 Eclipse update feature 8. XWiki Eclipse XECLIPSE-149 XEclipse does not start under Ubuntu 10.4 9. XWiki Eclipse XECLIPSE-133 XEclipse does not start on OSX if JDK 1.6 is selected 10. XWiki Eclipse XECLIPSE-94 When connecting to a multiwiki install, list all subwikis and ask to which one to connect to >From previous discussion, considering the big amount of new/improved features, we've decided to promote this new development line to 2.0.0-SNAPSHOT and deprecate the old 1.2 one. The idea is to fix the outstanding bugs in order to converge towards a 2.0.0-M1 and then 2.0.0 final. I'd like to thank Jun for his involvement and I hope that he will continue to help us making XEclipse improve. Thanks, Fabio

14 years, 1 month

[xwiki-devs] [Announcement] XWiki Enterprise 3.1.1 and XWiki Enterprise Manager 3.1.1 Released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Enterprise 3.1.1 and XWiki Enterprise Manager 3.1.1, bugfix releases on the 3.1.x stable branch. This is the first (and probably last) bugfix release for the 3.1 series. It contains only small bugfixes backported from the 3.2 branch, mainly around missing CSRF-prevention tokens, the extension manager, and build improvements. See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise311 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 1 month

[xwiki-devs] [VOTE] Improving the migration manager to fix XWIKI-7006, XWIKI-1859, XWIKI-2075, XWIKI-2066

by Denis Gervalle

Hi devs, I need to do XWIKI-6990 (Reduce the likelihood of having same (hibernate) document id for different documents), but XWIKI-7006 (Accessing a store that is not migrated to the lastest data version should not be allowed) is blocking for this to be safely introduced. So I have refactored the migration code to better protect the database, I would like your vote to introduce this patch first, another vote will come for XWIKI-6990. The proposed commit is available at https://github.com/dgervalle/xwiki-platform/commit/f1fa1b1357d17c1ee4ed65eb… In summary, here is what it does: a) Refactor the old XWikiMigrationInterface and XWikiMigratorInterface into new DataMigrationManager and DataMigration interfaces b) Implement the DataMigrationManager and the DataMigration interfaces using components for the hibernate stores c) Remove the migration check from XWiki and put them in hibernate stores components, freeing this from XWiki. Since store still use the XWikiContext, I still use it, but from the execution context, no more passing it everywhere. d) Use a cache for DB version to not degrade performance e) Remove many call to schemaUpdate which require synchronization, executing only schema updates during data migrations. f) Remove some data migration like code from schemaUpdate, convert it to HQL (in place of native SQL :() and put them in an initial LegacyDataMigration, that migrate from version 0 to version 1 g) Fix empty/new database issue by considering a database without version AND without documents as a new database, and initialize it with the current schema and the latest version. h) Properly report migration failure and prevent access on failure i) Prevent access to any database not being properly migrated to the latest version by never providing a valid transaction for it. By the way, fix another (unnoticed ?) bug: if a throw occurs during database switching, a transaction could be return and used improperly (mixing data from different database). j) deprecate xwiki.store.hibernate.updateschema, but use "1".equals(config.getProperty("xwiki.store.migration", "0") && !"0".equals(config.getProperty("xwiki.store.hibernate.updateschema") to enable migrations k) Now xwiki.store.migration.databases=all, before it was xwiki only, which is not right IMO Currently, migration manager is injected in stores, using a hint, since the migration manager will be different depending on the store that keep the data version. The migration manager lookup the store by hint to retrieve the data version. The migration manager lookup data migrations using hint as well. Finally, data migrations lookup stores again using hint. Some improvements would be to allow multiple data versions (one per store hint), and mix data migration, since stores could be mixed, but this is out of my scope currently. To support injecting store by scope properly, there is another separate commit, available at https://github.com/dgervalle/xwiki-platform/commit/6a353d6d45bfb73789ed0693…, which replace the default unnamed stores, by "hibernate" named stores. Since store are still initialized at XWiki initialization, migration still occurs during first request to the system, but this is no more related to the migration system, which intercept the first database access, but this is related to this XWiki initialization only now. So XWIKI-2075 is fixed for me. I have already work hard to reach this state, there is still room for improvements, but I will not be able to afford much more time on this right now (at least without a sponsor :)). Please be fair in your remarks ;) Here is my +1. Currently the patch is done for 3.3, but if you think it could go in 3.2, I am +1. -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

14 years, 1 month

[xwiki-devs] [VOTE] Fixing cyclic dependency introduced by the workspace module

by Eduard Moraru

Hi devs, The workspace module has a maven artefact (workspace-template) that produces an enhanced (adds extra pages, set some properties, overrides some pages, etc.) XE xar that is to be used by all the created workspaces. The problem is that, being part of the platform, this creates a cyclic dependency in maven thus breaking the build. Also, the 3.2RC1 release is supposed to be today, so the matter is rather urgent. To fix this, there might be a couple of solutions on which I`d like your opinion/vote: 1) Rewrite the workspace-template module and, instead of using maven to produce a customized XE xar, use velocity within the workspace application to enhance a standard XE xar at runtime, when actually creating the workspace. (needs some time) 2) Move the workspace-template module into the XEM build and bundle workspace by default with XEM. (quick to do) 3) Move the workspace-template module into the XE build, even though workspaces is not bundled by default with XE. (quick to do, but not necessarily right) 4) Unlink the workspace module from the platform build, so that it is skipped from the build and that it does not break it, but leave the hooks. (quick to do, leaves way for further work) 5) Just revert everything related to workspaces from the platform and possibly keep the existing work in a branch. (quick to do, but also removes the hooks) Here's my +1 for 2). Thanks, Eduard

14 years, 1 month

[xwiki-devs] [VOTE] Naming policy for "-manager" modules and naming the "Workspace feature"

by Eduard Moraru

Hi devs, Since starting to develop the workspaces feature, under the Wiki3.0 project, I`ve used internally the name "Workspace Manager" (providing the script service "$services.workspaceManager") by following the naming scheme used by the Wiki Manager plugin. When the code was moved into the platform, I`ve named the top maven artefact "xwiki-platform-workspace-manager" and the java package "org.xwiki.workspacemanager". Recently, Vincent proposed [1][2](see arguments) to drop the "-manager" suffix, thus, the following changes would occur: - "$services.workspace" instead of "$services.workspaceManager" - "org.xwiki.workspace" instead of "org.xwiki.workspacemanager" - "xwiki-platform-workspace" instead of "xwiki-platform-workspace-manager" - "Workspace Feature" instead of "Workspace Manager Feature" Since it's a new module, there are no problems with backward compatibility so the changes can be applied with some minor refactorings of the velocity code using the service. I did not know about this naming policy, so I`d like your opinion/vote on whether to apply the proposed changes and enforce this policy in the future as well. Here's my +1. Thanks, Eduard References: ----------------- [1] https://github.com/xwiki/xwiki-platform/commit/8c1cc0bc73249eee20159dc3e540… [2] https://github.com/xwiki/xwiki-platform/commit/8c1cc0bc73249eee20159dc3e540…

14 years, 1 month

[xwiki-devs] [VOTE] Keep empty reference in XHTML

by Thomas Mortagne

Hi devs, When you want a local link you use something like [[label>>#anchor]] and it will produce an XHTML like <a href="/xwiki/bin/view/CurrentSpace/CurrentDocument#myanchor">label</a>. IMO this is not very good since: * it's doing lot's of useless work (resolving the reference, getting the corresponding XWikiDocument to finally generate the URL thanks to URLFactory * it's breaking any included local reference since it will be resolved based on the source document and not the current document which makes sense when you target a specific document but not when you asked for a local reference Note that it used to be that way (and I tough it was still the case) and I don't remember why this has been changed. So I proposed to put back the specific handling of empty reference: produce <a href="#myanchor">label</a> in the XHTML renderer for the previous example. WDYT ? Here is my +1 -- Thomas Mortagne

14 years, 1 month

[xwiki-devs] [Proposal] Add support for DocBook integration in XWiki Rendering

by Vincent Massol

Hi devs, This weekend I've been working on adding docbook support in XWiki Rendering by using the Doxia Bridge (since Doxia as both a DocBook parser and a DocBook renderer). I'd like to commit this now for 3.2RC1 if possible since it's not going to cause any issue with anything else (it's something new not impacting existing stuff). WDYT? Thanks -Vincent

14 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs