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

Re: [xwiki-devs] [xwiki-notifications] r29564 - enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui

by Vincent Massol

Thanks Caleb! :) -Vincent On Jun 18, 2010, at 9:10 PM, cjdelisle (SVN) wrote: > Author: cjdelisle > Date: 2010-06-18 21:10:28 +0200 (Fri, 18 Jun 2010) > New Revision: 29564 > > Removed: > enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/ScriptingTest.java > Log: > XWIKI-5275: Prevent nested script macros. > Removed r29501 since it's now duplicated in unit tests. > > Deleted: enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/ScriptingTest.java > =================================================================== > --- enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/ScriptingTest.java 2010-06-18 18:09:53 UTC (rev 29563) > +++ enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/ScriptingTest.java 2010-06-18 19:10:28 UTC (rev 29564) > @@ -1,117 +0,0 @@ > -/* > - * See the NOTICE file distributed with this work for additional > - * information regarding copyright ownership. > - * > - * This is free software; you can redistribute it and/or modify it > - * under the terms of the GNU Lesser General Public License as > - * published by the Free Software Foundation; either version 2.1 of > - * the License, or (at your option) any later version. > - * > - * This software is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > - * Lesser General Public License for more details. > - * > - * You should have received a copy of the GNU Lesser General Public > - * License along with this software; if not, write to the Free > - * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > - * 02110-1301 USA, or see the FSF site: http://www.fsf.org. > - */ > -package org.xwiki.it.ui; > - > -import java.util.HashMap; > - > -import org.junit.Assert; > -import org.junit.Before; > -import org.junit.Test; > -import org.openqa.selenium.By; > -import org.openqa.selenium.WebElement; > -import org.xwiki.it.ui.elements.WikiEditPage; > -import org.xwiki.it.ui.framework.AbstractAdminAuthenticatedTest; > - > -/** > - * Test script macros. > - * > - * @version $Id$ > - * @since 2.4M2 > - */ > -public class ScriptingTest extends AbstractAdminAuthenticatedTest > -{ > - private static boolean initialized; > - > - @Before > - public void setUp() > - { > - if (!initialized) { > - super.setUp(); > - initialized = true; > - } > - } > - > - @Test > - public void testNestedEvaluation() > - { > - final String content = "{{html wiki=\"true\"}}\n{{velocity}}\n#set($x = 'script' + ' test')\n$x\n" > - + "{{/velocity}}\n{{/html}}\n"; > - > - getDriver().get(getUtil().getURL("ScriptingTest", "testNestedEvaluation", "preview", > - new HashMap<String, String>(){{put("content", content);}})); > - > - // check that the nested script is evaluated > - WebElement pageContent = getDriver().findElement(By.xpath("//div[@id='xwikicontent']/p")); > - Assert.assertEquals("Invalid content", "script test", pageContent.getText()); > - } > - > - @Test > - public void testNestedInline() > - { > - final String content = "text {{velocity}}\n\n{{html}}$doc.fullName{{/html}}\n\n" > - + "{{/velocity}} text"; > - > - getDriver().get(getUtil().getURL("ScriptingTest", "testNestedInline", "preview", > - new HashMap<String, String>(){{put("content", content);}})); > - > - // check that the inner text is inline despite having empty lines around html > - WebElement pageContent = getDriver().findElement(By.id("xwikicontent")); > - Assert.assertEquals("Invalid content", "text ScriptingTest.testNestedInline text", pageContent.getText()); > - long numParagraphs = getDriver().findElements(By.xpath("//div[@id='xwikicontent']//p")).size(); > - Assert.assertEquals("Content is not inline", 1, numParagraphs); > - } > - > - @Test > - public void testNestedNotInline() > - { > - final String content = "text\n\n{{velocity}}{{html}}$doc.fullName{{/html}}{{/velocity}}" > - + "\n\ntext"; > - > - getDriver().get(getUtil().getURL("ScriptingTest", "testNestedNotInline", "preview", > - new HashMap<String, String>(){{put("content", content);}})); > - > - // check that inner text is not inline > - WebElement pageContent = getDriver().findElement(By.id("xwikicontent")); > - Assert.assertEquals("Invalid content", "text\nScriptingTest.testNestedNotInline\ntext", pageContent.getText()); > - long numParagraphs = getDriver().findElements(By.xpath("//div[@id='xwikicontent']//p")).size(); > - Assert.assertEquals("Invalid number of paragraphs", 3, numParagraphs); > - } > - > - @Test > - public void testNoNestedScripts() > - { > - > - final String content = "{{velocity}}\n{{html wiki=\"true\"}}" > - + "{{velocity}}\\$doc.fullName{{/velocity}}{{/html}}\n{{/velocity}}"; > - > - getDriver().get(getUtil().getURL("ScriptingTest", "testNoNestedScripts", "preview", > - new HashMap<String, String>(){{put("content", content);}})); > - > - // check that the content does not contain Test.ScriptTest anywhere > - WebElement pageContent = getDriver().findElement(By.id("xwikicontent")); > - Assert.assertFalse("The nested script was evaluated", > - pageContent.getText().contains("ScriptingTest.testNoNestedScripts")); > - > - // check that the nested script produced an error message > - WebElement error = getDriver().findElement(By.xpath("//div[@id='xwikicontent']/p/strong" > - + "/span[@class='xwikirenderingerror']")); > - Assert.assertNotNull("No error message on nested scripts", error); > - } > -} > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

15 years, 3 months

1
0
0 0

[xwiki-devs] Fwd: [ANNOUNCE] Release of Lucene Java 3.0.2 and 2.9.3

by Vincent Massol

might be interesting to us. Thanks -Vincent Begin forwarded message: > From: "Uwe Schindler" <uschindler(a)apache.org> > Date: June 18, 2010 3:50:48 PM GMT+02:00 > To: <announce(a)apache.org> > Subject: [ANNOUNCE] Release of Lucene Java 3.0.2 and 2.9.3 > > Hello Lucene users, > > On behalf of the Lucene development community I would like to announce the > release of Lucene Java versions 3.0.2 and 2.9.3: > > Both releases fix bugs in the previous versions: > > - 2.9.3 is a bugfix release for the Lucene Java 2.x series, based on Java > 1.4. > - 3.0.2 has the same bug fix level but is for the Lucene Java 3.x series, > based on Java 5. > > New users of Lucene are advised to use version 3.0.2 for new developments, > because it has a clean, type-safe API. > > Important improvements in these releases include: > - Fixed memory leaks in IndexWriter when large documents are indexed. It > also uses now shared memory pools for term vectors and stored fields. > IndexWriter now releases Fieldables and Readers on close. > - NativeFSLockFactory fixes and improvements. Release write lock if > exception occurs in IndexWriter ctors. > - FieldCacheImpl.getStringIndex() no longer throws an exception when term > count exceeds doc count. > - Improve concurrency of IndexReader, especially in the context of near > real-time readers. > - Near real-time readers, opened while addIndexes* is running, no longer > miss some segments. > - Performance improvements in ParallelMultiSearcher (3.0.2 only). > - IndexSearcher no longer throws NegativeArraySizeException if you pass > Integer.MAX_VALUE as nDocs to search methods. > > Both releases are fully compatible with the corresponding previous versions. > We strongly recommend upgrading to 2.9.3 if you are using 2.9.x; and to > 3.0.2 if you are using 3.0.x. > > See core changes at > http://lucene.apache.org/java/3_0_2/changes/Changes.html > http://lucene.apache.org/java/2_9_3/changes/Changes.html > > and contrib changes at > http://lucene.apache.org/java/3_0_2/changes/Contrib-Changes.html > http://lucene.apache.org/java/2_9_3/changes/Contrib-Changes.html > > Binary and source distributions are available at > http://www.apache.org/dyn/closer.cgi/lucene/java/ > > Lucene artifacts are also available in the Maven2 repository at > http://repo1.maven.org/maven2/org/apache/lucene/ > > ----- > Uwe Schindler > uschindler(a)apache.org > Apache Lucene PMC Member / Committer > Bremen, Germany > http://lucene.apache.org/ > > >

15 years, 3 months

1
0
0 0

[xwiki-devs] [proposal] Add support for secet token verification

by Alex Busenius

Hi, I would like to add support for secret token verification to prevent CSRF attacks (see http://jira.xwiki.org/jira/browse/XWIKI-4873). The main idea is to add a random token as a parameter to each request that requires edit/comment/admin rights and check that this token is present on the server side. Since there are many ways one can modify documents, it would require many changes all over the place, in particular: * add a public method to XWikiContext: String getSecretToken() that generates a random token and caches it in the session * add a public method to XWikiRightService*: boolean isRequestLegitimate(String action, XWikiContext context) to check if the given action is allowed to be executed * add the following API methods to Context: String getSecretToken() boolean checkSecretToken() for including the secret token into forms/AJAX requests and checking that the current request is legitimate * add a new configuration parameter core.useSecretTokenValidation for disabling this functionality, and the corresponding method useSecretTokenValidation() to CoreConfiguration and DefaultCoreConfiguration * use the secret token (hidden input for forms or parameter of GET requests) in all templates (*.vm files in web/standard and skins, velocity macros in applications/**/resources/*.xml) * check the secret token in Save/Delete/Upload/etc.-Actions and throw an exception to deny the access if the check fails * check the secret token in all templates that directly modify data (e.g. web/standard/src/main/webapp/templates/admin.vm) * fix all selenium tests that directly modify pages using the open(...) method * make sure nothing else is broken WDYT? Thanks, Alex

15 years, 3 months

6
24
0 0

[xwiki-devs] [Proposal] Add an application for common XWiki functions

by Alex Busenius

Hi devs, I propose to add a new application called "core-functionality" that would contain a collection of XWiki.* pages used by the core and some components. The use cases I can think of are: - Some functionality of the old core that used a template from web/standard/src/main/webapp/templates is replaced by a new component - A new component that is supposed to be used everywhere needs to display 1-2 custom pages (a confirmation message, warning etc.) - There are several templates in web/standard/src/main/webapp/templates that are currently used in a somewhat strange way, they are injected into other pages using xpage=template parameter. This parameter completely replaces the original page content by the content of the template (e.g. copy, create or rename page work in this way). These templates should also be slowly migrated to corresponding XWiki.* pages. I have created this application in sandbox: https://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/core-functionality It currently contains one page used by the CSRF token component I'm currently working on (https://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-csrftoken). WDYT? Alex

15 years, 3 months

2
3
0 0

[xwiki-devs] [Proposal] Create Dashboard application (extract pages from XE application)

by Vincent Massol

Hi, I think it would be best to create a new app in platform/applications called dashboard that would contain dashboard pages currently found in enterprise/wiki. I'm thinking of the following pages which are making up 2 dashboards (the main one and the alldocs one): - recent changes - dashboard - spaces - alldocs Note that a good side effect of this is that this dashboard app will automatically appear as an item in the list of features of XE on: http://enterprise.xwiki.org/xwiki/bin/view/Main/Features This makes is nice for users to see what's in XE. WDYT? Thanks -Vincent

15 years, 3 months

9
8
0 0

[xwiki-devs] Calling Email from user

by Sales, G. (Grant)

$xwiki.user.eamil = current user's email address $xwiki.getLocalUserName($doc.author) = Author's First and Last name $xwiki.getLocalUserName($doc.creator) = Creator's First and Last name How would I get the email address for a document author and or the last person that modified the document? Grant Sales Security Operations Analyst ING 20 Washington Ave South Minneapolis, MN 55401 Tel: 612.342.7889 Fax: 612.342.3428 Cell: 320.761.0966 Email: grant.sales(a)us.ing.com www.ing-usa.com ING. Your future. Made easier. (r) --------------------------------------------------------- NOTICE: The information contained in this electronic mail message is confidential and intended only for certain recipients. If you are not an intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication and any attachments is strictly prohibited. If you have received this communication in error, please notify the sender by reply transmission and delete the message without copying or disclosing it. ============================================================================================

15 years, 3 months

3
17
0 0

[xwiki-devs] [VOTE] Add apis to set current user and current wiki

by Thomas Mortagne

Hi devs, To fix http://jira.xwiki.org/jira/browse/XWIKI-5282 I can't find other way that adding the following apis: * DocumentAccessBridge#setCurrentUser (we already have DocumentAccessBridge#getCurrentUser) * ModelContext#setCurrentEntityReference (we will have to add it at some point anyway) Here is my +1 Also this imply that to fix the bug in 2.3 we need to add theses new apis in 2.3 too. I'm +1 for it too. It can't break anything. WDYT ? -- Thomas Mortagne

15 years, 3 months

3
3
0 0

[xwiki-devs] [Vote] Move the 'paste office content' feature from the import menu to the tool bar?

by Marius Dumitru Florea

Hi, Currently the Import menu of the WYSIWYG editor has two entries: * 'Office Document' for importing office files * 'Office Content (Copy / Paste)' for pasting rich text (copied usually from office documents) We had a few complains from uses that were pasting the rich text directly in the edited document causing the editor to misbehave or getting unexpected content after save. When they were told to use the 'Office Content (Copy / Paste)' entry from the Import menu they seemed surprised Ideally the editor should catch the paste event and clean the pasted rich text on the fly before it is inserted in the edited document but currently there's no clean way to do this: access to the clipboard is restricted for security reasons and the paste event is not well supported in all major browsers. I recently committed a change to the WYSIWYG editor to allow putting any of the Import menu entries on the tool bar. (1) Should we enable the 'Office Content (Copy / Paste)' button on the tool bar by default in the standard XE distribution? (2) Should we remove the 'Office Content (Copy / Paste)' entry from the Import menu? I'm +1 for (1) and -0 for (2) because the Import menu would look awkward with just one entry. Note that it's not unusual to have a feature both in the menu and in the tool bar. Thanks, Marius

15 years, 3 months

6
6
0 0

Re: [xwiki-devs] XWiki Rendering Macro not working

by Luiz Marcelo Serique

On Wed, Jun 16, 2010 at 4:56 PM, Ludovic Dubost <ludovic(a)xwiki.org> wrote: > > Hi, > > We you talking about wiki macros ? Yes, wiki macros. > Are you putting them in the same page or using the same name ? Different names but in same page. > > There is indeed only one macro per page otherwise the system would not know which macros the parameters definitions would belong to. Ok, so if i want more than one global macro, i need to create a page for each one? In any space? > > Ludovic > > Le 16/06/10 21:51, Luiz Marcelo Serique a écrit : >> >> Hi, >> >> I am writing some macros but this issue happened: >> >> The first macro written works perfectly, the second macro does not. If i >> delete the first macro the second (now the only one on list) works. >> >> Can i have just one macro per page? >> >> thks >> -- >> L. Marcelo >> _______________________________________________ >> 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 >

15 years, 3 months

2
1
0 0

[xwiki-devs] XWiki Rendering Macro not working

by Luiz Marcelo Serique

Hi, I am writing some macros but this issue happened: The first macro written works perfectly, the second macro does not. If i delete the first macro the second (now the only one on list) works. Can i have just one macro per page? thks -- L. Marcelo

15 years, 3 months

2
1
0 0

[xwiki-devs] URL's computed inside JavaScript code

by Marius Dumitru Florea

Hi, We have many places in our JavaScript code where URLs are computed from different fragments. The most common use case is appending query string parameters to an existing URL: window.docgeturl + '?xpage=xpart&vm=' + extraTemplate This code works well in servlet mode but it's almost impossible to integrate in portlet mode because portlet URLs are special http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration#HPortletURLs . You can't add parameters to a portlet URL by simply appending them to the query string. There are two scenarios (for portlet mode): (1) Either window.docgeturl is a portlet URL written on the server when the page was rendered and in this case parameters appended to the query string will be ignored (2) or window.docgeturl is a servlet URL, but we have to rewrite on the server the computed URL into a portlet URL -- impossible What if we avoid computing URLs in JavaScript code and instead get the URLs from HTML elements (e.g. anchors or forms)? <a id="commentsResourceId" href="$doc.getURL('get', '?xpage=xpart&vm=commentsinline.vm')" class="hidden">Comments</a> ... $(commentsResourceId).href I'm interested to know if this would help others too. Thanks, Marius

15 years, 3 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r29494 - in platform/core/trunk/xwiki-rendering/xwiki-rendering-macros: xwiki-rendering-macro-html/src/main/java/org/xwiki/rendering/internal/macro/html xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/internal/macro/script xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script xwiki-rendering-macro-script/src/main/resources/META-INF xwiki-rendering-macro-script/src/test/java/org/xwiki/rendering/macro/script xwiki-rendering-macro-scri

by Vincent Massol

Hi Caleb, Some reviews below. On Jun 16, 2010, at 12:03 PM, cjdelisle (SVN) wrote: > Author: cjdelisle > Date: 2010-06-16 12:03:02 +0200 (Wed, 16 Jun 2010) > New Revision: 29494 > > Added: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/internal/macro/script/DefaultScriptMacroConfiguration.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/internal/macro/script/DefaultScriptMacroUtils.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/internal/macro/script/ScriptMacroUtils.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/ScriptMacro.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/ScriptMacroConfiguration.java > Removed: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/test/resources/macroscript3.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/test/resources/macroscript5.test > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html/src/main/java/org/xwiki/rendering/internal/macro/html/HTMLMacro.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/AbstractScriptMacro.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/resources/META-INF/components.txt > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/test/java/org/xwiki/rendering/macro/script/RenderingTests.java > Log: > XWIKI-5275: Prevent nested script macros. > When script runs, looks up the dom tree to see if it's inside of the output from another script and stops. > Thanks Alex Busenius for the patch. > Reviewed and applied with some revisions. [snip] > Added: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/internal/macro/script/DefaultScriptMacroUtils.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/internal/macro/script/DefaultScriptMacroUtils.java (rev 0) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/internal/macro/script/DefaultScriptMacroUtils.java 2010-06-16 10:03:02 UTC (rev 29494) > @@ -0,0 +1,76 @@ > +/* > + * See the NOTICE file distributed with this work for additional > + * information regarding copyright ownership. > + * > + * This is free software; you can redistribute it and/or modify it > + * under the terms of the GNU Lesser General Public License as > + * published by the Free Software Foundation; either version 2.1 of > + * the License, or (at your option) any later version. > + * > + * This software is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this software; if not, write to the Free > + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > + * 02110-1301 USA, or see the FSF site: http://www.fsf.org. > + */ > +package org.xwiki.rendering.internal.macro.script; > + > +import org.xwiki.component.annotation.Component; > +import org.xwiki.component.annotation.Requirement; > +import org.xwiki.rendering.block.MacroBlock; > +import org.xwiki.rendering.block.MacroMarkerBlock; > +import org.xwiki.rendering.macro.MacroId; > +import org.xwiki.rendering.macro.MacroLookupException; > +import org.xwiki.rendering.macro.MacroManager; > +import org.xwiki.rendering.macro.script.ScriptMacro; > +import org.xwiki.rendering.macro.script.ScriptMacroConfiguration; > + > +/** > + * A collection of utility methods for script macros. > + * > + * @version $Id$ > + * @since 2.4M2 > + */ > +@Component > +public class DefaultScriptMacroUtils implements ScriptMacroUtils I really don' t like having a component with such a bad name. Utils are the opposite to good OO design IMO. And the fact that isScriptNested will return false even if the script is nested is even worse (when the config param is set to true)... > +{ > + /** Used to get a macro by id. */ > + @Requirement > + private MacroManager macroManager; > + > + /** Script macro configuration. */ > + @Requirement > + private ScriptMacroConfiguration configuration; > + > + /** > + * {@inheritDoc} > + * @see org.xwiki.rendering.internal.macro.script.ScriptMacroUtils#isScriptNested(org.xwiki.rendering.block.MacroBlock) > + */ > + public boolean isScriptNested(MacroBlock currentBlock) > + { > + if (configuration.isNestedScriptsEnabled()) { > + return false; > + } > + // traverse the XDOM tree up to the root > + MacroMarkerBlock parent = currentBlock.getParentBlockByType(MacroMarkerBlock.class); > + while (parent != null) { > + String parentId = parent.getId(); > + try { > + if (macroManager.getMacro(new MacroId(parentId)) instanceof ScriptMacro) { > + return true; > + } else if ("include".equals(parentId)) { > + // included documents intercept the chain of nested script macros with XWiki syntax > + return false; > + } > + } catch (MacroLookupException exception) { > + // shouldn't happen, the parent macro was already successfully executed earlier > + } > + parent = parent.getParentBlockByType(MacroMarkerBlock.class); > + } > + return false; > + } > +} > > > Property changes on: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/internal/macro/script/DefaultScriptMacroUtils.java > ___________________________________________________________________ > Name: svn:keywords > + Author Id Revision HeadURL > Name: svn:eol-style > + native > > Added: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/internal/macro/script/ScriptMacroUtils.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/internal/macro/script/ScriptMacroUtils.java (rev 0) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/internal/macro/script/ScriptMacroUtils.java 2010-06-16 10:03:02 UTC (rev 29494) > @@ -0,0 +1,41 @@ > +/* > + * See the NOTICE file distributed with this work for additional > + * information regarding copyright ownership. > + * > + * This is free software; you can redistribute it and/or modify it > + * under the terms of the GNU Lesser General Public License as > + * published by the Free Software Foundation; either version 2.1 of > + * the License, or (at your option) any later version. > + * > + * This software is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this software; if not, write to the Free > + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > + * 02110-1301 USA, or see the FSF site: http://www.fsf.org. > + */ > +package org.xwiki.rendering.internal.macro.script; > + > +import org.xwiki.component.annotation.ComponentRole; > +import org.xwiki.rendering.block.MacroBlock; > + > +/** > + * An internal component for accessing script macro-related utility methods. > + * > + * @version $Id$ > + * @since 2.4M2 > + */ > +@ComponentRole > +public interface ScriptMacroUtils > +{ > + /** > + * Check if the given macro block is nested inside a script macro. > + * > + * @param currentBlock the block to check > + * @return true if the block is a ancestor of a script macro block The implementation doesn't do what the javadoc says since it will return false independently of the passed blocks if the config is set to true. > + */ > + boolean isScriptNested(MacroBlock currentBlock); > +} > > > Property changes on: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/internal/macro/script/ScriptMacroUtils.java > ___________________________________________________________________ > Name: svn:keywords > + Author Id Revision HeadURL > Name: svn:eol-style > + native > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/AbstractScriptMacro.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/AbstractScriptMacro.java 2010-06-16 09:35:24 UTC (rev 29493) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/AbstractScriptMacro.java 2010-06-16 10:03:02 UTC (rev 29494) > @@ -20,7 +20,6 @@ > package org.xwiki.rendering.macro.script; > > import java.io.StringReader; > -import java.net.URLClassLoader; > import java.util.Collections; > import java.util.List; > > @@ -35,6 +34,7 @@ > import org.xwiki.rendering.block.MacroBlock; > import org.xwiki.rendering.block.XDOM; > import org.xwiki.rendering.internal.macro.script.AttachmentClassLoaderFactory; > +import org.xwiki.rendering.internal.macro.script.ScriptMacroUtils; > import org.xwiki.rendering.macro.AbstractMacro; > import org.xwiki.rendering.macro.MacroExecutionException; > import org.xwiki.rendering.macro.descriptor.ContentDescriptor; > @@ -49,8 +49,10 @@ > * @param the type of macro parameters bean. > * @version $Id$ > * @since 1.7M3 > + * @todo This class is on the edge of a fanout violation and needs to be refactored and split up. > */ > public abstract class AbstractScriptMacro extends AbstractMacro > + implements ScriptMacro > { > /** > * The default description of the script macro content. > @@ -106,6 +108,12 @@ > private ParserUtils parserUtils = new ParserUtils(); > > /** > + * Used to check for nested scripts. > + */ > + @Requirement > + private ScriptMacroUtils scriptUtils; This looks very artificial and I have the feeling it was introduced artifically because of a fanout violation. As I 've said on irc it's much better for example to introduce a generic notion of filter and implement a filter based on the logic found in DefaultScriptMacroUtils. > + > + /** > * @param macroName the name of the macro (eg "groovy") > */ > public AbstractScriptMacro(String macroName) > @@ -196,6 +204,11 @@ > try { > Thread.currentThread().setContextClassLoader(newClassLoader); > > + // 0) Abort execution if the script is nested > + if (scriptUtils.isScriptNested(context.getCurrentMacroBlock())) { > + throw new MacroExecutionException("Nested scripts are not allowed"); > + } This part can be replaced by ScriptValidator components: try { for (ScriptValidator validator : componentManager.lookupList(ScriptValidator.class)) { validator.validate(context); <-- will throw ScriptValidationException } } catch (ScriptValidationException e) { throw new MacroExecutionException("Script failed to pass validations. Reason = [" + e.getMessage() + "]", e); } > + > // 1) Run script engine on macro block content > String scriptResult = evaluate(parameters, content, context); > > @@ -238,7 +251,7 @@ > * @return the class loader to use for executing the script > * @throws Exception in case of an error in building the class loader > */ > - private URLClassLoader findClassLoader(String jarsParameterValue, ClassLoader parent) throws Exception > + private ClassLoader findClassLoader(String jarsParameterValue, ClassLoader parent) throws Exception > { > // We cache the Class Loader for improved performances and we check if the saved class loader had the same > // jar parameters value as the current execution. If not, we compute a new class loader. > > Added: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/ScriptMacro.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/ScriptMacro.java (rev 0) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/ScriptMacro.java 2010-06-16 10:03:02 UTC (rev 29494) > @@ -0,0 +1,34 @@ > +/* > + * See the NOTICE file distributed with this work for additional > + * information regarding copyright ownership. > + * > + * This is free software; you can redistribute it and/or modify it > + * under the terms of the GNU Lesser General Public License as > + * published by the Free Software Foundation; either version 2.1 of > + * the License, or (at your option) any later version. > + * > + * This software is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this software; if not, write to the Free > + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > + * 02110-1301 USA, or see the FSF site: http://www.fsf.org. > + */ > +package org.xwiki.rendering.macro.script; > + > + > +/** > + * An interface used to distinguish script macros from the rest. The most important difference > + * is that script macros cannot be nested. That's not true. It depends on the configuration param. > + * > + * @version $Id$ > + * @since 2.4M2 > + */ > +public interface ScriptMacro > +{ > + > +} > + > > > Property changes on: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/ScriptMacro.java > ___________________________________________________________________ > Name: svn:keywords > + Author Id Revision HeadURL > Name: svn:eol-style > + native > > Added: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/ScriptMacroConfiguration.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/ScriptMacroConfiguration.java (rev 0) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/ScriptMacroConfiguration.java 2010-06-16 10:03:02 UTC (rev 29494) > @@ -0,0 +1,46 @@ > +/* > + * See the NOTICE file distributed with this work for additional > + * information regarding copyright ownership. > + * > + * This is free software; you can redistribute it and/or modify it > + * under the terms of the GNU Lesser General Public License as > + * published by the Free Software Foundation; either version 2.1 of > + * the License, or (at your option) any later version. > + * > + * This software is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this software; if not, write to the Free > + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > + * 02110-1301 USA, or see the FSF site: http://www.fsf.org. > + */ > +package org.xwiki.rendering.macro.script; > + > +import org.xwiki.component.annotation.ComponentRole; > + > +/** > + * Configuration properties for the Script macro. > + * > + * You can override the default values for each of the configuration properties below by defining them in XWiki's global > + * configuration file using a prefix of "rendering.macro.script" followed by the property name. For example: > + * <code>rendering.macro.script.nestedscripts.enabled = 1</code> > + * > + * @version $Id$ > + * @since 2.4M2 > + */ > +@ComponentRole > +public interface ScriptMacroConfiguration > +{ > + /** > + * Allowing nested scripting macros, for example {{velocity}}{{groovy}}...{{/groovy}}{{/velocity}} is potentially > + * insecure, because an insufficiently escaped user data might allow script injection attacks. > + * > + * Default: 0 (disabled) What does "Default: 0 (disabled)" means? > + * > + * @return true if nested scripts are allowed > + */ > + boolean isNestedScriptsEnabled(); > +} > > > Property changes on: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/ScriptMacroConfiguration.java > ___________________________________________________________________ > Name: svn:keywords > + Author Id Revision HeadURL > Name: svn:eol-style > + native > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/resources/META-INF/components.txt > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/resources/META-INF/components.txt 2010-06-16 09:35:24 UTC (rev 29493) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/resources/META-INF/components.txt 2010-06-16 10:03:02 UTC (rev 29494) > @@ -1,2 +1,4 @@ > org.xwiki.rendering.internal.macro.script.DefaultScriptMacro > -org.xwiki.rendering.internal.macro.script.DefaultAttachmentClassLoaderFactory > \ No newline at end of file > +org.xwiki.rendering.internal.macro.script.DefaultAttachmentClassLoaderFactory > +org.xwiki.rendering.internal.macro.script.DefaultScriptMacroUtils > +org.xwiki.rendering.internal.macro.script.DefaultScriptMacroConfiguration > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/test/java/org/xwiki/rendering/macro/script/RenderingTests.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/test/java/org/xwiki/rendering/macro/script/RenderingTests.java 2010-06-16 09:35:24 UTC (rev 29493) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/test/java/org/xwiki/rendering/macro/script/RenderingTests.java 2010-06-16 10:03:02 UTC (rev 29494) > @@ -39,9 +39,7 @@ > > suite.addTestsFromResource("macroscript1", true); > suite.addTestsFromResource("macroscript2", true); > - suite.addTestsFromResource("macroscript3", true); > suite.addTestsFromResource("macroscript4", true); > - suite.addTestsFromResource("macroscript5", true); There's a whole now. Other tests should be renamed or a new test added? Why don't we test the code btw? I didn't see any tests, have I missed something? We should never commit without tests especially not in the rendering module that is well tested! :) Thanks -Vincent > > ComponentManagerTestSetup testSetup = new ComponentManagerTestSetup(suite); > new ScriptMockSetup(testSetup.getComponentManager()); > > Deleted: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/test/resources/macroscript3.test > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/test/resources/macroscript3.test 2010-06-16 09:35:24 UTC (rev 29493) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/test/resources/macroscript3.test 2010-06-16 10:03:02 UTC (rev 29494) > @@ -1,27 +0,0 @@ > -.#----------------------------------------------------- > -.input|xwiki/2.0 > -.# Validate that inner macro is transformed also > -.#----------------------------------------------------- > -{{script}} > -{{script}} > -script here > -{{/script}} > -{{/script}} > -.#----------------------------------------------------- > -.expect|event/1.0 > -.#----------------------------------------------------- > -beginDocument > -beginMacroMarkerStandalone [script] [] [{{script}} > -script here > -{{/script}}] > -beginMacroMarkerStandalone [script] [] [script here] > -beginParagraph > -onWord [script] > -onSpace > -onWord [here] > -endParagraph > -endMacroMarkerStandalone [script] [] [script here] > -endMacroMarkerStandalone [script] [] [{{script}} > -script here > -{{/script}}] > -endDocument > \ No newline at end of file > > Deleted: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/test/resources/macroscript5.test > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/test/resources/macroscript5.test 2010-06-16 09:35:24 UTC (rev 29493) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/test/resources/macroscript5.test 2010-06-16 10:03:02 UTC (rev 29494) > @@ -1,23 +0,0 @@ > -.#----------------------------------------------------- > -.input|xwiki/2.0 > -.# Validate that inner macro is inline too > -.#----------------------------------------------------- > -text {{script}}{{script}}script here{{/script}}{{/script}} text > -.#----------------------------------------------------- > -.expect|event/1.0 > -.#----------------------------------------------------- > -beginDocument > -beginParagraph > -onWord [text] > -onSpace > -beginMacroMarkerInline [script] [] [{{script}}script here{{/script}}] > -beginMacroMarkerInline [script] [] [script here] > -onWord [script] > -onSpace > -onWord [here] > -endMacroMarkerInline [script] [] [script here] > -endMacroMarkerInline [script] [] [{{script}}script here{{/script}}] > -onSpace > -onWord [text] > -endParagraph > -endDocument Thanks -Vincent

15 years, 3 months

2
2
0 0

[xwiki-devs] [Feedback][UX] Action Menus

by Ecaterina Valica

Hi, More than 6 months have passed since we introduced the new action menus <http://platform.xwiki.org/xwiki/bin/view/Features/ActionBars>(in XE 2.1). If you want to make a comparison you can look at the old menus Toucan <http://code.xwiki.org/xwiki/bin/view/Skins/ToucanSkin>skin has. It would be great to have some feedback on the way the new menus improved/messed the productivity/flow. There are lots of aspects we need to take into considerations because XWiki is used worldwide both by developers and by less experienced users. Suggestions on how we can still improve the menus are very welcomed. Thanks for participating in improving the User Experience for Open-Source projects, Caty

15 years, 3 months

3
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r29480 - platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources

by Vincent Massol

Hi Caleb, On Jun 15, 2010, at 3:27 PM, cjdelisle (SVN) wrote: > Author: cjdelisle > Date: 2010-06-15 15:27:18 +0200 (Tue, 15 Jun 2010) > New Revision: 29480 > > Modified: > platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm > Log: > XWIKI-5273: In syntax 1.0 allow changing order of renderers, set default in configuration file to execute groovy before velocity. > Make groovy be rendered before velocity by default. > > Modified: platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm > =================================================================== > --- platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm 2010-06-15 13:24:58 UTC (rev 29479) > +++ platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm 2010-06-15 13:27:18 UTC (rev 29480) > @@ -307,6 +307,11 @@ > #-# Simple wiki syntax rendering > # xwiki.render.wikiwiki=0 > > +#-# Rendering order: content will be rendered by the first renderer on the list, output rendered by the second, etc. > +#-# Default: macromapping, velocity, groovy, plugin, wiki, wikiwiki > +#-# To protect against velocity content becoming groovy code, it is recommended to leave the following line active. > +xwiki.render.renderingorder=macromapping, groovy, velocity, plugin, wiki, wikiwiki I think this line should be commented out since it's the default and thus shouldn't be needed (xwiki must work without the config file as much as possible). Thanks -Vincent > + > #-# Maximum number of documents to keep in the rendered cache > # xwiki.render.cache.capacity=100

15 years, 3 months

2
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r29480 - platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources

by Thomas Mortagne

On Tue, Jun 15, 2010 at 15:27, cjdelisle <platform-notifications(a)xwiki.org> wrote: > Author: cjdelisle > Date: 2010-06-15 15:27:18 +0200 (Tue, 15 Jun 2010) > New Revision: 29480 > > Modified: > platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm > Log: > XWIKI-5273: In syntax 1.0 allow changing order of renderers, set default in configuration file to execute groovy before velocity. > Make groovy be rendered before velocity by default. > > Modified: platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm > =================================================================== > --- platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm 2010-06-15 13:24:58 UTC (rev 29479) > +++ platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm 2010-06-15 13:27:18 UTC (rev 29480) > @@ -307,6 +307,11 @@ > #-# Simple wiki syntax rendering > # xwiki.render.wikiwiki=0 > > +#-# Rendering order: content will be rendered by the first renderer on the list, output rendered by the second, etc. > +#-# Default: macromapping, velocity, groovy, plugin, wiki, wikiwiki > +#-# To protect against velocity content becoming groovy code, it is recommended to leave the following line active. > +xwiki.render.renderingorder=macromapping, groovy, velocity, plugin, wiki, wikiwiki The parameter name (and the comment) should probably reflect more the fact that this is only about xwiki/1.0 rendering. > + > #-# Maximum number of documents to keep in the rendered cache > # xwiki.render.cache.capacity=100 > > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications > -- Thomas Mortagne

15 years, 3 months

1
0
0 0

[xwiki-devs] [Proposal] Roadmap for XE 2.4

by Vincent Massol

Hi devs, It's time for roadmap again in order to define what we want to work on for XE 2.4 (as usual this list doesn't include bugs that we have to fix). Here's a proposal that takes into account past stuff that we had planned for XE 2.3 and that haven't been done: * Work on improving performances in general (could be a cache macro, object handling improvements, etc). Any taker? * Finish xwiki-localization. Suggestion: Sergiu + Thomas * Lucene as main search engine in XE: Thomas * Fix some security issues. Sergiu + others? * Edit Mode UI Changes: JV/Sergiu/Marta * Continue the Model Reference refactoring - Vincent * Office preview - Asiri * Invitation Manager - Caleb * Rights UI improvement to make rights easy to use at last - Suggestion: Caty + Sergiu * Support for component versioning and claddloader isolation (prereq for the extension manager) - Vincent * Integration of xwiki-portlet in sandbox into the platform - Marius Nice to have: * Livetable macro - Asiri * Selective Export UI - Any taker ? * Continue work on Model. Suggestion: Vincent * Office Export - Asiri Proposed dates: * XE 2.4M1: 24 May 2010 * XE 2.4M2: 14 June 2010 * XE 2.4RC1: 28 June 2010 * XE 2.4 RC2 (if needed): 5 July 2010 * XE 2.4 Final: 12 July 2010 WDYT? Please everyone confirm if what is put next to your name is ok with you or if you have other ideas or wish to work on something else. I'll then update http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap Thanks a lot -Vincent

15 years, 3 months

6
11
0 0

[xwiki-devs] [Proposal] XWiki Portlet Integration

by Marius Dumitru Florea

Hi devs, You can find here http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration a draft regarding the portlet integration. We need to decide what's the best approach. For short term I think the loosely-coupled integration solution is the best as it requires less changes to the core. The current implementation is in http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-portlet/ and I propose to move it to platform/xwiki-portlet before 2.4M2. For long term, when we'll have the new model in place, we might consider the tightly-coupled integration solution as it seems to be more clean and it follows the component way. It won't be easy to implement though. WDYT? Thanks, Marius

15 years, 3 months

5
9
0 0

[xwiki-devs] [Proposal] Use JMX for XWiki Management + xwiki-management module in platform/core

by Vincent Massol

Hi devs, We need to introduce some ways to manage XE instances by exposing management data and operations. For example exposing the content of the xwiki caches, operation to flush them, etc. Even the ability to view/modify XWiki's configuration data at runtime. I propose to use a standard to do this: JMX. The concept is easy: - you write a MBean java bean - you register it against an MBean server Note that all containers support JMX. I've tried it with Jetty and it's enabled by default which means that you can try it by starting XWiki with jetty then open another shell and type "jconsole" (it's part of the JDK since 1.5). JConsole is a JMX console. Then go to the MBeans tab and you'll Mbeans already registered. You'll see for example the JBoss caches since JBoss Caches exposes some MBeans by default. I have written a POC already in the Velocity module to expose the velocity engines, the template namespaces and the macros registered in each template. I'm ready to commit it as a first step in the direction of using JMX. I'd also like to introduce a xwiki-management module which will contain some generic code related to JMX management. Right now I have a JMXBeanRegistration component to perform registration of XWiki MBean. That component will be used by any module wanting to register a MBean. WDYT? Thanks -Vincent

15 years, 3 months

4
5
0 0

[xwiki-devs] Build failed

by Bogdan Flueras

Hello guys, It's been a long time since I've done a build on the *platform* module. However, doing an update on this module and invoking the maven command: *mvn clean package -Pdev -Dtest=none -DfailIfNoTests=false * in the main directory (*/platform/trunks*) fails due to a typo in the *foxwiki*'s *pom.xml*. The parent pom (*tools*) has version 2.4-SNAPSHOT while the child has the 2.3-SNAPSHOT version for the parent. Fixed that. Now a hard one: Issuing the same mvn command in the *platform/trunks/core *dir fails when compiling the *XWiki Platform - Core - Annotations - REST Services* with the following error: *DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory**.* *Please find the stacktrace err message in the following link: http://pastebin.com/4zC4KPUf* * * Before posting this mail I double checked the *.m2/settings.xml* file and also did the same steps using another machine, a new checkout and an empty mvn repo, just to be sure. Still this problem persists. As XWiki has a continuous build system, perhaps I have mis-configured something and I would highly appreciate some feedback. Best regards! Ps: The problem seems to be a class cast exception due to the fact that 2 versions of xercesImpl jar are used in the project (one with compile scope,while the other with runtime scope). In the latter case, the version 2.9.1 is used and I suspect this as the root cause of the problem.

15 years, 3 months

1
0
0 0

[xwiki-devs] [proposal] Establish/Codify a best practice of putting all javascript in the <head> of the document.

by Caleb James DeLisle

I would like to see a (written) best practice of putting all javascript content into the head of the XHTML document. Reason 1: Moving all script into the head makes it easier to find and makes impossible bad (and often non WCAG compliant) practices such as attaching script to xml attributes. It makes it less of a jungle. Reason 2: If we have no script in the body of any documents then users can implement filters which remove any script after the </head> tag. This would make script injection certifiably impossible. WDYT? Caleb

15 years, 3 months

3
3
0 0

[xwiki-devs] [Proposal] How about extending EscapeTool to add XWiki 1.0 and 2.0 escaping? Re: [xwiki-users] XWiki/1.0 and XWiki/2.0 escaping

by Caleb James DeLisle

Right now $escapetool is included via velocity configuration. I don't see any reason why we couldn't change to a VelocityContextInitializer which adds an extension of escapetool which has: $escapetool.xwiki1(String) $escapetool.xwiki2(String) Although it would be cleaner I'm resistant to: $escapetool.xwiki.syntax20(String) or the like because vulnerability is easier than security so we should make security as easy (to type) as possible. I'm not sure when I'll have time to do this but I don't think it'd take more than a few hours. WDYT? Caleb Marius Dumitru Florea wrote: > On 06/13/2010 11:43 AM, Marius Dumitru Florea wrote: >> On 06/12/2010 04:26 PM, Ivan Levashew wrote: >>> Hello! >>> >>> Yet another problem I'm encountering is lack of >>> proper escaping tools. I have noticed it when I >>> decided to use [ and ] in page titles. >>> «My Recent Modifications» became broken because >>> XWiki parsed [ and ]. Currently I have added >>> {pre} and {/pre} at both ends, but it is just a >>> krunch. What is the proper way? I have checked >>> $escapetool and $xwiki.get*Encoded APIs. There is >>> no common API to escape [, ], =, {, etc. > >> You haven't checked >> http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HEscapes ;) > > This doesn't fix your problem. What about > http://platform.xwiki.org/xwiki/bin/download/DevGuide/API/xwiki-core-2.3.1-… > ? > >> Hope this helps, >> Marius >> >>> >>> _______________________________________________ >>> users mailing list >>> users(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/users >> _______________________________________________ >> users mailing list >> users(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users

15 years, 3 months

5
7
0 0

[xwiki-devs] [Vote][Proposal] Rights Management

by Ecaterina Valica

Hi, For a while we've been discussing how the new Rights Management UI is gonna look like. After 5 prototype versions, we may have reached a conclusion. Please take a look at: *Prototype* http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space *Explanations* http://incubator.myxwiki.org/xwiki/bin/view/Improvements/RightsProposal Please cast your vote if this is gonna be the final Rights representation, so that we may start the implementation. my +1 Any feedback is welcomed and we can still added improvements to this version. The current version is a collaborative work done by me, Denis Gervalle, Raluca Stavro, Alex Busenius, Roman Muntyanu and many others (Guillaume, Sergiu, Vincent, Thomas). Thanks everyone for participating in the process. Thanks, Caty p.s: former discussion about mocking process can be seen at [Proposal] Rights Management UI http://markmail.org/thread/zgzufskvhe6xt6ey

15 years, 3 months

7
17
0 0

[xwiki-devs] The Social Networking Mess: Why we need the Social Web

by Story Henry

Hi, I put a new (10 min) video together that gives an overview of why we need the Social Web based on Web IDs. http://www.yovisto.com/play/17147 This is an overview of what the point of http://webid.myxwiki.org/ is. Btw, we are now working on creating OSGI compliant libs for the java code at http://github.com/bblfish/foafssl-java Henry Social Web Architect http://bblfish.net/

15 years, 3 months

1
0
0 0

[xwiki-devs] [Proposal] Documentation Standard Document & Call to Vote

by Sorin Burjan

Hello. Silvia and me have created a DRAFT for XWiki.org Documentation Standard found at : http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiOrgDocumentationStandard In order to move towards the final version, we need your input on 2 issues. - For which project version we create & maintain documentation - Which skins we are going to support in the documentation (latest/all) Although, these issues were discussed in December 2009, no final result came out of them. http://markmail.org/message/ou7hgdiiwgayghku#query:+page:1+mid:ou7hgdiiwgay… 1. the project version (XE version for ex) for which the documentation is created/updated/maintained. We have several choices: a) We make the documentation only for the latest version. b) We make the documentation only for the latest version, and we export the pages at release time and make it available as a zipped HTML export so that people using the older version can refer to them. c) We make the doc work the last 2 releases. That would be 2.3 and 2.4. Note: If option b) is chosen then we need to add a step to the release process. (export for every release) 2. The skin used for documenting steps. This also includes the screenshots. Again we have several choices: a) Document only for the latest default skin. b) Document for all supported skins. Right now that would be Toucan + Colibri (not sure about Albatross, I don't think we've officially said it wasn't supported). Note: If option b) is chosen, this would mean 2 screenshots for the same feature (one for each skin) The vote content was mostly taken from the markmail link above. If you have any other suggestions regarding this draft, please reply and state your opinion. We need as much feedback as possible in order to create a solid documentation standard.

15 years, 3 months

4
4
0 0

Re: [xwiki-devs] [xwiki-notifications] r29399 - in platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src: main/java/org/xwiki/configuration/internal test/java/org/xwiki/configuration/internal

by Vincent Massol

On Jun 10, 2010, at 5:43 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2010-06-10 17:43:32 +0200 (Thu, 10 Jun 2010) > New Revision: 29399 > > Modified: > platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src/main/java/org/xwiki/configuration/internal/SpacePreferencesConfigurationSource.java > platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src/test/java/org/xwiki/configuration/internal/SpacePreferencesConfigurationSourceTest.java > Log: > XWIKI-5264: Cannot get the value of a property stored in the space preferences using the configuration module > Fix important regression: when using a peace of enityreference to create another one it should be cloned otherwise it's breaking the initial reference Thanks for the fix Thomas. [snip] > Modified: platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src/test/java/org/xwiki/configuration/internal/SpacePreferencesConfigurationSourceTest.java > =================================================================== > --- platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src/test/java/org/xwiki/configuration/internal/SpacePreferencesConfigurationSourceTest.java 2010-06-10 14:14:50 UTC (rev 29398) > +++ platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src/test/java/org/xwiki/configuration/internal/SpacePreferencesConfigurationSourceTest.java 2010-06-10 15:43:32 UTC (rev 29399) > @@ -55,15 +55,19 @@ > ConfigurationSource source = getComponentManager().lookup(ConfigurationSource.class, "space"); > > final DocumentReference webPreferencesReference = new DocumentReference("wiki", "space", "WebPreferences"); > + final DocumentReference currentDocument = new DocumentReference("wiki", "space", "page"); > + > mockery.checking(new Expectations() {{ > allowing(bridge).getCurrentDocumentReference(); > - will(returnValue(new DocumentReference("wiki", "space", "page"))); > + will(returnValue(currentDocument)); > oneOf(bridge).getProperty(webPreferencesReference, webPreferencesReference, "key"); > will(returnValue("value")); > }}); > > String result = source.getProperty("key", String.class); > + > Assert.assertEquals("value", result); > + Assert.assertEquals(currentDocument.getName(), currentDocument.getParent().getChild().getName()); This last line is going to be very hard to remember in the future (ie why we've written that). IMO it's not the right place for this test. If you want to keep it at least it needs to be heavily commented (but this indicates IMO that it's not the right place). Thanks -Vincent

15 years, 3 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs