June 2010 - xwiki-devs@xwiki.org

Re: [xwiki-devs] [xwiki-notifications] r29596 - platform/web/trunk/standard/src/main/webapp/resources/js/prototype
by Vincent Massol 21 Jun '10

21 Jun '10

On Jun 21, 2010, at 10:24 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-06-21 10:24:46 +0200 (Mon, 21 Jun 2010) > New Revision: 29596 > > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/prototype/prototype.js > Log: > XWIKI-4183: Improve page load speeds via parallel JavaScript download > Fixed most race condition failures occuring in IE > > Modified: platform/web/trunk/standard/src/main/webapp/resources/js/prototype/prototype.js > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/resources/js/prototype/prototype.js 2010-06-21 08:24:35 UTC (rev 29595) > +++ platform/web/trunk/standard/src/main/webapp/resources/js/prototype/prototype.js 2010-06-21 08:24:46 UTC (rev 29596) > @@ -4687,8 +4687,11 @@ > document.addEventListener('DOMContentLoaded', fireContentLoadedEvent, false); > } else { > document.observe('readystatechange', checkReadyState); > + // Disabled in XWiki since it conflicts with defered scripts > + /* > if (window == top) > timer = pollDoScroll.defer(); > + */ So we'll loose this change (ie we'll have to remember it) when we upgrade to a new version of prototype? Thanks -Vincent

3 3

Re: [xwiki-devs] Gadgets & Dashboard roadmap
by Jerome Velociter 21 Jun '10

21 Jun '10

----- "Anca Luca" <lucaa(a)xwiki.com> wrote: > Hi all, > > I am now restarting the work on the gadgets & dashboard project, > documented here > http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration (however > > documentation needs to be slightly revised). > > What is done already can be summarized as: > * gadgets are implemented as macros and there is a script to import > google gadgets as xwiki macros, > * also, right now, gadgets are implemented as xwiki macros and can be > > used anywhere just like a regular wiki macro, and any wiki macro can > be > seen/used as a gadget so **there is no difference between macros and > gadgets** . WDYT about this? should we keep it like that? (A) If I understand correctly, it means XWiki will not be an OpenSocial container, but will provide a "conversion" layer to make OpenSocial gadgets work with the XWiki gadget (= macros) system. I'm not sure it's the proper approach. It will not encourage developers of XWiki application / macros etc. to write their gadgets as OpenSocial gadgets, since writing XWiki macros will be enough (so it will not be possible to display a XWiki gadget in say JIRA). Plus, if we make XWiki an OpenSocial container, it does not prevent us from writing a generic XWiki gadget that can wrap any macro thus not adding too much weight on developers. Jerome. > * there is a dashboard macro responsible with layouting a gadgets > dashboard, which also provides specific editing features in inline > mode > (gadgets can be dragged around, toolboxes for gadgets in the top > right) > * there is a minimal macros directory, where one can see all the > existing macros, descriptions, details about the parameters. > * there is an PanelMacro macro, that displays an xwiki panel inside a > > document, which can be used to display xwiki panels as gadgets in a > dashboard. > > The big picture of the roadmap is that we should: > > 1/ have a fully working dashboard, that is implement add gadget and > edit > gadget settings > 2/ implement the main dashboard (Main.Dashboard) as a dashboard and > fill > it with the appropriate gadgets by default, and also to add a user > specific dashboard ("My dashboard") where each user can configure > his/her dashboard, and is available to a user from his / her profile > or > the user menu > 3/ have a nice macros directory where a user can navigate through > existing gadgets and add one to a dashboard > 4/ have a "dashboard template", integrated with the document templates > > system to easily allow a user to create a dashboard > 5/ also, since the xwiki panels can be seen as gadgets / macros, and > can > be implemented as such, somewhere in the future a refactoring should > be > made to integrate the 2 notions > 6/ be able to publish the gadgets in the wiki such that other apps can > > integrate this in their content > > WDYT about the order above? (B) with the mention that points 5 and 6 > could eventually be infinitely postponed. > > Also, after points 1 and 2 are implemented, the feature could be > available with xwiki platform and integrated in XE by default. WDYT? > (C) > > my +1 for (A), (B) and (C). > > Happy hacking, > Anca > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

1 0

[xwiki-devs] [Proposal] Changing the RightService API
by Andreas Jonsson 21 Jun '10

21 Jun '10

I will make two proposals for changing the RightService API: The first does not actually change any code, but it is a preparation for future changes. I want to be sure that the methods checkAccess and hasAccessLevel aren't used interchangeably; it should be well defined when to use one or the other. The second proposal is a complete rework of the API, which might be a bit further into the future. 1. Change the semantics of hasAccessLevel slightly. Currently the method hasAccessLevel is defined as: /** * Verifies if the user identified by {@code username} has the * access level identified by {@code right} on the document with * the name {@code docname}. I would like to make a change the describing text into: /** * Decides whether the access level given by {@code right} should * be granted during rendering of the document identified by * {@code docname} by request of the user identified by {@code * username}. In other words, the rights queried for is tied to the thread executing a request on behalf of the user. In contrast, the checkAccess method queries for the configured rights of a particular user. This suggests that the underlying implementation may choose to base its decision on more things than the given user and document, and thus opens up for more possibilities to change the security policy. For instance, hasAccessLevel("programming", context.getUser(), docname, context) could be made equivalent to hasProgrammingRights(context.getWiki().getDocument(docname), context) In the current implementation, XWikiRightServiceImpl, the methods checkAccess and hasAccessLevel can be used interchangeably once the user have been authenticated. But it seems that the current usage pattern more or less matches the above change in semantics already. 2. Deprecate all methods in the current API and introduce the following new ones: boolean checkAccess(String action, EntityReference entity); boolean userHasRight(DocumentReference userIdentity, Right right, EntityReference entity); boolean hasAccessLevel(Right right); Iterable<Right> getEnabledRights(EntityType entityType); The differences are: 1. The context parameter is dropped. The right service can have an Execution instance injected instead. 2. No exceptions are thrown. Instead, on error, log and deny access. 3. Identify users by the DocumentReference of their profile page. 4. Introduction of the enum 'Right'. 5. The rights are controlled against entities identified by EntityReferences that may be of type WIKI, SPACE or DOCUMENT. 6. Add a new method, userHasRight, for querying for the specific rights of a given user on a given entity, where the entity may be wiki, space or document. This method replaces the method hasAdminRights. I guess this method will be primarily used by the user interface. 7. hasAccessLevel have the same change in semantics as mentioned above, and could thus replace the hasProgrammingRights methods. In other words, hasAccessLevel provides the answer to the question "should access for an operation that requires the specified right be granted given the current context?" Within the lifecycle of a request, first a call should be made to checkAccess to authenticate the user and to grant access to the specific action. Subsequent security checkpoinst should normally use hasAccessLevel. 8. The listAllLevels-method is moved to the Right enum class. The right service could instead provide a method that lists what rights are enabled at a particular level in the document hierarchy, i.e., the getEnabledRights method, which I guess is relevant for the rights manager. So, what do you think? Best regards, Andreas Jonsson

2 2

[xwiki-devs] [Proposal] Why don't we use XWQL and the Query Manager + ScriptService
by Vincent Massol 21 Jun '10

21 Jun '10

Hi devs, I'm wondering why we haven't moved to using XQL instead of HQL. Any reason? If not, I'd like to suggest we start using it everywhere we currently use HQL since XWQL since is much nicer. Also since we don't use it our users don't use it. Additionally I'd like to propose that we move to a ScriptService to access the query manager. From Velocity you'd write the following to get a Query: $services.query.xwql("....") Note that the ScriptService implementation would replace the SecureQueryManager implementation. We would also deprecate XWiki.getQueryManager. WDYT? Thanks -Vincent

5 11

Re: [xwiki-devs] [xwiki-notifications] r29588 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web
by Vincent Massol 21 Jun '10

21 Jun '10

On Jun 21, 2010, at 9:28 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-06-21 09:28:46 +0200 (Mon, 21 Jun 2010) > New Revision: 29588 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/Utils.java > Log: > [cleanup] Updated deprecated method call > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/Utils.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/Utils.java 2010-06-21 07:28:40 UTC (rev 29587) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/Utils.java 2010-06-21 07:28:46 UTC (rev 29588) > @@ -65,8 +65,8 @@ > Utils.class.getCanonicalName() + "_placeholders_enabled"; > > /** > - * The component manager used by {@link #getComponent(Class)} and {@link #getComponent(Class, String)}. It is > - * useful for any non component code that need to initialize/access components. > + * The component manager used by {@link #getComponent(Class)} and {@link #getComponent(Class, String)}. It is useful > + * for any non component code that need to initialize/access components. > */ > private static ComponentManager componentManager; > > @@ -150,7 +150,7 @@ > // the content is fully rendered. The rendering code can use Utils.createPlaceholder. > // Initialize the placeholder map > enablePlaceholders(context); > - String content; > + String content = ""; > try { > content = context.getWiki().evaluateTemplate(template + ".vm", context); > // Replace all placeholders with the protected values > @@ -163,8 +163,12 @@ > } > > // get Error template "This template does not exist > - content = context.getWiki().parseTemplate("templatedoesnotexist.vm", context); > - content = content.trim(); > + try { > + content = context.getWiki().evaluateTemplate("templatedoesnotexist.vm", context); > + content = content.trim(); > + } catch (IOException ex) { > + // Cannot write output, can't do anything else Shouldn't we log a warning/error? Thanks -Vincent

2 2

Re: [xwiki-devs] [xwiki-users] Templates Provider
by Guillaume Lerouge 21 Jun '10

21 Jun '10

Hi, On Mon, Jun 21, 2010 at 10:04, Adriana Escamilla Alvarado < adriana.escamilla.alvarado(a)gmail.com> wrote: > Hello guys, I want to tell u first that all of XWiki is awesome °¬° (and > the developers too =D ) > > But, I need to know when you (you mean XWiki org) are going to liberate > the XEnterprise 2.4M2, I need... really I need the Templates Pages =( > this is the URL if u doest'n know what I mean > http://code.xwiki.org/xwiki/bin/view/Applications/AdministrationApplication > in the sub-section "Easy Templates Creation and Administration (Starting > with XWiki Enterprise 2.4M2)" ... > > Maybe I'm wrong and this is a User-Application maybe not, but I want to > know if this "templates" are going to be in the Milestone 2, if not, > then tell me if that "Templates" are a User-Application (and if u can > tell me how to make it please =( ) > Templates are already available for testing. You can get a snapshot of the release here: http://maven.xwiki.org/snapshots/com/xpn/xwiki/products/xwiki-enterprise-we… Guillaume Also, I have a little problem with the Import of Documents in > OpenOfficeServer, I tried to set up a OOffice in a Linux Server, but i > cant to make it a service D=!!! I was looking for a tip of "How to make > OpenOffice a Service in Linux" and what i found doesnt work =(. My > server details are: > > - SO: OpenSuse 10, Server > - XWiki: Enterprise 2.3 > - OpenOffice: 3.2 > > If someone can help me please with this 2 Issues I'll be really happy. > Thank you for your time!!!! > > Adriana Escamilla Alvarado > Ing. Tecnologías Computacionales > Particular: (614) 260-0732 > Móvil: (614) 219-7213 > Contact Me Facebook > <http://www.facebook.com/#%21/adriana.escamilla.alvarado>Twitter > <http://twitter.com/Ing_Patito> > > --- @ WiseStamp Signature > < > http://my.wisestamp.com/link?u=6qp9k36s775m7jfq&site=www.wisestamp.com/emai… > >. > Get it now > < > http://my.wisestamp.com/link?u=6qp9k36s775m7jfq&site=www.wisestamp.com/emai… > > > > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users

1 0

[xwiki-devs] Support skin inheritence for file system skin
by Ludovic Dubost 19 Jun '10

19 Jun '10

Hi, I believe we need to implement skin inheritence for file system skins. We do have skin inheritence for skins stored in Wiki pages but we don't have it for FS skins. So we cannot have albatross <-> colibri <-> myskin <-> wiki page skin To implement this we could just use a file called "parent" which would contain the name of the parent skin. WDYT ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

2 1

Re: [xwiki-devs] [xwiki-notifications] r29564 - enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui
by Vincent Massol 18 Jun '10

18 Jun '10

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

1 0

[xwiki-devs] Fwd: [ANNOUNCE] Release of Lucene Java 3.0.2 and 2.9.3
by Vincent Massol 18 Jun '10

18 Jun '10

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/ > > >

1 0

[xwiki-devs] [proposal] Add support for secet token verification
by Alex Busenius 18 Jun '10

18 Jun '10

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

6 24