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

[xwiki-devs] Access to the security mailing list

by Alex Busenius

Hello devs, I'd like to have access to the security mailing list :) Thanks, Alex

15 years, 3 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r29043 - in platform: core/trunk/xwiki-core core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/xwiki core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web web/trunk/standard/src/main/webapp/WEB-INF

by Vincent Massol

Hi Asiri, Some comments below. On May 28, 2010, at 1:03 PM, asiri (SVN) wrote: > Author: asiri > Date: 2010-05-28 13:03:53 +0200 (Fri, 28 May 2010) > New Revision: 29043 > > Added: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/TempResourceAction.java > Modified: > platform/core/trunk/xwiki-core/pom.xml > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/xwiki/XWikiRightServiceImpl.java > platform/web/trunk/standard/src/main/webapp/WEB-INF/struts-config.xml > Log: > XWIKI-5227: Introduce a temp resource action. > > * Applying patch after review, refer http://jira.xwiki.org/jira/browse/XWIKI-5227 for more details. > > > Modified: platform/core/trunk/xwiki-core/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-core/pom.xml 2010-05-28 09:34:16 UTC (rev 29042) > +++ platform/core/trunk/xwiki-core/pom.xml 2010-05-28 11:03:53 UTC (rev 29043) > @@ -257,6 +257,13 @@ > <groupId>commons-beanutils</groupId> > <artifactId>commons-beanutils</artifactId> > </dependency> > + > +  > + <dependency> > + <groupId>org.apache.tika</groupId> > + <artifactId>tika-core</artifactId> > + <version>0.7</version> > + </dependency> > >  > <dependency> > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/xwiki/XWikiRightServiceImpl.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/xwiki/XWikiRightServiceImpl.java 2010-05-28 09:34:16 UTC (rev 29042) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/xwiki/XWikiRightServiceImpl.java 2010-05-28 11:03:53 UTC (rev 29043) > @@ -137,6 +137,7 @@ > actionMap.put("jsx", "view"); > actionMap.put("ssx", "view"); > actionMap.put("tex", "view"); > + actionMap.put("temp", "view"); why "temp" and not "tmp"? > actionMap.put("unknown", "view"); > } > > > Added: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/TempResourceAction.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/TempResourceAction.java (rev 0) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/TempResourceAction.java 2010-05-28 11:03:53 UTC (rev 29043) > @@ -0,0 +1,128 @@ > +/* > + * 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 com.xpn.xwiki.web; > + > +import java.io.File; > +import java.io.IOException; > +import java.net.URI; > +import java.util.regex.Matcher; > +import java.util.regex.Pattern; > + > +import org.apache.commons.io.FileUtils; > +import org.apache.commons.io.IOUtils; > +import org.apache.commons.logging.Log; > +import org.apache.commons.logging.LogFactory; > +import org.apache.tika.Tika; > +import org.apache.tika.mime.MimeTypes; > +import org.xwiki.container.Container; > + > +import com.xpn.xwiki.XWikiContext; > +import com.xpn.xwiki.XWikiException; > + > +/** > + * Action responsible for downloading temporary resources created by various modules. Refer JIRA issue: > + * <a>http://jira.xwiki.org/jira/browse/XWIKI-5227</a>. > + * > + * @version $Id$ > + * @since 2.4M1 > + */ > +public class TempResourceAction extends XWikiAction > +{ > + /** > + * URI pattern for this action. > + */ > + public static final Pattern URI_PATTERN = Pattern.compile(".*?/temp/([^/]*+)/([^/]*+)/([^/]*+)/(.*+)"); > + > + /** > + * Logging support. > + */ > + private static final Log LOG = LogFactory.getLog(TempResourceAction.class); > + > + /** > + * Used for detecting mime-types of files. > + */ > + private Tika tika = new Tika(); > + > + /** > + * Used to resolve temporary working dir. > + */ > + private Container container = Utils.getComponent(Container.class); > + > + /** > + * {@inheritDoc} > + */ > + public String render(XWikiContext context) throws XWikiException > + { > + XWikiRequest request = context.getRequest(); > + XWikiResponse response = context.getResponse(); > + String uri = request.getRequestURI(); > + > + // Locate the temporary file. > + File tempFile = getTempFile(uri); Using File is not recommended IMO. Couldn't you use a URL instead? > + if (null == tempFile) { > + throw new XWikiException(XWikiException.MODULE_XWIKI_APP, XWikiException.ERROR_XWIKI_APP_URL_EXCEPTION, > + "Invalid temporary resource URL"); > + } > + > + // Write temporary file into response. > + response.setDateHeader("Last-Modified", tempFile.lastModified()); > + String contentType = MimeTypes.OCTET_STREAM; > + try { > + contentType = tika.detect(tempFile); > + } catch (IOException ex) { > + LOG.warn(String.format("Unable to determine mime type for temporary resource [%s]", tempFile > + .getAbsolutePath()), ex); > + } > + response.setContentType(contentType); > + try { > + response.setContentLength((int) tempFile.length()); > + IOUtils.copy(FileUtils.openInputStream(tempFile), response.getOutputStream()); This is very bad for performance. You should stream the content instead. > + } catch (IOException e) { > + throw new XWikiException(XWikiException.MODULE_XWIKI_APP, > + XWikiException.ERROR_XWIKI_APP_SEND_RESPONSE_EXCEPTION, "Exception while sending response", e); > + } > + return null; > + } > + > + /** > + * Returns the temporary file corresponding to the specified URI. > + * > + * @param uri request URI. > + * @return temporary file corresponding to the specified URI or null if no such file can be located. > + */ > + private File getTempFile(String uri) I'd prefer a more explicit name such as getTemporaryFile() > + { > + Matcher matcher = URI_PATTERN.matcher(uri); > + File result = null; > + if (matcher.find()) { > + String space = matcher.group(1); > + String page = matcher.group(2); > + String module = matcher.group(3); > + String filePath = matcher.group(4); > + String prefix = String.format("temp/%s/%s/%s/", module, space, page); > + String path = URI.create(prefix + filePath).normalize().toString(); > + if (path.startsWith(prefix)) { > + result = new File(container.getApplicationContext().getTemporaryDirectory(), path); > + result = result.exists() ? result : null; > + } You should use the xwiki-url module to extract information from the URL IMO. It's much more complicated than what is written above. See code in xwiki-url for details. > + } > + return result; > + } > +} > > Modified: platform/web/trunk/standard/src/main/webapp/WEB-INF/struts-config.xml > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/WEB-INF/struts-config.xml 2010-05-28 09:34:16 UTC (rev 29042) > +++ platform/web/trunk/standard/src/main/webapp/WEB-INF/struts-config.xml 2010-05-28 11:03:53 UTC (rev 29043) > @@ -257,6 +257,11 @@ > name="download" > scope="request"> > </action> > + <action path="/temp/" > + type="com.xpn.xwiki.web.TempResourceAction" > + name="temp" > + scope="request"> > + </action> > <action path="/downloadrev/" > type="com.xpn.xwiki.web.DownloadRevAction" > name="dowloadrev" Thanks -Vincent

15 years, 3 months

2
3
0 0

[xwiki-devs] [vote] livetable select field default value should say 'All' and not 'none'

by Ludovic Dubost

Hi, I've created bug http://jira.xwiki.org/jira/browse/XWIKI-5229 because the livetable select field default value is not translatable and is not using a good term (as noticed by some heavy livetable users). I would like to propose we use "All" instead of "none" Here is my +1 Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

15 years, 3 months

6
6
0 0

[xwiki-devs] Xwiki/Jabber chat integration

by Khelifa BOUMAZA

Hi; I try to implement basic jabber chat based on · EJABBERD ( Jabber/XMPP instant messaging server) · JSJAC class ( jabber/XMPP client library written in JavaScript) · and XWIKI I confront two major problems · how to synchronize jabber users with Xwiki users · how get user chat status within xwiki page using velocity or groovy Any suggestions thx logoNearbee_CMJN BOUMAZA Khelifa Développeur WEB 15 rue Jean-Baptiste Berlier 75013 PARIS Tél :01.55.43.76.90 Fax : 01 55 43 76 96 <http://www.nearbee.com/> http://www.nearbee.com

15 years, 3 months

3
2
0 0

[xwiki-devs] xwiki and social web screencast

by Story Henry

Hi, I put together a very short screen cast that shows how xwiki can be used on the social web. http://www.youtube.com/watch?v=8iZPJBpI2Po Certainly there can be improvements. For example one can't log into xwiki the way shown in the video yet. Henry Social Web Architect http://bblfish.net/

15 years, 4 months

1
0
0 0

[xwiki-devs] [Proposal] Allow to provide document templates on document creation

by Jean-Vincent Drean

Hi XWikiers, I've been working on the ability to provide document templates on document creation lately. It's documented on dev.xwiki.org: http://dev.xwiki.org/xwiki/bin/view/Drafts/DocumentTemplates Implementation: - New "create" xwiki action - Templates: create.vm, createinline.vm (for inline and ajax uses) - Modification in the xwiki-core-rendering-xwiki core module so that it gets the correct action (create) for broken links - New XClass: XWiki.TemplateProviderClass (with associated sheet and template), this class allow to build the list of template entries to display in the create document form. - New administration section: Templates. Allows to list existing template providers and to create new ones. I'm almost ready to commit (I only need one more day to write functional tests) and I'd really like to do it after the 2.4M1 release. WDYT ? JIRA: http://jira.xwiki.org/jira/browse/XE-672 JV.

15 years, 4 months

8
15
0 0

[xwiki-devs] Introduce new tempresource action

by Vincent Massol

Hi, Part I ===== I've started implementing a Ditaa Macro over the weekend (http://ditaa.sourceforge.net/ ) but we need an Action to return the Ditaa-generated image file. For the chart macro we're using the charting action but I think we can make this generic and instead introduce a tmp (or temp or tmpresource or ...) action instead that would return any resource located in the xwiki temporary directory. For ex: /xwiki/bin/tmp/SomeResource would return SomeResource found in container.getApplicationContext().getTemporaryDirectory(). Part II ===== The only thing to be careful about is to not be able to read what's for another user and for which you don't have access to see it. For example an image generated by the chart macro for a page for which the user doesn't have view rights. This can be partially solved by ensuring that file names include a generated token. However the pb is that this token cannot be unique since, for ex, generated image need to be shared to anyone having the rights to view a page. <brainstomring mode> A solution I see would be to include the "rights" to check + the full page name in the URL, in addition to the resource. For example: /xwiki/bin/tmp/view/wiki:Space.Page/SomeResource A more generic solution would be to add a notion of Check Handler, i.e. code that would perform the check. For example in the previous solution it's not possible to check for 2 permissions, nor any complex scheme. This would mean something like: /xwiki/bin/tmp/<check handler name>/<resource name>?<check params> Ex: /xwiki/bin/tmp/simple/SomeResource? checkPermission="view"&checkDocument="wiki:Space.Page" Implementation: A component with a role hint of "simple" would be looked-up and the check logic delegated to it. However someone could use a some check for a resource that wasn't meant to be used for that resource. Thus the check and its params should probably instead be included in the resource name with some algorithm instead. Thus the solution maybe to have a high level API to create a resource name and that API would take a Check Handler hint + some arbitrary params and that API would generate a resource name with these added. For ex something like:: "SomeResource-simple-view-wiki:Space.Page" (or any other format). Another solution would be to follow a completely different direction and for example to introduce a new XDOM representation for a TMP- image, i.e. in addition to URLImage and DocumentImage, to add a TemporaryImage implementation. </brainstomring mode> WDYT about these 2 ideas and especially about Part I since I would need that sooner rather than later to implement the Ditaa macro, and Part II is already a problem today. Thanks -Vincent

15 years, 4 months

7
16
0 0

[xwiki-devs] On Security

by Andreas Jonsson

The work on the new right manager user interface looks very promising. Good work! But I also think that the underlying security model must urgently be revised. Although I must say that I love the idea that the users can write their own applications on top of XWiki, the current security just doesn't support this. When executing a script, who should be held accountable for the actions are taken by the script? In traditional operating systems, a user is expected to know and trust the programs that he or she chooses to run. Considering how much problems there are with "viruses" I'd say that this security model works badly in traditional environments. But in a wiki, scripts are executed at any page load. A user who casually browse the wiki cannot know when and what scripts are executed. Thus, it is a complete disaster to use a security model where the users are held accountable for whatever actions the script is doing. For instance, to take over a wiki that is open for anonymous commenting, just post a script that sits and waits for a user with admin or programming rights to view the page. How can the security model be fixed? There are two roles that should be considered involved in the execution of a script: user and programmer. Both the programmer and the user should be held accountable for whatever actions are taken by the script, but neither trust the other. The programmer says "go ahead and run this script, but you wont be able to do anything that you don't already have rights to". The user says "sure, I'll go ahead and run your script, but I don't give you any rights that you don't already have." Hence, a script should be executed with the intersection of the rights that the two roles possess. But it should be possible for a programmer that have carefully sanitized the user input to lend his or hers full privileges to the user. It should also be possible for users to indicate that they have reviewed a script and indicate that they trust a certain scripts or that they trust some programmer. In other words, the users should be able to lend their full rights to a particular script or to scripts written by a trusted programmer, when executed by the user. What about contents that is generated by a script? If the user who runs a script becomes the programmer of any scripts that are generated and saved, we have just added one level of indirection for attackers: An anonymous commenter could post a script that waits for an administrator. This script should in turn post a script (whos programmer would then be the administrator) that waits for an administrator. Since both user and programmer should be held accountable for the actions taken by a script, it might be reasonable that they are also both credited for any contents generated by the script. Thus both the user and the programmer could be considered "the programmer" for any new scripts generated by a script. But this might be unnecessarily complex. Instead, a distninction could be made on documents that is "saved with a programmer set" and those that are not. When rendering a document that does not have a programmer, all rights should be denied for scripts in the document. Saving a document with yourself as "the programmer" must not be allowed without first prompting the user for a confirmation, where the user must input a password. This to prevent attacks where the user is tricked into saving content with to the programmer set. How can this be implemented in XWiki? A document has a "creator", which is the person who saved the first revision of the document and each revision of the document has an "author", which is the person who saved the revision. We have to extend the document format to support a "programmer". "The user" is of course the logged in user that requests the page. The user is authenticated the ordinary way and both programmer (if any) and user is noted in the context. Thereafter any rights check is made by checking if both user and programmer has the right. If there is no programmer, all right checks should return "deny", except maybe for the "view"-right that should be checked against the user to allow the include macro without saving with a programmer. (But this opens up for an attack where page content which aren't viewable by everyone can be extracted, so maybe not. It could be a configurable option.) Obviously, it is important that comments to a page are not rendered with a programmer set. This will make it impossible to execute privileged scripts in comments. I don't think that is a useful feature, anyway. This will also require some additional user interaction. The default should be to not set any programmer when saving a document, and this will of course not require anything special from the user. But when saving a page, it should be possible to select "save with me set to the programmer". If the user chooses this option, she will be forwarded to a confirmation page "You are about to save this content with you set to the programmer. Please confirm by entering your save password." It should also be possible to select "save with me as programmer and lend my rights to users executing scripts in this page", whereupon the confirmation page should be marked with a big warning sign and contain a harsh lecture on sanitizing user input. It might be a good idea to introduce a special "save setuid" right that the user must have in order to at all be allowed to do this. A user that have programming rights should additionally have the option to set the programmer to an arbitrary user. A setuid script should, of course, have a programmer with as little privileges as possible. A set of dummy users with varying privileges could be prepared for this purpose. In order to allow saving documents with "the programmer" set in bulk (for instance in the import application), there should also be a confirmation page for allowing "saving with programmer set" throughout a request. Is this sufficient? Maybe. We have at least made it a lot harder for attackers, because now they must trick a privileged user to confirm a "save with myself as programmer". If the same password is used for saving pages as for logging in, this can be accomplished by spoofing a login-page. Thus, there should be a separate "save password" which must differ from the ordinary login password. It might even be possible to allow users to save javascript extensions. But there should at least be a configurable option to demand programming rights for this. Javascripts opens up many attack paths. Tasks: 1. Add "programmer" attribute to document. 2. Add "execute scripts with the programmers privilege (setuid)"-flag to document. 3. Change the RightService to: 1. if a programmer is not set, deny everything except "view", which (as a configurable wiki option) can be checked only for the user (to allow using the include macro without saving with a programmer), 2. check rights only for the programmer, if the setuid-flag is set, 3. check rights only for user, if the programmer is "trusted" or the user "trusts" the document, 4. check rights for both user and programmer, otherwise. Although the current right service implementation can be kludged into supporting this, it really needs to be rewritten from scratch, both for clarity and speed. The special treatment when the document author happens to have programming rights must be removed. How to determine if a programmer or the document is "trusted" is an open question, but I guess that users with programming or admin rights, at least, can be considered trusted. 4. Add "save password" to the user profile, which must be set to a non-empty string that differs from the login password for the user to be allowed to "save with myself as programmer" or "save setuid". 5. Add user interface controls for saving a page with programmer set. 6. Add confirmation page for confirming "save with myself as programmer". 7. Add user interface controls and confirmation page for "save setuid". 8. Add wiki-option to demand programming rights for saving javascript extensions. 9. Fix all applications that undoubtly will be broken by this change. Do you other people agree with me when I say that the security model must be replaced immediately? What do you think about my suggestion? Please, poke at it to try to find any attacks that I have not thought of. I have started on a new right service implementation with a cacheing front-end. I'll create a new module under core which I'll call 'xwiki-security' and move the right service to the new architecture while I'm at it. Best regards, Andreas Jonsson

15 years, 4 months

3
5
0 0

Re: [xwiki-devs] On Security

by Jerome Velociter

----- "Andreas Jonsson" <aj(a)member.fsf.org> wrote: > The work on the new right manager user interface looks very > promising. > Good work! > > But I also think that the underlying security model must urgently be > revised. > > Although I must say that I love the idea that the users can write > their own applications on top of XWiki, the current security just > doesn't support this. > > When executing a script, who should be held accountable for the > actions are taken by the script? > > In traditional operating systems, a user is expected to know and > trust > the programs that he or she chooses to run. Considering how much > problems there are with "viruses" I'd say that this security model > works badly in traditional environments. > > But in a wiki, scripts are executed at any page load. A user who > casually browse the wiki cannot know when and what scripts are > executed. Thus, it is a complete disaster to use a security model > where the users are held accountable for whatever actions the script > is doing. > > For instance, to take over a wiki that is open for anonymous > commenting, just post a script that sits and waits for a user with > admin or programming rights to view the page. > > How can the security model be fixed? > > There are two roles that should be considered involved in the > execution of a script: user and programmer. Both the programmer and > the user should be held accountable for whatever actions are taken by > the script, but neither trust the other. The programmer says "go > ahead and run this script, but you wont be able to do anything that > you don't already have rights to". The user says "sure, I'll go > ahead > and run your script, but I don't give you any rights that you don't > already have." > > Hence, a script should be executed with the intersection of the > rights that the two roles possess. > > But it should be possible for a programmer that have carefully > sanitized the user input to lend his or hers full privileges to the > user. > > It should also be possible for users to indicate that they have > reviewed a script and indicate that they trust a certain scripts or > that they trust some programmer. In other words, the users should be > able to lend their full rights to a particular script or to scripts > written by a trusted programmer, when executed by the user. > > What about contents that is generated by a script? > > If the user who runs a script becomes the programmer of any scripts > that are generated and saved, we have just added one level of > indirection for attackers: An anonymous commenter could post a script > that waits for an administrator. This script should in turn post a > script (whos programmer would then be the administrator) that waits > for an administrator. > > Since both user and programmer should be held accountable for the > actions taken by a script, it might be reasonable that they are also > both credited for any contents generated by the script. Thus both > the > user and the programmer could be considered "the programmer" for any > new scripts generated by a script. But this might be unnecessarily > complex. > > Instead, a distninction could be made on documents that is "saved > with a programmer set" and those that are not. When rendering a > document > that does not have a programmer, all rights should be denied for > scripts in the document. Saving a document with yourself as "the > programmer" must not be allowed without first prompting the user for > a > confirmation, where the user must input a password. This to prevent > attacks where the user is tricked into saving content with to the > programmer set. > > How can this be implemented in XWiki? > > A document has a "creator", which is the person who saved the first > revision of the document and each revision of the document has an > "author", which is the person who saved the revision. We have to > extend the document format to support a "programmer". > > "The user" is of course the logged in user that requests the page. > The user is authenticated the ordinary way and both programmer (if > any) and user is noted in the context. Thereafter any rights check > is > made by checking if both user and programmer has the right. If there > is no programmer, all right checks should return "deny", except maybe > for the "view"-right that should be checked against the user to allow > the include macro without saving with a programmer. (But this opens > up for an attack where page content which aren't viewable by everyone > can be extracted, so maybe not. It could be a configurable option.) > > Obviously, it is important that comments to a page are not rendered > with a programmer set. This will make it impossible to execute > privileged scripts in comments. I don't think that is a useful > feature, anyway. > > This will also require some additional user interaction. The default > should be to not set any programmer when saving a document, and this > will of course not require anything special from the user. > > But when saving a page, it should be possible to select "save with me > set to the programmer". If the user chooses this option, she will be > forwarded to a confirmation page "You are about to save this content > with you set to the programmer. Please confirm by entering your save > password." > > It should also be possible to select "save with me as programmer and > lend my rights to users executing scripts in this page", whereupon > the > confirmation page should be marked with a big warning sign and > contain > a harsh lecture on sanitizing user input. It might be a good idea to > introduce a special "save setuid" right that the user must have in > order to at all be allowed to do this. A user that have programming > rights should additionally have the option to set the programmer to > an > arbitrary user. A setuid script should, of course, have a programmer > with as little privileges as possible. A set of dummy users with > varying privileges could be prepared for this purpose. > > In order to allow saving documents with "the programmer" set in bulk > (for instance in the import application), there should also be a > confirmation page for allowing "saving with programmer set" > throughout > a request. > > Is this sufficient? > > Maybe. We have at least made it a lot harder for attackers, because > now they must trick a privileged user to confirm a "save with myself > as programmer". If the same password is used for saving pages as for > logging in, this can be accomplished by spoofing a login-page. Thus, > there should be a separate "save password" which must differ from the > ordinary login password. > > It might even be possible to allow users to save javascript > extensions. But there should at least be a configurable option to > demand programming rights for this. Javascripts opens up many > attack paths. > > Tasks: > > 1. Add "programmer" attribute to document. It could be a 'XWiki.ProgramClass' object (to be discussed) > > 2. Add "execute scripts with the programmers privilege (setuid)"-flag > to document. Same, could be a property of said object > > 3. Change the RightService to: > > 1. if a programmer is not set, deny everything except "view", > which > (as a configurable wiki option) can be checked only for the > user > (to allow using the include macro without saving with a > programmer), > > 2. check rights only for the programmer, if the setuid-flag is > set, > > 3. check rights only for user, if the programmer is "trusted" or > the user "trusts" the document, > > 4. check rights for both user and programmer, otherwise. > > Although the current right service implementation can be kludged > into supporting this, it really needs to be rewritten from > scratch, > both for clarity and speed. > > The special treatment when the document author happens to have > programming rights must be removed. > > How to determine if a programmer or the document is "trusted" is > an > open question, but I guess that users with programming or admin > rights, at least, can be considered trusted. > > 4. Add "save password" to the user profile, which must be set to a > non-empty string that differs from the login password for the > user > to be allowed to "save with myself as programmer" or "save > setuid". > > 5. Add user interface controls for saving a page with programmer set. > > 6. Add confirmation page for confirming "save with myself as > programmer". > > 7. Add user interface controls and confirmation page for "save > setuid". > > 8. Add wiki-option to demand programming rights for saving javascript > extensions. FYI it's already the case of "always-use" extensions. (Same for CSS extensions) > > 9. Fix all applications that undoubtly will be broken by this change. The changes listed here are not really backward compatible, so it will be a necessary way anyway, in order to have an application that make use of the programming right in a working state with a new security model. > > Do you other people agree with me when I say that the security model > must be replaced immediately? What do you think about my suggestion? > Please, poke at it to try to find any attacks that I have not > thought of. I'm very +1 to fix the programming right immediately (by that I mean for programmers to declare a page that require to be executed with the programming right). For the rest of the proposal, I have to think more about it before I make my mind. Anyway I think we can improve the security model incrementally - of course the sooner the better. > > I have started on a new right service implementation with a > cacheing front-end. I'll create a new module under core which I'll > call 'xwiki-security' and move the right service to the new > architecture while I'm at it. That's great. Don't hesitate to commit it early in the sandbox so that everyone can look at it. Jerome. > > > Best regards, > > Andreas Jonsson > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

15 years, 4 months

1
0
0 0

Re: [xwiki-devs] [VOTE] Automatically add scope attribute in generated table header cells in XHTML renderer (summary)

by Thomas Mortagne

7 +1, committing now See http://jira.xwiki.org/jira/browse/XWIKI-5222 On Tue, May 25, 2010 at 14:31, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: > Hi dev, > > For Dutch Web Guidelines validity a <th> have to contains scope > attribute (scope="col" or scope="row") which means that default wiki > tables are invalid currently. > > See http://www.w3.org/TR/xhtml2/mod-tables.html#non-visual-rendering > for example of scope attribute use. > > I propose to modify XHTML renderer table header cell to do the following: > * if a scope is explicitly provided reuse it > * if there is no scope: > ** if first line or not first column: <th scope="col"> > ** if not first line and first column: <th scope="row"> > > I thing that covers most of the use cases and it will avoid having to > set explicitly scope attribute in all our standard pages. > > WDYT ? > > -- > Thomas Mortagne > -- Thomas Mortagne

15 years, 4 months

1
0
0 0

[xwiki-devs] [Proposal] Remove old attributes*.vm templates

by Alex Busenius

Hello devs, I propose to remove the following templates: web/standard/src/main/webapp/templates/attributes.vm web/standard/src/main/webapp/templates/attributesinline.vm They are not used any more (replaced by the "Information" tab), are still in 1.0 syntax, are not internationalized (the only one used translation is missing) and they also have some security issues. Alex

15 years, 4 months

6
7
0 0

[xwiki-devs] [VOTE] Automatically add scope attribute in generated table header cells in XHTML renderer

by Thomas Mortagne

Hi dev, For Dutch Web Guidelines validity a <th> have to contains scope attribute (scope="col" or scope="row") which means that default wiki tables are invalid currently. See http://www.w3.org/TR/xhtml2/mod-tables.html#non-visual-rendering for example of scope attribute use. I propose to modify XHTML renderer table header cell to do the following: * if a scope is explicitly provided reuse it * if there is no scope: ** if first line or not first column: <th scope="col"> ** if not first line and first column: <th scope="row"> I thing that covers most of the use cases and it will avoid having to set explicitly scope attribute in all our standard pages. WDYT ? -- Thomas Mortagne

15 years, 4 months

7
9
0 0

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

by Sergiu Dumitriu

On 05/25/2010 11:20 AM, dgervalle (SVN) wrote: > Author: dgervalle > Date: 2010-05-25 11:20:42 +0200 (Tue, 25 May 2010) > New Revision: 28991 > > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.css > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.js > platform/web/trunk/standard/src/main/webapp/templates/macros.vm > Log: > XWIKI-5219 - Improve livetable markup for better accessibility compliance > > Modified: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.css > =================================================================== > -.xwiki-livetable-pagination span.pagenumber { > +.xwiki-livetable-pagination a.pagenumber { For more flexibility, this could become just .xwiki-livetable-pagination .pagenumber -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 4 months

2
1
0 0

[xwiki-devs] [VOTE] Improve accessibility of livetables pagination

by Denis Gervalle

Hi devs, Even if ajax based stuff will never fully comply with accessibility requirements, I would like to improve a little bit the livetable pagination markup so it gets closer to these requirements. Currently, the pagination feature use <span> for numbers, and also use empty <span> with a background image for previous/next page buttons. Both of these practice produce very poor interface once the css is disabled. I attach a patch that improve the situation by using <a> in place of <span>, so that links are properly identified when css is not used or with a screen readers. Using CSS, the behavior and the design is unchanged. Here is my +1 to apply this ASAP on trunk. Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

15 years, 4 months

2
4
0 0

[xwiki-devs] OSGi manifest data for our core modules

by Vincent Massol

Hi devs, I'd like to add OSGi manifest data generation for our core modules during our build. This would be the first step in allowing xwiki modules to be used in an osgi environment (whether it's by us later on or by external users who want to use the xwiki rendering for example). WDYT? Thanks -Vincent

15 years, 4 months

6
6
0 0

[xwiki-devs] Need tempresource support to integrate office-preview

by Asiri Rathnayake

Hello Devs, I've been looking at integrating office-preview module into our main source but I'm really not happy with how presentation preview support is currently implemented, its a load of hacks (btw, its myself who coded it that way). When a presentation office document is imported, it generates a bunch of html files (slides) and a set of images. I need a way to group these artifacts into a single temporary directory and link from the wiki page into the main slice (html page). This is not possible without something like tempresource action and currently I use charting action with a lot of hacks (and only image slides are supported). Is anyone working on tempresource action? Can I work on it? Thanks. - Asiri

15 years, 4 months

2
1
0 0

[xwiki-devs] Programmatically Login

by Luiz Marcelo Serique

Hi, I'm new on list, and new on xwiki too, we have successfully deployed the XWiki Enterprise 2.3 in our company, but there is some pre requisites that we must accomplish to integrate the system to our SSO aplication. The SSO is a very simple aplication that stores all users and groups on a independent database, the SSO system have a interface that shows, like a catalog, all the internal systems that a specific person (logged in person) has access. The archictecture is very simple, and almost time insecure, passing by GET parameter the credentials to other systems in php, java, python, etc..., but this is another point that we here have to discuss and adjust adjust. To provide this SSO to xwiki i was wondering create a Filter that verify those GET parameters and programmatically authenticates the user to XWiki and use the MyFormAuthenticator.authenticate() to perform the login. But here come the question, the authenticate method needs a XWikiContext object, is it possible to have this context in a Servlet Filter? And you guys have some suggestions about my strategy? Any alternative to what i want achieve? -- L. Marcelo

15 years, 4 months

3
5
0 0

Re: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table

by Vincent Massol

On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote: > Author: dgervalle > Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010) > New Revision: 28950 > > Modified: > platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js > Log: > XWIKI-5212 - Livetable filter serialization does not properly support multi-valued form elements > Merge from trunk r28947 Do we have a test for this? How do we unit-test UI components? Thanks -Vincent > Modified: platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js > =================================================================== > --- platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js 2010-05-20 17:11:02 UTC (rev 28949) > +++ platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js 2010-05-20 17:15:53 UTC (rev 28950) > @@ -609,11 +609,12 @@ > for (var i = 0; i < this.inputs.length; ++i) { > var key = this.inputs[i].name; > if ((this.inputs[i].type == "radio") || (this.inputs[i].type == "checkbox")) { > - if (this.filters[key]) { > - if (this.filters[key] == this.inputs[i].value.strip()) { > - this.inputs[i].checked = true; > + var filter = this.filters[key]; > + if (filter) { > + if (Object.isArray(filter)) { > + this.inputs[i].checked = (filter.indexOf(this.inputs[i].value.strip()) != -1); > } else { > - this.inputs[i].checked = false; > + this.inputs[i].checked = (filter == this.inputs[i].value.strip()); > } > } > } else { > @@ -624,14 +625,14 @@ > } > > for (var i = 0; i < this.selects.length; ++i) { > - if (!this.filters[this.selects[i].name]) { > - continue; > - } > - for (var j = 0; j < this.selects[i].options.length; ++j) { > - if (this.selects[i].options[j].value == this.filters[this.selects[i].name]) { > - this.selects[i].options[j].selected = true; > - } else { > - this.selects[i].options[j].selected = false; > + var filter = this.filters[this.selects[i].name]; > + if (filter) { > + for (var j = 0; j < this.selects[i].options.length; ++j) { > + if (Object.isArray(filter)) { > + this.selects[i].options[j].selected = (filter.indexOf(this.selects[i].options[j].value) != -1); > + } else { > + this.selects[i].options[j].selected = (this.selects[i].options[j].value == filter); > + } > } > } > } > @@ -649,7 +650,7 @@ > // Ignore filters with blank value > if (!filters[i].value.blank()) { > if ((filters[i].type != "radio" && filters[i].type != "checkbox") || filters[i].checked) { > - result += ("&" + filters[i].name + "=" + encodeURIComponent(filters[i].value)); > + result += ("&" + filters[i].serialize()); > } > } > }

15 years, 4 months

3
9
0 0

[xwiki-devs] New search admin UI and icon

by Thomas Mortagne

Hi devs, I committed the new search admin UI and fixed some issuse, should work well now. Some notes: * the actual configuration is put in a document automatically created if it does not exist so that you can upgrade the whole app without having to worry about what you will overwrite * it's using Configurable system but just to be "injected" as admin app, would be nice to be able to have some reusable code when you need custom UI but still we some standard configuration style in the middle of it * there is a new central search page (Main.Search) which include the proper engine search page depending of the configuration Missing things are: * an nice icon: would be cool to have someone else than me on that * rename "web" into "database", i just moved the page yet but "web" is not very nice and i need to change it. I'm just a bit worried about backward compatibility, i think i will create a DatabaseSearch page and redirect WebSearch to Search probably to make old apps use the right default search engine instead of the old hardcoded websearch default page * make number of indexing element refresh automatically using ajax: i'm working on something else right and it's not urgent but i will take care of it (I'm not begging for it if someone want to take it ;)) * write documentation for it in xwiki.org (especially about how to use indexing UI), about that do we have some clean way to put documentation tooltips or something nice to explain to the use what he can put in the fields and how it's working ? Would be cool that some people review it (pretty sure there is typos I did not seen, there is always...). Thanks, -- Thomas Mortagne

15 years, 4 months

5
12
0 0

Re: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table

by Jerome Velociter

----- "Denis Gervalle" <dgl(a)softec.lu> wrote: > On Thu, May 20, 2010 at 19:23, Vincent Massol <vincent(a)massol.net> > wrote: > > > > > On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote: > > > > > Author: dgervalle > > > Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010) > > > New Revision: 28950 > > > > > > Modified: > > > > > > platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js > > > Log: > > > XWIKI-5212 - Livetable filter serialization does not properly > support > > multi-valued form elements > > > Merge from trunk r28947 > > > > Do we have a test for this? How do we unit-test UI components? > > > > This would be nice to have. Building proper tests is not so easy, this > could > be very long to setup, since you need to test in several browsers and > you > need full AJAX interaction. That's basically what we do with Selenium, except that we test the integration of the features in the wiki, not the atomic behaviors of the components. There isn't really an alternative to launching a browser for testing our JS components, since most if not all of them heavily rely on a DOM, so just a JS runtime will not be enough. We could envisage a JS unit-testing system like this : - Write tests in .js files, using JSUnit or any other unit testing JS framework (http://ejohn.org/blog/which-unit-testing-framework/) - Slurp the tests in a XAR using a maven plugin - Execute the tests inside XE, using Selenium wdyt ? Jerome. > I am not used to such automated testing, > but I > am not sure the investment is worse the improvement we could get from > them. > > On the other side, I use livetables JS heavily, so you could be > assured that > my fixes/improvements are either well tested or will be fixed ASAP > since all > changes I introduce is already in production. We also usually test > them on > all supported browsers, and at least on IE6/7/8, FF3 (Win/Mac), > Safari4 > (Mac) and Chrome (Mac) > FYI, I found this one when we have introduced the usage of hashes to > provide > "Back to the list" links. I will soon commit an improvement supporting > the > page size in hash as well, so you can really get very precise "back to > the > list" return links. > > Denis > > Thanks > > -Vincent > > > > > -- > 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

3
2
0 0

[xwiki-devs] 答复: Embed xwiki to existing project

by 靳雄飞

XWiki support XMP-RPC and REST, So I am wondering if one can integrate third-party-app with XWiki through XML-RPC. That is, use XWiki as a page store/search/versioning platform, and third-party-app response for page editing and display. If there's a easy way to embed XWiki's editor and render engine into my application, the integration work will be very easy I think. I'm not sure if this can be achieved, I am studying. > >Hi... Good to know there are people with common interest in embedding xwiki >to existing project. > >Here is my confusion. Please comment if you have idea on this. >I have my J2EE project. It uses JSF, Spring and Hibernate. So I have my own >hibernate.cfg.xml and web.xml and other config files. >Now, I'm trying to add xwiki as a module to my project. Since Xwiki uses >Struts and Hibernate, it also has its own hibernate.cfg.xml and web.xml >files. >How do I integrate these two now? >Can I have both of these in my project and move on? > >If I am able to work it out, I think I can move forward. I just learnt the >way how we can delegate the struts action management to the spring >framework. > >Regards, >Manish >-- >View this message in context: http://xwiki.475771.n2.nabble.com/Embed-xwiki-to-existing-project-tp5070278p 5081734.html >Sent from the XWiki- Dev mailing list archive at Nabble.com. >_______________________________________________ >devs mailing list >devs(a)xwiki.org >http://lists.xwiki.org/mailman/listinfo/devs

15 years, 4 months

2
1
0 0

[xwiki-devs] Extension Manager - First Objective

by Vincent Massol

Hi devs, Just to keep you abreast, Thomas and I are working on the following use case POC fpr midle of next week (hopefully): - Ability to install the JRuby macro from our XWiki Remote repo in a running XE (note that installing this macro is interesting since it has dependencies on another artifact (jruby)). For this we'll develop: - A xwiki-extension-manager module (in sandbox for now). The code will use Maven classes underneath to download the jruby macro + its dependencies to a local repo - A xwiki-extension-manager application XAR (in sandbox for now). It'll be supra simple UI with just a text field where to specify the groupId + artifactId + version - We'll also update the xwiki-classloader module to allow unloading of JARs from a URL Classloader. Thanks -Vincent

15 years, 4 months

1
0
0 0

[xwiki-devs] [Discussion] OSGi POC result and base for the Extension Manager

by Vincent Massol

Hi devs, I've explored enough of OSGi to get a handle of how it works and what it would mean to use it for XWiki as the basis for our Extension Manager (Thomas helped me with this too). The executive summary is that I don't think we need to use OSGi right now for the Extension Manager and we can defer its usage for later. Let me start by listing what would OSGi bring for XWiki: 1) Known framework with good documentation, books, etc 2) Users would be able to write extensions using OSGi programming model (without using XWiki's programming model), this also means the ability to reuse OSGi bundles inside XWiki 3) ClassLoader isolation and thus ability to have several versions of classes 4) OBR (Bundle Repository) for downloading and installing remote jars Now here are the problems found with OSGi so far: A) Impedance mismatch with the webapp/WAR model (classloader and visibility issues). Two examples: - it would mean having a special directory somewhere, where to put the bundles, and this means not going through the standard WAR deployment process. - if we want to keep WEB-INF/lib in order to have a standard WAR deployment then it would mean keeping for ex the core jars in WEB-INF/lib and using OSGi only for extensions. However doing this is not really possible since it would mean extension (OSGi bundles) would have Imports on core classes but this won't work since core classes won't be OSGi bundles B) In practice it's very hard to use OSGi with only a part of the modules being OSGi bundles and another part being standard external libraries. Everything must be OSGified for it to work well. In addition we might want not need the features listed above: 1) Not really needed especially since we have the XWiki programming model that we don't want to loose right now 2) is a nice to have but not a requirement for the Extension Manager 3) in practice it's going to be very hard to support multiple versions of classes. Imagine for example an application A which is providing a macro in a wiki page. Application B requires version 1.0 of A and application C requires version 2.0 of A. How do we support that? OSGi won't help here since this is about wiki pages. It's only helping for jars. The jar isolation could also easily be implemented using a custom URL classloader without too much problem IMO, but I'm inclined to say that we don't need to support multiple versions in a first version of the Extension Manager. 4) We can easily use the Maven 3 Embedder to download and install maven artifacts into a local repository. This is convenient since we already deploy our applications/modules to a maven repository. Note that the only "difficult" part here might be searching into a remote repository; I don't know if a maven api exists for this (but probably). In the worst of cases we could use the Nexus REST API to provide this feature for now. And here's what I think we should do right now: i) focus on the 2 features we need for the Extension Manager: -- ability to install an application containing not only wiki pages but also jars -- ability to install an application from a remote repository ii) then once i) is done focus on the upgrade part of the extension manager Implementation note: - To implement i) we can do this easily I believe using a custom URL ClassLoader (we already have one btw used in the script macro) that we pass to the Component Annotation Loader when a new JAR is installed (in order to register the components in that jar) + set that custom URL ClassLoader as the new thread context classloader (for code that would use the thread context classloader to load classes). WDYT? Thanks -Vincent PS: I'd be interested to hear from OSGi experts what they have to say about this since I'm an OSGi newbie and there might be stuff I have not seen/realized. PPS: I'm just realizing that the proposal in this mail is close to Pomegranate's idea: http://www.caucho.com/projects/pomegranate/

15 years, 4 months

4
10
0 0

[xwiki-devs] YourKit Java Profiler 9.0 Released

by Vincent Massol

See http://bit.ly/b1iPgf Note that all xwiki committers have a Yourkit license key available to them on dev.xwiki.org (tools page). Thanks -Vincent

15 years, 4 months

2
2
0 0

[xwiki-devs] Fwd: [ANNOUNCE] Apache VelocityTools 2.0 release

by Vincent Massol

Possible candidate for upgrade in XWiki too. Thanks -Vincent Begin forwarded message: > From: Nathan Bubna <nbubna(a)apache.org> > Date: May 19, 2010 2:56:21 AM GMT+02:00 > To: Velocity Users List <user(a)velocity.apache.org>, Velocity Developers List <dev(a)velocity.apache.org>, private <private(a)velocity.apache.org>, announce(a)apache.org > Subject: [ANNOUNCE] Apache VelocityTools 2.0 release > > The Apache Velocity project is pleased to announce the release of > VelocityTools 2.0. > > Downloads are available here: > http://velocity.apache.org/download.cgi > > This should be useable as a drop in replacement for Tools 2.0-beta4 or > Tools 1.4, with a few minor exceptions. The 2.x series of > VelocityTools requires Velocity 1.5+ and JDK 1.5+. > > For those new to Tools 2, here's an overview of the work done since 1.4: > * More convention over configuration and smart defaults > * New configuration formats (more concise/flexible/powerful xml, > properties, java) > * Provision of default and auto-loaded configurations > * Entirely new core infrastructure (lazy-loading tools, easier > access, standalone support etc) > * Added VelocityViewTag for JSP integration > * Added DisplayTool, ConversionTool, ClassTool, LoopTool, > FieldTool, a generic version of LinkTool and more > * Refactored and enhanced a number of existing tools > * Improved documentation > * Deprecated many outdated things > * Legacy support for almost all Tools 1.4 configurations and extensions > * Better integration of $application, $session and $request scope > control objects > * and lots more... > > For those following the betas, here's the notable changes since 2.0-beta4: > * Added a 'readOnly' config option to allow write operations on > ValueParser and ParameterTool (when set to false) > * Added a beta-quality UiDependencyTool (included in > velocity-view, but not in default tools.xml) > * Added an alpha-quality MarkupTool (included in generic tools, > but not in default tools.xml) > * Fixed (as much as possible) some significant last-iteration > LoopTool problems, and added a $loop.this property to serve as a more > reliable workaround in nested loops. See > https://issues.apache.org/jira/browse/VELTOOLS-124 > * VelocityLayoutServlet now checks request attributes for > non-default layouts. > * The velocity-view.tld is now valid. > * VelocityView[Servlet] has improved exception and http management > (particularly for ResourceNotFoundExceptions). > * Miscellaneous documentation and build.xml improvements > > The Velocity developers are very interested in all feedback regarding > Tools 2.0, especially regarding backwards compatibility with apps > designed for Tools 1.4 or earlier. We aim to enable a smooth, > incremental transition for developers and their applications.

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