March 2010 - xwiki-devs@xwiki.org

[xwiki-devs] Questions about fixing getRenderedContent() bug
by Vincent Massol 18 Feb '15

18 Feb '15

Hi, Im trying to fix http://jira.xwiki.org/jira/browse/XWIKI-4274 Basically if you do $xwiki.getDocument("someDoc").getRenderedContent() it'll get executed in the context of the current doc which I believe is wrong especially since other signatures of getRenderedContent() execute in the target document's context. I have fixed this locally but found that admin.vm for example is assuming that getRenderedContent() will get executed in the context of the calling doc (i.e. XWiki.Import when doing an import for example). FYI the chain flow is admin.vm -- getRenderedContent() --> XWiki.AdminSheet --> XWiki.AdminImportSheet --> importinline.vm, which requires the current doc to be XWiki.Import (to get/put attachments from/to it). I can fix this easily using a new getRenderedContent signature I've introduced. However I'm wondering if we have other places that incorrectly use getRenderedContent() and assume it won't be rendered in the context of the target document. Is this change too dangerous to make? If not know, we'll need to it quickly (2.1M1?) since it's an important bug IMO. WDYT? Thanks -Vincent

4 7

[xwiki-devs] Redirect to a space
by Bruno Amaro Almeida 04 Jun '13

04 Jun '13

Hi How can i redirect the users after login to a space ? I`m looking at login.vm but i have no clue to do this Thanks

4 6

[xwiki-devs] Pretty Time library
by Vincent Massol 11 Jul '12

11 Jul '12

Could be useful: http://ocpsoft.com/prettytime/ Idea of usage: For ex we could use that to show the last modified document dates for dates in the past week (for ex): "Document created 2 days ago" It's in the maven central repo and it's under LGPL -Vincent

5 7

[xwiki-devs] How to load GWT application on Xwiki pages?
by Leon Wang 24 Nov '11

24 Nov '11

Hi Everyone! I have read this document "Writing GWT applications in XWiki" ( http://dev.xwiki.org/xwiki/bin/view/Drafts/WritingGWTApplicationsInXWiki) And I know how to develop GWT module for xwiki now. I also have read the document "WYSIWYG Editor Module" ( http://code.xwiki.org/xwiki/bin/view/Modules/WysiwygEditorModule) I followed the instruction which tried to integrate the WYSIWYG editor(GWT application) in wiki pages, and I put the following code in my wiki editor: "{{html}} <script type="text/javascript" src="XWikiWysiwyg.js"> alert('WYSIWYG code is loaded!'); </script> <textarea id="demo"></textarea> <script type="text/javascript"> Wysiwyg.onModuleLoad(function() { new WysiwygEditor({hookId:'demo'}); alert('WYSIWYG code is loaded!'); }); Wysiwyg.onModuleLoad(function() { editor = new WysiwygEditor({hookId: 'demo'}); }); }); </script> {{/html}}" After saved, it only display a blank text area without any sign of WYSIWYG editor, also there is no alart 'WYSIWYG code is loaded!' popup. Can you help me figure it out what is wrong with it? I am planing to develop a tree view using GWT to display Design Rationale Element. Could you give me some ideas of after my development, how can I embeded the GWT application into Xwiki pages and interact with the GWT application? Thank you very much! Leon

6 5

[xwiki-devs] [VOTE] Edit UI improvements and panelless edit
by Sergiu Dumitriu 27 Sep '10

27 Sep '10

Hi devs, We've been working on improving the editors (content, class, object), and now I have some pretty important UI changes to commit, but not everybody seems to agree with them, so I bring up a vote. The whole improvements can be seen on http://incubator.myxwiki.org/xwiki/bin/Improvements/ImprovedEdit Here are the individual voted points: 0 Remove all panels in edit mode 1a Parent and title above the content in wiki/wysiwyg mode 1b The same style in edit mode as in view mode for the parent/title fields 1c AJAX Suggest for the parent field 2a New label for the content textarea ("Content") 2b List of included documents after the Content label 3a Syntax switcher in the top right corner of the content 3b Syntax help in the top right corner of the content 3c Syntax help and switcher only in the wiki editor 4 Better label for the version comment 5a Right float the Minor edit field 5b Put the Minor edit label after the checkbox 6 Move autosave in line with the submit buttons 7 Introduce new AJAX-powered Add Object i) above the objects ii) bellow the objects 8 Introduce new AJAX-powered Add Object from this class i) at the top of the list of existing objects ii) at the end of the list 9 Move the class switcher in the top right corner 9b Remove the class switcher 10 Introduce new AJAX-powered Add Property i) at the top of the list of properties ii) at the end of the list I vote +1 for all of the above, except 9b (-0), and with options 7i), 8ii), and 10ii) -- Sergiu Dumitriu http://purl.org/net/sergiu/

7 13

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

18 Jun '10

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

6 24

[xwiki-devs] Introduce new tempresource action
by Vincent Massol 26 May '10

26 May '10

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

7 16

[xwiki-devs] [PROPOSAL] Rendering l10n
by Thomas Mortagne 21 Apr '10

21 Apr '10

Hi devs, We need to support some way internationalization of everything in the rendering that appear in the UI, for now it's mainly related to macros. What I propose is to introduce the rule that any displayable String returned by the API (MacroDescriptor#getName, ParameterDescriptor#getDescription, etc.) could be a l10n key. Then the API user call the l10n component to get the final String. pros: - no need to touch the current API - it avoid having complex API to support l10n specifics and makes pretty much everything depends on l10n component. It's easier for macro author to write a quick macro with some description without having to create l10n resource and call the l10n component just for english for example. - the displayer can control how to get actual translations the way it wants - we need something like that for wiki macros anyway: XWiki does not support translations of objects yet (and for long I guess since the issue is at database level) and it would be a pain to have to copy the content of the macro by language since most of the time the script of the macro would not be related to the language cons: - it's more work for the API user to filter the String with the l10n component to get the actual final String One detail I'm not sure of is if we introduce some syntax to explicitly indicate it's a l10n key or if we just always give the String to the l10n component which will return it as it is if it can't find any matching key. Having an explicit way to indicate a String is a key would be better to track l10n keys bugs but introduce a syntax is always more complex (what chars to choose, how to escape, etc...). WDYT ? Thanks, -- Thomas Mortagne

3 5

[xwiki-devs] A Problem about Debug Wysiwyg Editor
by Leon Wang 06 Apr '10

06 Apr '10

Hi Marius, hi XWiki Developers, Thank you for your reply and add instructions to http://dev.xwiki.org/xwiki/bin/view/Community/Debugging#HDebuggingtheWYSIWY…<http://www.google.com/url?q=http%3A%2F%2Fdev.xwiki.org%2Fxwiki%2Fbin%2Fview…> Really appreciated! After I executed the start_xwiki.sh and start_wysiwyg_noserver_debug.sh, it gives me new errors. It says: "[WARN] Unable to process 'file:/home/freeleons/XWiki_Enterprise_2.1.1/war/WEB-INF/web.xml' for servlet validation javax.servlet.UnavailableException: Configuration problem at org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:298) at org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:222) at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:68) at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:51) at com.google.gwt.dev.HostedMode.doStartup(HostedMode.java:344) at com.google.gwt.dev.HostedModeBase.startUp(HostedModeBase.java:585) at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:397) at com.google.gwt.dev.HostedMode.main(HostedMode.java:232)" also it gives me a hint: "[ERROR] Hint: Check that the type name 'com.xpn.xwiki.wysiwyg.client.Wysiwyg' is really what you meant" Here is the visual: http://picasaweb.google.com/lh/photo/arGtksR3nPM9-b-GbNOmsg?feat=directlink When I made the change to the script (start_wysiwyg_noserver_debug.sh), from: "com.google.gwt.dev.HostedMode \ -logLevel WARN \ -style DETAILED \ -noserver \ -port 8080 \ -startupUrl xwiki/$WYSIWYG_PATH/Wysiwyg.html \ com.xpn.xwiki.wysiwyg.Wysiwyg" to "com.google.gwt.dev.HostedMode \ -logLevel WARN \ -style DETAILED \ -noserver \ -port 8080 \ -startupUrl xwiki/$WYSIWYG_PATH/Wysiwyg.html \ com.xpn.xwiki.wysiwyg.client.Wysiwyg" It will give me the error: "[ERROR] Unable to find 'com/xpn/xwiki/wysiwyg/client/Wysiwyg.gwt.xml' on your classpath; could be a typo, or maybe you forgot to include a classpath entry for source?" Here is the screenshot of hierarchy of the XWiki Enterprise folder, http://picasaweb.google.com/lh/photo/arGtksR3nPM9-b-GbNOmsg?feat=directlink Could you please give me some suggestions? Thank you! Sincerely, Jue Wang

2 2

[xwiki-devs] [Discussion] What direction to take the administration application.
by Caleb James DeLisle 05 Apr '10

05 Apr '10

When I was trying to figure out how to cleanly configure the registration page, I wrote a piece of code to handle it. The code is at XWiki.ConfigurableClass and it displays configuration for applications which contain objects of the same class. Documentation is here: http://code.xwiki.org/xwiki/bin/view/Applications/AdministrationApplication… In adding this I made a few assumptions which may not be the direction which the community wants to go. #1 I added a document called XWiki.RegistrationHelp to the default XE package which explains how to configure the registration page. In the Registration section of the administration interface, I made the labels for the input fields into links to the relevant sections of the help page (I like links :) ) Vincent has suggested that instead of links we were to use popups or tooltips because they would not allow the user to leave the administration interface. The currently existing links could have click handlers added to show a popup and block the click so that they still work for users without Javascript. The other and more major issue in my mind is that I can't think of a way to show only information for the item clicked on while keeping the help page a single unit which can be read (and edited) easily. Another option would be to remove the help page and links but I found myself reading code to figure out what some of the parameters meant so I don't think that is a realistic option. I am in favor of continuing with the method which I started because I feel that popups are an attack on my browser and I see no way to keep tooltips centralized for reading beginning to end and for easily updating when things change. #2 When I added configuration for the registration page, I did not want to add it to XWikiPreferences. This is not only because I want to keep my code modular but I want to put myself in the position of an application developer so I can see the API from their point of view. This has lead to configuration for XWiki.Registration residing in XWiki.RegistrationConfig. It has been pointed out to me that this will make upgrading more difficult and I agree but I don't think adding properties to XWikiPreferences class for each and every application is reasonable and since third party developers cannot do that I see this as a deficiency in our API. The options I can see are to add a "Document Type" which defines a particular document as a configuration document which should never be upgraded but I think this is wrong because even configuration needs to be upgraded, it is the values which need to remain. Also I am not a fan of separating configuration to a document different than the code because the code needs to handle the case where the configuration is unavailable and I think code making static references to a document name is an antipattern. My proposal is to create another class just like ConfigurableClass except it will be UpgradableClass. A document may have an object of UpgradableClass and that object can either A. Point to another object in the same class which should have it's values loaded in on upgrade or B. Add some code which should be run on upgrade. It is important to understand that the document can be changed but the upgradable objects will load the values from the old object and set them in the new object. #3 Because the configuration for the registration page is seperate, it cannot be saved along with XWikiPreferences in a single save operation and because there is configuration for the registration page in XWikiPreferences and in RegistrationConfig, they are both specified to be displayed in the "Registration" section of the administration interface. XWiki.ConfigurableClass handles this situation by creating two forms with two save buttons and a heading in the middle saying "Configure XWiki.RegistrationConfig" It would be easy to override this with another message and it would be possible to make a single button for users who have Javascript enabled but it introduces the question do we want third party applications to anonymously add parameters to a section of the administration interface. I suppose the best answer would be to separate all of the parameters having to do with registration from XWikiPreferences (and stop referring to them in the core). I can think of no better solutions to this at the moment. #4 (No hasty changes here, just a proposal) The administration application uses the "admin" struts action which calls the AdminAction class. From my looking at AdminAction class I think it can be removed entirely and struts can be redirected to the InlineClass (Unproven claim). This brings up a point about permissions: admin permission must be had in order to use the admin action but only edit access to XWikiPreferences is required to do the things offered by the administration action. see: https://localhost:8443/xwikiTrunk/bin/edit/XWiki/XWikiPreferences?editor=ob… In fact admin action is not even necessary to use the Administration Application see: https://localhost:8443/xwikiTrunk/bin/inline/XWiki/XWikiPreferences?xpage=a… I think the myth that admin access is necessary to do the administrative functions is dangerous for administrators who may leave security holes as a result. My proposal is that we try removing AdminAction to sandbox and redirect /admin/ in struts to InlineAction. I also think we ought to redefine admin access perhaps as the combination of view, edit, and delete which cannot be denied at a lower level (so a space admin can delete a page even if it denies them access.) I have made XWiki.ConfigurableClass with the idea that it should be able to do all of the functions of the administration application (meaning XWikiPreferences would have a ConfigurableClass object for each section in the administration application). I am always happy to hear when somebody wants to use ConfigurableClass but I don't think porting XWikiPreferences over is a good idea until ConfigurationClass has had some time in the field and we are sure that we don't want to change any of it's behavior. Sorry for the long email, I had a lot to discuss and didn't want to spam the list with 4 emails about the administration application. Caleb

2 6