Hi devs,
I'm going to continue Asiri's work on integrating officepreview module (
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-officepreview/
) into the main source tree. Following the discussion at
http://xwiki.475771.n2.nabble.com/Discussion-Integrating-officepreview-modu…
here are the steps that need to be taken:
* Extend DocumentAccessBridge with a method to get the current version
of an attachment in order to drop the dependency on xwiki-core:
String getAttachmentVersion(AttachmentReference attachmentReference)
* Convert OfficePreviewVelocityBridge to a ScriptService:
$services.officepreview.preview($attachmentReference, $filterStyles)
* Move /contrib/sandbox/xwiki-officepreview/ to
/platform/core/xwiki-officepreview
* Publish the office preview wiki macro on code.xwiki.org
* Integrate office preview in the UI (e.g. button/link to preview, next
to download links in the attachments tab)
Let me know if you don't agree with some of these steps. The goal is to
have the office preview module in platform ready to use before the 2.5M2
release.
Thanks,
Marius
Hi,
The discussion started in http://xwiki.markmail.org/thread/hqvmy34jfknb2waa but since it's an important decision I'm making it a full thread here.
The idea is to know how we want to represent query string and anchors in links to documents in XWiki Syntax 2.1.
In 2.0 we were using: [[label>>whatever?queryString#anchor]]
The proposal is to move query string and anchor to a link parameter.
It be done like this:
[[label>>doc:mypage||parameters="a=b&c=d" anchor="..."]]
We could decide to use another syntax for parameters (ie query string) such as:
[[label>>doc:mypage||parameters="a=b,c=d" anchor="..."]]
This would make it a little bit less URL-specific.
The pros of this approach are:
- no need for the user to escape the ? and # characters in document names
- makes the syntax a little bit less "magic" and more formal
The cons:
- Takes a bit longer to write
- A new syntax to learn
WDYT?
Thanks
-Vincent
Hello all.
First of all, I'd like to say that I'm kind new in the XWiki project
and in this mailing list so, I apologize if this is an already
reported issue I'm not aware of (I looked for open issues related to
the customization of the PDF pages when exporting from XWiki but I
found nothing related to what I'm about to share with you):
I'm using XWiki 2.4 and I cannot make the example in
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration#HCustomiz…
related to the configuration of the field style work. After some
debugging, I found out why: basically, the example states that we
should use a field of type TextArea for the style property of the
PDFClass class. However, when doing so, at runtime, when getting the
value of my "style" field, I don't get what I actually wrote there,
because a new paragraph is inserted around my content, resulting in
something like:
<p>
h2 {
margin-left: 2cm;
margin-bottom: 1cm;
color: red;
}
h3 {
margin: 3cm;
color: yellow;
}
</p>
I thought the problem might be with the editor that was used for
editing the field or something, so I forced using the Text editor but
still had no results. This example only worked when I used a String
property instead of a TextArea (which is a real "pita" right?).
I'd like to know:
1 - Am I doing something wrong?
2 - Is this a known bug and I couldn't find information about it?
3 - If this is really a bug, can I help fixing it or something similar?
Regards,
Paulo Zenida
Hi,
I thought it would be good to summarize the rules I'm implementing/fixing relative to escaping in link references for both XWiki Syntax 2.0 and the new XWiki Syntax 2.1 I have started. This will later go in the XWiki Syntax page on xwiki.org.
There are 2 set of rules:
- For entity references
- For link references
Entity References
==============
The rules are (independent of the XWiki Syntax):
- if you need a \ in any part of the reference then you need to double it with \\
- For a : in a space name it's \:
- For a . in a page name it's \.
- For a @ in an attachment name it's \@
- For a ^ in an object name it's \^
- For a . in an object property name it's \.
Link References
=============
For XWiki Syntax 2.0
----------------------------
The rules are:
- if the link reference points to a document and you want a ?, #, @ or \ in any part of the reference you need to escape them with \?, \#, \@ or \\.
Note that when resolving a link reference to a document the link reference escapes are first unescaped and then the entity reference is unescaped. For ex for: [[label>>my\.page]] will result in a link to a page named "my.page" and [[label>>my\?page]] to "my?page".
- if link reference points to a mailto then no escaping is performed at all. Thus [[label>>mailto:john\@whatever.org]] will generate in HTML <a href="mailto:john\@whatever.org">john\(a)whatever.org</a>
- same for link refs to URLs
- For link to attachments, only the entity reference escape is performed, no additional escape is done for the link reference.
- For link to interwiki, if the interwiki path needs a @ then it must be escaped with \@. Same for the interwiki alias. Example: [[label>>what\@ever@wiki\@pedia]]
For XWiki Syntax 2.1
----------------------------
The rules are:
- if the link reference points to a document and you want a ?, # or \ in any part of the reference you need to escape them with \?, \#, or \\.
- if link reference points to a mailto then no escaping is performed at all.
- same for link refs to URLs
- For link to attachments, only the entity reference escape is performed, no additional escape is done for the link reference.
- For link to interwiki, no escaping is performed at all (and ":" is not allowed in the interwiki alias). Example: [[label>>interwiki:wikipedia:what\\ever]] will generate an interwiki path of what\\ever
Open Questions
=============
Do we want to allow \\ in any link references (mailto, attach, interwiki, url, etc) and unescape it to \ or should we keep the rules defined above?
Thanks
-Vincent
Hi devs,
knowing that gadgets will be xwiki macros instances (in any of the
approaches) we need a way to add all these in a dashboard. Proposed
options are at
http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HDashboardMacr…
. Currently implemented solution is 1/ which has a few drawbacks: it
defines a meta syntax for its content and this syntax doesn't allow more
complex layouts than a number of columns.
The new proposal is 4)
http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HOption429Colu…
, which basically proposes to use nested column macros (
http://svn.xwiki.org/svnroot/xwiki/contrib/projects/xwiki-macro-column/
) to do layouting and extend the section macro with a dashboard macro
which would be used on the first level to mark that the columned content
is a dashboard and not just regular wiki content. For more details about
the approach see the description in the design page, as well as for the
advantages of this proposal.
my +1, I like this approach, I will try to prove the concept in the next
days.
WDYT?
Thanks,
Anca
Hello,
See below.
---------- Forwarded message ----------
From: abusenius <platform-notifications(a)xwiki.org>
Date: Sun, Sep 19, 2010 at 2:37 PM
Subject: [xwiki-notifications] r31169 - in
platform/web/trunk/standard/src/main/webapp:
resources/js/xwiki/editors resources/js/xwiki/usersandgroups templates
To: platform-notifications(a)xwiki.org
> Author: abusenius
> Date: 2010-09-19 14:37:25 +0200 (Sun, 19 Sep 2010)
> New Revision: 31169
> Modified:
> Â Â platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/editors/dataeditors.js
> Â Â platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/usersandgroups/usersandgroups.js
> Â Â platform/web/trunk/standard/src/main/webapp/templates/addnewgroup.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/attachmentsinline.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/attachwysiwyg.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/changeavatar.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/changemyavatar.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/commentsinline.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/copy.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/delete.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/documentTags.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/edit.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/editclass.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/editgroup.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/editinline.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/editobject.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/edituser.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/editwysiwyg.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/editwysiwygnew.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/getgroupmembers.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/historyinline.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/importinline.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/passwd.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/recyclebinlist.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/registerinline.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/registeruser.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/renameStep1.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/resetversions.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/rightsUI.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/rollback.vm
> Â Â platform/web/trunk/standard/src/main/webapp/templates/userinactive.vm
> Log:
> XWIKI-5462: Added CSRF tokens to all default templates
[snip]
> Modified: platform/web/trunk/standard/src/main/webapp/templates/editgroup.vm
> ===================================================================
> --- platform/web/trunk/standard/src/main/webapp/templates/editgroup.vm  2010-09-18 23:58:17 UTC (rev 31168)
> +++ platform/web/trunk/standard/src/main/webapp/templates/editgroup.vm  2010-09-19 12:37:25 UTC (rev 31169)
> @@ -71,7 +71,8 @@
> Â //<![CDATA[
> Â (function() {
> Â var startup = function() {
> - Â tabl = new ASSTable("$url", 15, "display1", "scrollbar1", "memberstable", displayMembers, true);
> + Â var callback = function(row, i, table) { return displayMembers(row, i, table, form_token) };
> + Â tabl = new ASSTable("$url", 15, "display1", "scrollbar1", "memberstable", callback, true);
I think something is missing here. For me the form_token you pass here
to displayMembers is always undefined.
Am I missing something ?
Thanks,
Jerome.
Hi Anca,
See below
---------- Forwarded message ----------
From: <notifications(a)xwiki.org>
Date: Sat, Sep 18, 2010 at 12:00 AM
Subject: [xwiki-notifications] XWiki updates, 4 documents have been modified
since 2010/09/17 00:00
To: notifications(a)xwiki.org
[snip]
> lucaa - (16:59): I would need this to be able to implement the
Main.Dashboard page as a dashboard with gadgets
> lucaa - (17:01): any opinions?
> jvdrean - (17:03): lucaa: what do you need exactly ? having macros in the
default enterprise won’t resolve the PR problem right ?
> lucaa - (17:03): well, i would like to implement the Main.Dashboard as a
dashboard with gadgets
> lucaa - (17:04): and since gadgets are macros, the components of the
Main.Dashboard (spaces, recent changes, tag cloud) should be macros
> lucaa - (17:04): now, they could be java macros, but the problem is that
they will be harder to modify
> lucaa - (17:04): which I don’t like, in general
> lucaa - (17:05): another solution is to use the {{include }} macros and
leave them as pages...
> lucaa - (17:05): but
> lucaa - (17:05): in this case
> lucaa - (17:05): they won’t be configurable using macro parameters
> lucaa - (17:06): the good part though, is that anyone with edit rights
would be able to change them
Actually only global visibility (across wikis) needs programming rights.
Local wiki visibility only requires the user to have edit on the macro
document. See
org.xwiki.rendering.internal.macro.wikibridge.DefaultWikiMacroManager#isAllowed
We still need to agree we want to have wiki macros in the default wiki.
Jerome.
[snip]
To fix "XWIKI-5469: Change password feature does not use validation"
( http://jira.xwiki.org/jira/browse/XWIKI-5469 ) I would like to add
a document for helping the user change their password.
passwd.vm is only referenced in one place in
XWiki.XWikiUserPreferencesSheet so as a template it is unused unless
the Enterprise XAR is installed. To avoid a "rat's nest" dependency
graph, I do not like templates to have statically defined document
names so I'd like to avoid the method used in registerinline.vm.
Also any proposal which moves code from the /templates/ directory to
the inside of wikiland has my +1.
WDYT?
Caleb
I think this function would be useful, I have used code like it to
make sure scripts didn't run with PR when they shouldn't and I think
it deserves a place in the api.
The function doesn't need any special privileges to run, but after
it's run, api.Api#hasProgrammingRights will always return false and
api.Document#saveAsAuthor will be attempting to save as the guest
instead of the real document author. (likewise with
getDocumentAsAuthor and deleteAsAuthor)
Once permissions have been dropped, they cannot be regained (for the
duration of the request.)
This depends on another function in api.Api which is package private.
String getEffectiveScriptAuthorName()
returns the name given by XWikiContext.getDoc().getAuthor() unless
dropPermissions() has allready been called or XWikiContext.getDoc()
== null in which case it returns the guest username.
Why in the old api.Context? I envision in the future a
SecurityManager component will exist which distrusts not only script
but core java as well. I think the option to drop privileges when
unneeded should also be present in the final security manager
implementation. Since security managers require a large secure code
base to be useful, I am proposing api.Context#dropPermissions() as
an interim solution.
WDYT?
Caleb
Hi Alex,
On Sep 15, 2010, at 8:00 PM, abusenius (SVN) wrote:
> Author: abusenius
> Date: 2010-09-15 20:00:02 +0200 (Wed, 15 Sep 2010)
> New Revision: 31124
>
> Modified:
> platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.properties.vm
> Log:
> XWIKI-5461: Added configuration for CSRF protection
>
> Modified: platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.properties.vm
> ===================================================================
> --- platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.properties.vm 2010-09-15 17:59:36 UTC (rev 31123)
> +++ platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.properties.vm 2010-09-15 18:00:02 UTC (rev 31124)
> @@ -267,3 +267,23 @@
> #crypto.passwd.keyDerivationFunctionPropertiesForPasswordVerification = millisecondsOfProcessorTimeToSpend = 200
> #crypto.passwd.keyDerivationFunctionPropertiesForPasswordVerification = numberOfKilobytesOfMemoryToUse = 1024
> #crypto.passwd.keyDerivationFunctionPropertiesForPasswordVerification = derivedKeyLength = 32
> +
> +#-------------------------------------------------------------------------------------
> +# CSRF token component
> +#-------------------------------------------------------------------------------------
> +
> +#-# [Since 2.5M2]
> +#-# Controls whether secret token validation mechanism should be used (to prevent CSRF attacks).
> +#-#
> +#-# If enabled, all actions requiring "comment", "edit", "delete", "admin" or "programming" rights
> +#-# will check that the parameter "form_token" with the value of a random secret token is present
> +#-# in the request.
> +#-# This feature requires CSRFToken component.
I think we could remove this last sentence since the CSRFToken component is bundled with the platform and this message will probably confuse the user who's not going to know how to check if he has this component or not. It'll make him/her ask himself questions, which we don't want IMO.
> +#-#
> +#-# Valid values:
> +#-# 0: Disabled
> +#-# 1: Enabled
> +#-#
> +#-# Default value is 0
> +# core.csrftoken.enabled = 0
I guess we're going to turn it on by default when the implementation is finished?
Thanks
-Vincent