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

Re: [xwiki-devs] [VOTE] "member" field of XWikiGroups objects is supposed to contains only one member (summary)

by Thomas Mortagne

3 +1 Committed in trunk On Fri, May 7, 2010 at 18:36, Thomas Mortagne <thomas.mortagne(a)xwiki.com>wrote: > Hi devs, > > I recently created http://jira.xwiki.org/jira/browse/XWIKI-5149, this > issue is due to the fact that XWikiGroupServiceImpl#listMemberForGroup > is splitting the value of the "member" field based on white space and > comma. > > That does not make sense IMO and makes impossible to have a user with > a white space (and comma which is less common) in its name for a very > bad reason. Also the name of the field is "member" and not "members". > Last reason is that i think in all other places we don't take this > value as a list. > > Note that this bug is mainly a pain for authenticators where you have > to remember the real name of the user and have some collision handling > to support use case users "somename" and "some name" coming for an > external authentication server in which theses are two different > users. > > WDYT ? > > Here is my +1. > > -- > Thomas Mortagne > -- Thomas Mortagne

15 years, 4 months

2
1
0 0

[xwiki-devs] [VOTE] "member" field of XWikiGroups objects is supposed to contains only one member

by Thomas Mortagne

Hi devs, I recently created http://jira.xwiki.org/jira/browse/XWIKI-5149, this issue is due to the fact that XWikiGroupServiceImpl#listMemberForGroup is splitting the value of the "member" field based on white space and comma. That does not make sense IMO and makes impossible to have a user with a white space (and comma which is less common) in its name for a very bad reason. Also the name of the field is "member" and not "members". Last reason is that i think in all other places we don't take this value as a list. Note that this bug is mainly a pain for authenticators where you have to remember the real name of the user and have some collision handling to support use case users "somename" and "some name" coming for an external authentication server in which theses are two different users. WDYT ? Here is my +1. -- Thomas Mortagne

15 years, 4 months

4
3
0 0

Re: [xwiki-devs] [xwiki-notifications] r28794 - platform/xwiki-applications/trunk/administration/src/main/resources/XWiki

by Sergiu Dumitriu

On 05/07/2010 10:42 PM, cjdelisle (SVN) wrote: > Author: cjdelisle > Date: 2010-05-07 22:42:06 +0200 (Fri, 07 May 2010) > New Revision: 28794 > > Modified: > platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml > Log: > XAADMINISTRATION-138: ConfigurableClass producing invalid xhtml > Fixed regression introduced in r28787 preventing saving. > > Modified: platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml > =================================================================== > --- platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml 2010-05-07 20:21:45 UTC (rev 28793) > +++ platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml 2010-05-07 20:42:06 UTC (rev 28794) > @@ -567,8 +567,8 @@ > #end > </label> > ## Have to prepend the app name to prevent id collisions. Are you sure it's always going to be _0_ ? > - $obj.display($propName, "edit").replaceAll("$objClass.getName()_0_$propName", > - "${escapedAppName}_$objClass.getName()_0_$propName") > + $obj.display($propName, "edit").replaceAll(" id='$objClass.getName()_0_$propName", > + " id='${escapedAppName}_$objClass.getName()_0_$propName") > </p> > #end## If property is in propertiesToShow > #end## Foreach property in this class > -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 4 months

3
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r28793 - platform/xwiki-applications/trunk/administration/src/main/resources/XWiki

by Sergiu Dumitriu

On 05/07/2010 10:21 PM, cjdelisle (SVN) wrote: > Author: cjdelisle > Date: 2010-05-07 22:21:45 +0200 (Fri, 07 May 2010) > New Revision: 28793 > > Modified: > platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml > Log: > XAADMINISTRATION-129: Fix save button for 'Registration> Customize XWiki.RegistrationConfig' > Javascript (which fixes buttons) now tested and working in IE7 > > Modified: platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml > =================================================================== > --- platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml 2010-05-07 18:00:43 UTC (rev 28792) > +++ platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml 2010-05-07 20:21:45 UTC (rev 28793) > @@ -222,15 +222,16 @@ > var errorShown = false; > for (var i = elementsInPage.length - 1; i> -1; i--) { > var e = elementsInPage[i]; > - if (e.tagName == 'DIV'&& e.getAttribute('class').indexOf('errormessage') != -1) > + if (e.tagName != undefined&& e.tagName.toLowerCase() == 'div'&& e.getAttribute('class') != undefined&& e.getAttribute('class').indexOf('errormessage') != -1) $(e).hasClassName('errormessage') is a better alternative, since indexOf can also match <div class="notanerrormessage"> > { > errorShown = true; > } else if (!errorShown > -&& e.tagName == 'H1' > -&& e.getAttribute('class') == 'wikigeneratedheader' > -&& e.getAttribute('id').indexOf('HCustomize') == 0) > +&& e.tagName != undefined > +&& e.tagName.toLowerCase() == 'h1' > +&& e.getAttribute('id') != undefined > +&& e.getAttribute('id').toLowerCase().indexOf('hcustomize') == 0) > { > - e.setAttribute('class', 'hidden'); > + e.parentNode.removeChild(e); $(e).remove() or $(e).hide(); You should have a look at what Prototype can offer, see http://www.prototypejs.org/api/element > errorShown = false; > } > } > @@ -239,8 +240,8 @@ > var forms = document.getElementsByTagName('form'); > var inputs = document.getElementsByTagName('input'); > for (var i = 0; i< inputs.length; i++) { > - if (inputs[i].getAttribute('type') == 'submit') { > - inputs[i].setAttribute('class', 'hidden'); > + if (inputs[i].getAttribute('type') != undefined&& inputs[i].getAttribute('type').toLowerCase() == 'submit') { > + inputs[i].parentNode.removeChild(inputs[i]); $(inputs[i]).remove(); > } > } > > @@ -302,6 +303,9 @@ > <number>0</number> > <className>XWiki.TagClass</className> > <guid>ddb1f0f6-1943-4e80-824a-0718cdbf1892</guid> > +<property> > +<tags/> > +</property> This looks like a leftover tag object which should be removed. > </object> > <content>{{velocity}} > #* -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 4 months

1
0
0 0

[xwiki-devs] Should email invitation app be a top level application? How should I add it to the sandbox?

by Caleb James DeLisle

I have a working prototype of the invitation mail sender and I would like to put it in the sandbox. I need to know how that should be done and should this be a separate top level project on jira? Some guidance here would be great. Caleb

15 years, 4 months

7
18
0 0

[xwiki-devs] [Idea] Sanity check wiki pages for admins in XE

by Vincent Massol

Hi, Right now we check pages in our functional tests (xhtml validity, no error when executing the page, no failing macro). I was wondering about the idea of having the checks done inside wiki pages so that we could provide a sanity check wiki page in the admin section for admins. Then we would use that page from our junit test and people would also be able to run it too from inside their wiki. Thus killing 2 birds with one stone I think we're lacking such kind of tools for wiki admins and it could be interesting. WDYT? Thanks -Vincent

15 years, 4 months

5
6
0 0

Re: [xwiki-devs] [Proposal] Support choosing pagination size in livetable UI

by Jerome Velociter

----- "Denis Gervalle" <dgl(a)softec.lu> wrote: > On Thu, May 6, 2010 at 15:43, Jerome Velociter <jerome(a)xwiki.com> > wrote: > > > Hi Denis, > > > > It's pretty nice. > > > > I've added an annotation on the patch > > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/LivetablePageSizer… > > > > The annotation dropped the end of my selection, it actually concerns > the > > following lines : > > > > + #if($!hasPageSize) > > + document.observe("xwiki:livetable:${divid}:loadingEntries", > function() > > { $('${divid}-pagesize').addClassName("hidden"); } ); > > + document.observe("xwiki:livetable:${divid}:loadingComplete", > > function() { $('${divid}-pagesize').removeClassName("hidden"); } ); > > + #end > > > > > Well, I do not follow. The JS is able to display one or more control, > anywhere you want. As well as it could be able to do the hiding on all such controls (LiveTablePageSizer has a references on all said domNodes) Choosing to put only one, and in the same place > then the > loading bar is just a design choice, that is the responsability of the > code > that produce the markup (the macro here). And the behavior of hiding > the > control is related. I don't see why placing it somewhere else (or having more) you would want a different behavior. In my opinion the macro should just consume the livetable JS constructor. If you need more JS code, it's probably that you need new options in the constructor (options which possibly be callback functions, not necessarly just flags/values). Finally, I think the proper behavior here would be to disable the control, instead of hidding its container. WDYT? Jerome. This is why I choose to add a additional even to > the > table, and put the observe in the macro. > > Denis > > > > Jerome. > > > > ----- Original Message ----- > > From: "Guillaume Lerouge" <guillaume(a)xwiki.com> > > To: "XWiki Developers" <devs(a)xwiki.org> > > Sent: Thursday, May 6, 2010 3:10:01 PM GMT +01:00 Amsterdam / Berlin > / Bern > > / Rome / Stockholm / Vienna > > Subject: Re: [xwiki-devs] [Proposal] Support choosing pagination > size in > > livetable UI > > > > Hi, > > > > On Thu, May 6, 2010 at 15:05, Denis Gervalle <dgl(a)softec.lu> wrote: > > > > > On Thu, May 6, 2010 at 14:55, Guillaume Lerouge > <guillaume(a)xwiki.com> > > > wrote: > > > > > > > Hi, > > > > > > > > On Thu, May 6, 2010 at 14:33, Denis Gervalle <dgl(a)softec.lu> > wrote: > > > > > > > > > Hi devs, > > > > > > > > > > Currently the number of rows displayed in a livetable is fixed > at > > > > creation > > > > > time. > > > > > I proposed to add UI controls (currently select) that allows > to > > change > > > > the > > > > > pagination size freely by the end user. > > > > > > > > > > This patch is be both a change in livetable.js to support > these > > > controls > > > > > (one or more), and a change in the livetable macro to allow > > displaying > > > > > them. > > > > > I have already a patch and some screenshots as well as bare > > > > documentation, > > > > > you can review them all at > > > > > > > > > > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/LivetablePageSizer > > > > > > > > > > I am currently testing different browsers to ensure there is > no > > > > regression. > > > > > > > > > > WDYT ? > > > > > > > > > > > > > Sounds very nice to me, I was asked about it in the past so I'm > +1. > > > > > > > > Only question -> is the preference remembered for the user? I > guess not > > > and > > > > that the default still is the number chose by the livetable > creator, > > but > > > > thought I'd ask. > > > > > > > > > > Well this is mainly a new functionality on the livetable, no > change in XE > > > in > > > my patch currently. My feeling is that keeping the information for > the > > user > > > should not be done by the livetable itself (JS), but by the caller > (the > > > macro, why not). It would not be so difficult to do with cookies, > it > > would > > > be a little bit more work to store the information in the user > profile. > > > Anyway, this is a second step. > > > > > > By the way, I have not proposed to change the current pages of XE, > but it > > > could be a nice idea. Do not hesitate to propose page you want me > to > > > improve. The other way, we may also set this new feature as a > default, so > > > it > > > will apear on all existing livetables using the macro, and allow > > disabling > > > it. WDYT ? > > > > > > > Yes, I'd make this available by default to all livetables, with a > > configuration parameter allowing to disable it on a case-by-case > basis. > > > > Guillaume > > > > > > > Denis > > > > > > -- > > > Denis Gervalle > > > SOFTEC sa - CEO > > > eGuilde sarl - CTO > > > _______________________________________________ > > > devs mailing list > > > devs(a)xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > -- > > Guillaume Lerouge > > Product Manager - XWiki SAS > > Skype: wikibc > > Twitter: glerouge > > http://guillaumelerouge.com/ > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Denis Gervalle > SOFTEC sa - CEO > eGuilde sarl - CTO > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

15 years, 4 months

2
1
0 0

[xwiki-devs] [Proposal] Support choosing pagination size in livetable UI

by Denis Gervalle

Hi devs, Currently the number of rows displayed in a livetable is fixed at creation time. I proposed to add UI controls (currently select) that allows to change the pagination size freely by the end user. This patch is be both a change in livetable.js to support these controls (one or more), and a change in the livetable macro to allow displaying them. I have already a patch and some screenshots as well as bare documentation, you can review them all at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/LivetablePageSizer I am currently testing different browsers to ensure there is no regression. WDYT ? Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

15 years, 4 months

3
5
0 0

[xwiki-devs] add custom access level

by Ibrahim hammani

Hi, How do I add a custom access levels to my xwiki. (eg : upload level, Here the user can edit the page but can't add attachments to it) . I tried to implant some solutions using groovy but i dind't succeed, so is there any other way please let me know. thanks.

15 years, 4 months

1
0
0 0

[xwiki-devs] [Proposal] Prefix the database name used as class name on the document body to avoid conflict with other classes (XWIKI-5165)

by Jerome Velociter

Hi devs, Due to special circumstances (hitting XWIKI-5166 while upgrade XWiki.org to 2.3), we've face the <body> database className conflict again, on code.xwiki.org. What happens is that the "code" DOM class name is apposed to the body element (see htmlheader.vm), and this interferes with styles defined for the {{code}} macro. Potentially there are other scenarios where class names can conflict with database names. I propose we prefix the apposed class name with "wiki-" (that's what we've been doing on xwiki.org for some time now) in order to avoid this. Though, we need to agree on this, since it can be a breaking change for those who relied on that "feature" to skin differently different wikis on a farm. WDYT ? Jerome.

15 years, 4 months

5
4
0 0

[xwiki-devs] [Proposal] Define our security requirements.

by Caleb James DeLisle

It might sound silly but if there are no security requirements then there are no security holes. We all know when we see something which shouldn't happen but I don't think there is any page defining exactly what the security requirements are. 1. Users should not be able to spawn additional processes on the server. 2. Users should not be able to commit changes to the database except through the saveDocument function. 3. Users should not be able to save documents without their name as the author or contentAuthor as applicable. 4. Guests should not be able to execute server side script except that which was written and saved by a user. This list is doesn't cover much yet, I hope to see some additions and discussion of may code may violate some the rules as well as how we can have 'untrusted' code which is unable to violate the rules. I propose we put up a design page for maintenance of this list. WDYT? Caleb

15 years, 4 months

4
5
0 0

Re: [xwiki-devs] [xwiki-notifications] r28744 - in enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui: . elements framework

by Vincent Massol

On May 5, 2010, at 7:38 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-05-05 19:38:38 +0200 (Wed, 05 May 2010) > New Revision: 28744 > > Added: > enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/EscapeTest.java > Modified: > enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/elements/FormPage.java > enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/framework/TestUtils.java > Log: > XWIKI-5161: Using XML symbols (<, >, &, ") inside the document title/name/space breaks various parts of the UI and causes the PDF export to throw exceptions > Added test. hmm shouldn't the test be more "functional"? For example, if we test the create page use case using a page with a special char, we could test this use case at the same time, no? Thanks -Vincent > Added: enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/EscapeTest.java > =================================================================== > --- enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/EscapeTest.java (rev 0) > +++ enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/EscapeTest.java 2010-05-05 17:38:38 UTC (rev 28744) > @@ -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.it.ui; > + > +import junit.framework.Assert; > + > +import org.junit.Test; > +import org.xwiki.it.ui.framework.AbstractAdminAuthenticatedTest; > +import org.xwiki.it.ui.framework.TestUtils; > + > + > +/** > + * Test various character escaping bugs. > + * > + * @version $Id$ > + * @since 2.4M1 > + */ > +public class EscapeTest extends AbstractAdminAuthenticatedTest { > + > + @Test > + public void testEditReflectedXSS() > + { > + // tests for XWIKI-4758, XML symbols should be escaped > + String page = "<>'?&\""; > + TestUtils.gotoPage("Main", TestUtils.escapeURL(page), "edit", getDriver()); > + Assert.assertTrue(getDriver().getPageSource().indexOf(page) < 0); > + } > +} > + > > > Property changes on: enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/EscapeTest.java > ___________________________________________________________________ > Name: svn:keywords > + Author Id Revision HeadURL > Name: svn:eol-style > + native > > Modified: enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/elements/FormPage.java > =================================================================== > --- enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/elements/FormPage.java 2010-05-05 16:17:06 UTC (rev 28743) > +++ enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/elements/FormPage.java 2010-05-05 17:38:38 UTC (rev 28744) > @@ -31,7 +31,7 @@ > /** > * Represents a Form. > * > - * @version $Id:$ > + * @version $Id$ > * @since 2.4M1 > */ > public class FormPage extends BasePage > > Modified: enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/framework/TestUtils.java > =================================================================== > --- enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/framework/TestUtils.java 2010-05-05 16:17:06 UTC (rev 28743) > +++ enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/framework/TestUtils.java 2010-05-05 17:38:38 UTC (rev 28744) > @@ -41,7 +41,7 @@ > > public static void gotoPage(String space, String page, String action, WebDriver driver) > { > - gotoPage(space, page, "view", null, driver); > + gotoPage(space, page, action, null, driver); > } > > public static void gotoPage(String space, String page, String action, String queryString, WebDriver driver)

15 years, 4 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r28709 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/xwiki

by Vincent Massol

On May 4, 2010, at 10:50 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-05-04 22:50:34 +0200 (Tue, 04 May 2010) > New Revision: 28709 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/xwiki/MyPersistentLoginManager.java > Log: > XWIKI-5156: Session cookies are not marked as HttpOnly > Fixed > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/xwiki/MyPersistentLoginManager.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/xwiki/MyPersistentLoginManager.java 2010-05-04 20:50:00 UTC (rev 28708) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/xwiki/MyPersistentLoginManager.java 2010-05-04 20:50:34 UTC (rev 28709) > @@ -245,7 +245,31 @@ > LOG.debug("Adding cookie: " + cookie.getDomain() + cookie.getPath() + " " + cookie.getName() + "=" > + cookie.getValue()); > } > - response.addCookie(cookie); > + // We don't use the container's response.addCookie, since the HttpOnly cookie flag was introduced only recently > + // in the servlet specification, and we're still using the older 2.4 specification as a minimal requirement for > + // compatibility with as many containers as possible. Instead, we write the cookie manually as a HTTP header. AFAIK addCookie is avail in the the 2.3 spec: http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpSer… Thanks -Vincent > + StringBuilder cookieValue = new StringBuilder(150); > + cookieValue.append(cookie.getName() + "="); > + if (StringUtils.isNotEmpty(cookie.getValue())) { > + cookieValue.append("\"" + cookie.getValue() + "\""); > + } > + cookieValue.append("; Version=1"); > + if (cookie.getMaxAge() >= 0) { > + cookieValue.append("; Max-Age=" + cookie.getMaxAge()); > + } else { > + cookieValue.append("; Discard"); > + } > + if (StringUtils.isNotEmpty(cookie.getDomain())) { > + // IE needs toLowerCase for the domain name > + cookieValue.append("; Domain=" + cookie.getDomain().toLowerCase()); > + } > + if (StringUtils.isNotEmpty(cookie.getPath())) { > + cookieValue.append("; Path=" + cookie.getPath()); > + } > + // Protect cookies from being used from JavaScript, see http://www.owasp.org/index.php/HttpOnly > + cookieValue.append("; HttpOnly"); > + > + response.addHeader("Set-Cookie", cookieValue.toString()); > } > > /**

15 years, 4 months

2
3
0 0

Re: [xwiki-devs] Curriki 1.8.5 - Local Installation - Pom configuration error

by Jerome Velociter

Release tags should not refer to SNAPSHOT dependencies. It seems the tag has not been made with maven tag plugin. Either you can "fix" the tag by changing the dependency to a non-SNAPSHOT version (like 24), or try to build the trunk which should refer to more recent deps (i.e., that still exists in the maven repo). Regards, Jerome. -- View this message in context: http://xwiki.475771.n2.nabble.com/Curriki-1-8-5-Local-Installation-Pom-conf… Sent from the XWiki- Dev mailing list archive at Nabble.com.

15 years, 4 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r28726 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/templates

by Sergiu Dumitriu

On 05/05/2010 02:28 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2010-05-05 14:28:17 +0200 (Wed, 05 May 2010) > New Revision: 28726 > > Modified: > platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/templates/commentsinline.vm > platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/templates/informationinline.vm > Log: > [misc] Fix XHTML validity > > Modified: platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/templates/commentsinline.vm > =================================================================== > --- platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/templates/commentsinline.vm 2010-05-05 12:27:21 UTC (rev 28725) > +++ platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/templates/commentsinline.vm 2010-05-05 12:28:17 UTC (rev 28726) > @@ -90,7 +90,7 @@ > #foreach($name in $request.getParameterNames()) > #set($queryString = "$!queryString&$name=$escapetool.url($request.get($name))") > #end > - $response.sendRedirect("$doc.getURL('view')?captchaAnswerWrong=1&$queryString"); > + $response.sendRedirect("$doc.getURL('view', "captchaAnswerWrong=1&$queryString")"); Are you sure this works? Looks like nested quotes which makes Velocity a bit unhappy... Also the & is still unescaped. $response.sendRedirect($doc.getURL('view', "captchaAnswerWrong=1&$queryString")); > #end > $response.setContentLength(0) > #stop -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 4 months

2
2
0 0

Re: [xwiki-devs] SVN Application for XWiki

by Denis Gervalle

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

15 years, 4 months

4
10
0 0

[xwiki-devs] [Proposal] Fix inconsistencies in access to the change password feature

by Denis Gervalle

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

15 years, 4 months

3
3
0 0

[xwiki-devs] xwiki-core-xmlrpc-client-2.1.1.jar

by Vivian Richard

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…

15 years, 4 months

3
2
0 0

[xwiki-devs] SVN Application for XWiki

by Ludovic Dubost

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

15 years, 4 months

4
5
0 0

[xwiki-devs] [VOTE] Commit Search application

by Thomas Mortagne

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

15 years, 4 months

8
8
0 0

[xwiki-devs] [Proposal] Merge dev:Drafts.SecuringXWiki with platform:AdminGuide.Security

by Caleb James DeLisle

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

15 years, 4 months

5
4
0 0

[xwiki-devs] What browsers do we officially support?

by Caleb James DeLisle

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

15 years, 4 months

5
7
0 0

[xwiki-devs] Fwd: [ANNOUNCE] Velocity Engine 1.7-beta1 release available

by Vincent Massol

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. :)

15 years, 4 months

3
5
0 0

Re: [xwiki-devs] [xwiki-notifications] r28664 - platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table

by Sergiu Dumitriu

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/

15 years, 4 months

2
2
0 0

[xwiki-devs] [Security Advisory] SQL injection issue.

by Caleb James DeLisle

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

15 years, 4 months

1
0
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