- xwiki-devs@xwiki.org - lists.xwiki.org

Re: [xwiki-devs] SVN Application for XWiki
by Denis Gervalle 05 May '10

05 May '10

On Mon, May 3, 2010 at 21:54, Ludovic Dubost <ludovic(a)xwiki.org> wrote: > > Hi Denis, > > Thanks for the feedback and testing > > > Le 03/05/10 21:20, Denis Gervalle a écrit : > > Hi Ludovic, >> >> I have made some quick testing of this application in our sandbox, and I >> have discovered weird issues in relation with the document history. >> >> Here is what I have noticed so far: >> >> I've seen indeed some issue with the history. I thought it was limited to > having to resave the document to fix it. > Resaving may be not possible due to the exception you may get when you save. > I will look into it. I had to add some code specially for handling > attachments. I suspect that is what is creating the problems No attachment in my test, just a very small page. The issue is in the way you manage archives. > - Checking out new document from the repository, the document does not >> have >> an history at all, and the creator of the document is not set >> - Checking out a existing document from the repository (reverting a >> change), cause the history of the document to be somewhat inverted, the >> current document being 1.1 version and the history containing later >> versions... (except when only 1.1 version were existing). The document >> also >> cause an exception when you try to save some modification to it: >> >> Detailed information: >> Error number 3201 in 3: Exception while saving document Main.TestPage2 >> Wrapped Exception: Failed to commit or rollback transaction. Root cause >> [] >> com.xpn.xwiki.XWikiException: Error number 3201 in 3: Exception while >> saving document Main.TestPage2 >> Wrapped Exception: Failed to commit or rollback transaction. Root cause >> [] >> at >> >> com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:638) >> ... >> Wrapped Exception: >> org.hibernate.StaleStateException: Batch update returned unexpected row >> count from update [1]; actual row count: 0; expected: 1 >> >> The change is then recorded in the archive and not in the document, >> creating >> the same "inverted" history situation. I suspect it happen due to >> a discrepancy between the cache and the database, since after a restart, >> the >> 1.1 (current) version is no more in the history. >> >> - After a restart, I also got some "C" status, which are not documented, >> and I imagine, means conflict. But since this is just a restart that cause >> them, this not expected. Looking at the details, this append on groups, >> because of object GUID changes without any other changes, and it may be >> unrelated to your application in particular. >> > Interesting. How come would GUID change in groups ? > I do not investigate, just noticed that after a tomcat restart, one GUID has changed on all groups. > Indeed this does not seem related to the SVN app. > Either this is normal and then we could change the comparaison to ignore > such GUID changes. However the GUID is important data. Probably it is not related and would not do that. - At an initial attempt to go back to the list after committing and then >> updating a new page, it has shown a status of '?' in place of 'M', but I >> have not reproduced that later :( >> > The only reason to show ? is that either > > there is a change both in SVN and in the Wiki > Does this means C and not "?" ? > OR > the status information is not filled in Agree, and I have get that while the status is available, but I was unable to reproduce :( > - SVN operations also cause the recycle bin to contains deleted >> document, >> is it intended ? >> > This is possible.. I have to check > > > I also have a question regarding the usage of the status field. Why it is >> required to keep this status ? if needed, why coding it in place of >> keeping >> it with each document (in an xobject) ? >> >> I thought about that but did not want the SVN application to have any > impact on the wiki you want to commit to SVN > Well, it would be nice, but it has more than you expect, and the way you get rid of the Tag object could also be an issue, due to the bad way object are deleted currently in documents. Do you really need that status information ? Denis On Thu, Apr 22, 2010 at 19:42, Ludovic Dubost<ludovic(a)xwiki.com> wrote: >> >> Hi, >>> >>> >>> If you are following the xwiki comments, you might have seen that I've >>> been >>> working on an SVN application for XWiki. >>> >>> I've published this application here: >>> http://code.xwiki.org/xwiki/bin/view/Applications/SVNApplication >>> >>> The objective of this application is to bring to XWiki Applications more >>> professional development practices. >>> One of them is the ability to do version management of XWiki >>> applications. >>> Of course XWiki contains versioning but this versioning does not apply >>> accross wikis and makes it difficult to contribute code back to the >>> community. >>> >>> With the SVN application you can now directly contribute code and code >>> updates to the XWiki SVN contrib repository or to any other SVN >>> repository. >>> You can even commit in multiple SVN repositories in the same Wiki. >>> >>> The SVN Application supports: >>> >>> 1/ Compare the Wiki (limited to a list of spaces) with the SVN repository >>> listing >>> - added pages in the wiki >>> - modified pages in the wiki >>> - new pages in SVN >>> - modified pages in SVN >>> - conflicting pages modified in both SVN and the Wiki >>> 2/ Commit in the SVN Repository >>> 3/ Update from the SVN Repostory >>> 4/ Show differences between SVN and the Wiki (in XML) >>> >>> The SVN Application does not provide merging and conflict resolution. The >>> SVN Application normalizes XWiki XML allowing the cleanup the XML to not >>> have the user, the dates, comments. This is necessary to provide >>> concurrent >>> development on multiple XWiki server without telling you that the pages >>> have >>> changed all the time. >>> >>> The source code is of course in SVN at >>> http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-svn/ >>> >>> Ludovic >>> >>> -- >>> Ludovic Dubost >>> Blog: http://blog.ludovic.org/ >>> XWiki: http://www.xwiki.com >>> Skype: ldubost GTalk: ldubost >>> >>> >>> _______________________________________________ >>> devs mailing list >>> devs(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >>> >>> >> > > -- > Ludovic Dubost > Blog: http://blog.ludovic.org/ > XWiki: http://www.xwiki.com > Skype: ldubost GTalk: ldubost > > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

4 10

[xwiki-devs] [Proposal] Fix inconsistencies in access to the change password feature
by Denis Gervalle 04 May '10

04 May '10

Hi devs, I would like to fix the current inconsistencies in the way the change password feature is implemented. Actually, to be able to change a password, you need to be able to save the document storing the XWikiUsers XObject. So edit right on the user profile is just what you require, but, if you want to use the "change password" feature implemented in passwd.vm, you need: - either being on your own profile or having global (!) admin right, just to see the "Change password" button - either being on your own profile or having (local) admin right on this profile, just to be able to use passwd.vm This seems to me really inconsistant, since these protections implemented in the UI part are either annoying or a false impression of security. So, I propose to simplify this by only checking the real requirements, which means only checking edit right on the user document ? WDYT ? Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

3 3

[xwiki-devs] xwiki-core-xmlrpc-client-2.1.1.jar
by Vivian Richard 04 May '10

04 May '10

Where can I find this jar file? On this page there is a link but it does not work - http://platform.xwiki.org/xwiki/bin/view/Features/XMLRPCJavaExamples the link is: http://maven.xwiki.org/releases/org/xwiki/platform/xwiki-core-xmlrpc-client…

3 2

[xwiki-devs] SVN Application for XWiki
by Ludovic Dubost 03 May '10

03 May '10

Hi, If you are following the xwiki comments, you might have seen that I've been working on an SVN application for XWiki. I've published this application here: http://code.xwiki.org/xwiki/bin/view/Applications/SVNApplication The objective of this application is to bring to XWiki Applications more professional development practices. One of them is the ability to do version management of XWiki applications. Of course XWiki contains versioning but this versioning does not apply accross wikis and makes it difficult to contribute code back to the community. With the SVN application you can now directly contribute code and code updates to the XWiki SVN contrib repository or to any other SVN repository. You can even commit in multiple SVN repositories in the same Wiki. The SVN Application supports: 1/ Compare the Wiki (limited to a list of spaces) with the SVN repository listing - added pages in the wiki - modified pages in the wiki - new pages in SVN - modified pages in SVN - conflicting pages modified in both SVN and the Wiki 2/ Commit in the SVN Repository 3/ Update from the SVN Repostory 4/ Show differences between SVN and the Wiki (in XML) The SVN Application does not provide merging and conflict resolution. The SVN Application normalizes XWiki XML allowing the cleanup the XML to not have the user, the dates, comments. This is necessary to provide concurrent development on multiple XWiki server without telling you that the pages have changed all the time. The source code is of course in SVN at http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-svn/ Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

4 5

[xwiki-devs] [VOTE] Commit Search application
by Thomas Mortagne 03 May '10

03 May '10

Hi devs, I have been working on an search related administration UI and i would like to commit a first version on svn and put it as XE 2.4-SNAPSHOT dependency to start review and improvements. Better do it as soon as possible instead of arguing just before the release of 2.4M1 since it's functionally complete and just need potential UI work (even if it's not worst than others admin section UIs ;)). This new application contains: * search administration UI: administration section that permit to choose the default engine ("lucene" and "web" for now) to use in the search panel and some Lucene status and control tools * all search related pages (panel, web/lucene search pages, XWiki.Result) moved from XE. I did not touched anything except the panel to support engine option, it's just a move for now * the default search engine is lucene TODO before commit: * put some new textual content in ApplicationResources.properties for the admin page TODO after first commit: * refactor ApplicationResources.properties to reflect the fact that some textual content moved from XE app to Search app * i will work on making "element to index" queue status refresh automatically using ajax WDYT ? Here is my +1 Thanks, -- Thomas Mortagne

8 8

[xwiki-devs] [Proposal] Merge dev:Drafts.SecuringXWiki with platform:AdminGuide.Security
by Caleb James DeLisle 03 May '10

03 May '10

Hello all, http://dev.xwiki.org/xwiki/bin/view/Drafts/SecuringXWiki has existed since 2009/12/26 and has become a place for explaining how to make XWiki more secure as well as containing some information about testing for the recently disclosed SQL issue. I would like to merge it into: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Security I will leave the draft page up for a while because I had linked to an anchor in it in the security advisory mail. Eventually I plan to blank the page, leaving only a redirect and remove it from the drafts section. Caleb

5 4

[xwiki-devs] What browsers do we officially support?
by Caleb James DeLisle 03 May '10

03 May '10

I was just wondering what browsers do we support? Is this written down somewhere? I assume we do not support browsers with script turned off since menus and the admin app require script. Are there multiple levels of support? For example: more browsers supported for guests viewing than administrators or some browsers must have all functionality but can have ugly UI? Thanks Caleb

5 7

[xwiki-devs] Fwd: [ANNOUNCE] Velocity Engine 1.7-beta1 release available
by Vincent Massol 03 May '10

03 May '10

fyi -Vincent Begin forwarded message: > From: Nathan Bubna <nbubna(a)apache.org> > Date: April 28, 2010 12:53:50 AM GMT+02:00 > To: Velocity Developers List <dev(a)velocity.apache.org>, Velocity Users List <user(a)velocity.apache.org>, announce(a)apache.org > Subject: [ANNOUNCE] Velocity Engine 1.7-beta1 release available > > The Velocity developers are please to announce the availability of > Velocity Engine 1.7-beta1. > > Downloads can be found here: > http://velocity.apache.org/download.cgi > > A great deal of work has been done since the 1.6 branch. Here's a taste: > > - Your macros can now be called with bodies when you want: > #macro(foo)Here is $bodyContent#end > #@foo()body content!#end > - Quotes can be escaped in strings by doubling them: > #set( $foo = "$person said, ""$comment"" " ) > #set( $bar = 'Joe said, ''Hi!'' ' ) > - The flawed #literal directive has been replaced with: > #[[ This is included but not parsed, so #if and $foo need no escaping.]]# > > Also included are namespacing improvements, better #break and #stop, > bracketed index syntax, and more! For full details, please see the > change log: > http://velocity.apache.org/engine/devel/changes-report.html > > This should work as a drop-in replacement for Velocity 1.6.3 in the > vast majority of cases. However, there have been a number of > deprecations (should result in warnings in your log output) and a few > minor behavioral changes, all of which are explained in the change > log. :)

3 5

Re: [xwiki-devs] [xwiki-notifications] r28664 - platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table
by Sergiu Dumitriu 29 Apr '10

29 Apr '10

On 04/29/2010 05:21 PM, dgervalle (SVN) wrote: > Author: dgervalle > Date: 2010-04-29 17:21:25 +0200 (Thu, 29 Apr 2010) > New Revision: 28664 > > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.js > Log: > XWIKI-5135 - Highlight applied filters in livetable > Fix tag names comparison to uppercase string. > > Modified: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.js > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.js 2010-04-29 13:13:38 UTC (rev 28663) > +++ platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.js 2010-04-29 15:21:25 UTC (rev 28664) > @@ -698,7 +698,7 @@ > * Apply style to livetable filters that are applied > */ > applyActiveFilterStyle: function(element) { > - if(element&& ((element.tagName == "input"&& element.type == "text") || element.tagName == "select")) { > + if(element&& ((element.tagName == "INPUT"&& element.type == "text") || element.tagName == "SELECT")) { That's not quite correct. Depending on the browser, doctype and mimetype, it could be lowercase. Better use some case insensitive comparison, for example: element.tagName.toLowerCase() == "input" > if ($F(element) != '') { > element.addClassName('xwiki-livetable-filter-active'); > } else { -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 2

[xwiki-devs] [Security Advisory] SQL injection issue.
by Caleb James DeLisle 29 Apr '10

29 Apr '10

In the 2.3 timeframe, a serious security bug was fixed. Hibernate treats backslashes differently from some database management systems and as a result native SQL can be injected through the searchDocuments function. This means members of a wiki can finish an SQL query, also this means that badly written searchDocuments or search queries go from small security issues to larger ones. NOTE: Passwords are hashed (encrypted) so they cannot easily be read from the database. Who's at risk? Database systems which treat backslash as an escape character and allow stacked queries are susceptible to arbitrary SELECT, INSERT, UPDATE, DELETE, and DROP statements. These include: MS-SQL Postgres Database systems which treat backslash as an escape character but disallow stacked queries are susceptible only to arbitrary SELECT statements. These include: MySql Oracle Database systems which do not treat backslash as an escape character are not vulnerable these include: HSQLDB (default XWiki zip/exe installation) You can get a small groovy snippet to test your database and see if it supports stacked queries here: http://dev.xwiki.org/xwiki/bin/view/Drafts/SecuringXWiki#HMitigationMethods… What can be done: #1: XWiki-2.3 and XWiki-2.2.6 Are patched to convert \ to \\ in search queries so upgrading to them will negate the threat. You can download them here: http://www.xwiki.org/xwiki/bin/Main/Download #2: If you compile your own branch of XWiki and are unable to upgrade, you can integrate the patch which was used to fix the problem The patch is here: http://dev.xwiki.org/xwiki/bin/download/Drafts/SecuringXWiki/XWIKI%2D4755%2… Since the database controller has changed, you will likely have to port this patch to your version, what's important is that api.XWiki.searchDocuments and api.XWiki.search have their input filtered. #3: You can and should make sure to log unexpected SQL at the database level. XWiki doesn't usually use the backslash character and queries containing backslashes should be logged specially. Also it is a good idea to log (or block if possible) any SQL comment syntax. Hibernate does not support comments and comment syntax is central to almost all SQL injection. Caleb

1 0