xwiki-devs May 2018

xwiki-devs@xwiki.org

19 participants
56 discussions

by Alex Cotiugă

Hello devs, This Thursday is BFD#179: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays I would like to propose that this day to be a quantitative rather than qualitative day in terms of closed issues. There are bugs in older versions of XWiki that do not reproduce nor make sense anymore in the latest versions and make the BFD statistics to be less accurate. We should try to close as many as possible bugs of this kind. Our current status is: * -54 bugs over 120 days (4 months), i.e. we need to close 54 bugs to have created bugs # = closed bugs # * -97 bugs over 365 days (1 year) * -149 bugs over 500 days (between 1 and 2 years) * -316 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#179 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14300 Happy Bug Fixing Day, Alex

6 years, 3 months

[xwiki-devs] [Vote][UX] Visible Save buttons

by Ecaterina Moraru (Valica)

Hi devs, Just to make sure we are on the same page since there were some ambiguities on the proposal, I've put some screenshot on how it will look like: http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave#HProposal10… This proposal extracts the save controls and puts them on a fixed bottom bar. There are some problems with the inline mode and with the responsive versions. With the inline version we could decide to keep the current behavior and have the fixed bar only in Wiki and WYSIWYG modes. I guess we should do some implementation tests and see what's possible. Thanks, Caty

6 years, 3 months

[xwiki-devs] [Question for the xwiki security feature] Hi xwiki security members

by Kwan Kim

I am Kwan Kim who works for the Rogosin Institute (medical research company specialized for Kidney disease in New York) Recently we tried to use xwiki as an our wiki server. So we configured the xwiki server on Redhat, MySQL & Glassfish environment and ask vulnerability test team to test. However they found several security issues. And I am not a expert for the xwiki so I am not sure whether xwiki already has a solution to fix the issues or not. That’s why I would like to ask you about the security features of xwiki. This is the security problems which the vulnerability team addressed below: 1. Cross Site Scripting (XSS): Script insertion at Name Field in the registration form. When new user register, there is first and last name field. thesis fields allow javascript code. Is there any way we can put the some validation to prevent the javascript code ? 2. No controls for Account Creation The vulnerability test team think it is too easy to create new account Is there any way that new account need to get approval from admin user ? 3.Site discloses session tokens in multiple locations It seems xwiki use session token through URL(GET). The vulnerability test team suggest to use POST method instead GET. Is there any option to use POST method instead of GET method to transmit the session token information? 4.Username retrieval with no verification When the user forget the username, the user can retrieve username with email address. However it is not sent to email but show in the site. The vulnerability test team think the hacker can get the username if they try many different combination of email. Is it possible xwiki only send the username by email instead of showing in the page ? 5. Password Validation is weak It seems xwiki allow weak password to register new user. Is it possible to use strong password only when new user registered in xwiki? These are the all issue they addressed. Please let me know the answer. Thank you and have a good day Kwan Kim

6 years, 3 months

[xwiki-devs] [ANN] XWiki 9.11.5 released

by Guillaume Delhumeau

The XWiki development team is proud to announce the availability of XWiki 9.11.5. It is a bugfix release that covers important issues that we have discovered since 9.11.4 has been released. It also includes a feature from XWiki 10.4: the notifications macro, that is designed to replace Activity Stream soon. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.11.5/ Thanks for your support -The XWiki dev team

6 years, 3 months

[xwiki-devs] [Proposal] Refactor backward compat implementation for the Mail Sender

by Vincent Massol

Hi devs, We need to refactor the backward compat implementation for the Mail Sender since right now it’s causing for example https://jira.xwiki.org/browse/XWIKI-15196 (SMTP setting used for each new wiki no inherited from xwiki.properties). I’m proposing to change it as proposed on: https://jira.xwiki.org/browse/XWIKI-15196?focusedCommentId=98794&page=com.a… Copying the most relevant extract here for easiness of read: What I propose: * Introduce a new MandatoryDocumentInitializer component (or a DataMigration one) in a platform-mail-send-legacy module which is in charge of two things: ** Look for all XWiki.XWikiPreferences xobjects in the current wiki and copy the values to the XWiki.MailConfig xobject if they're different from defaults. This would execute on each subwiki at init time. ** Remove the SMTP xclasses from XWiki.XWikiPreferences xclass and xobjects in the current wiki * Modify XWikiPreferencesDocumentInitializer and remove the code that creates the mail-related xproperties. * Modify DefaultMailSenderConfiguration to stop looking in XWiki.XWikiPreferences. The new order will be: ** Look in Mail.MailConfig in the current wiki ** Look in the xwiki properties file Let me know if you see any issue with this. Note: The old mailsender plugin is already taking its mail config from the new mail config. Thanks -Vincent

6 years, 3 months

[xwiki-devs] Activating Wiki on a single host in fleet clears security cache for entire fleet

by ktc

Hi, we noticed an issue during host activation where a single host being activated would cause all hosts in the fleet to then clear their security cache. Upon investigation, we discovered that this was due to a JGroups message being sent for a DocumentUpdatedEvent. Here is a sample message received by one of the hosts in the fleet: Fri May 11 16:18:04 0995 GMT Wiki -@<host> [DEBUG] <null> (null) Received JGroups remote event [event: [org.xwiki.bridge.event.DocumentUpdatedEvent@16e3c8e3], source: [{docversion=41.1, doclanguage=, origdocversion=41.1, origdoclanguage=, docname=xwiki:XWiki.XWikiServerXwiki}], data: [{contextwiki=xwiki, contextuser=XWiki.XWikiGuest}]], id: <id_here> timestamp: [Fri May 11 16:18:04 UTC 2018] air time: 22 ms RID=, SESSION= >From what we can tell, the initialization triggers the XWikiServerXwikiDocumentInitializer's updateDocument() event. As expected, this document update produces the DocumentUpdatedEvent shown above. When the hosts receive this event through JGroups, it triggers [this condition in the DefaultSecurityCacheRulesInvalidator](https://github.com/xwiki/xwiki-platfo…, which then proceeds to remove the 'xwiki' node from the security cache (and everything else in the cache as well since they are all connected to that node). What is the purpose of this update document on initialization and is there any way for us to avoid it? For example, we could perhaps override the DefaultSecurityCacheRulesInvalidatorListener and comment out that condition if there are no major repercussions. Thanks! -- Sent from: http://xwiki.475771.n2.nabble.com/XWiki-Dev-f475773.html

6 years, 3 months

[xwiki-devs] [Proposal] CAPTCHA module refactoring

by Eduard Moraru

Hi, devs, XWiki's current CAPTCHA module [1] is very old and outdated for a while now and this is not news for anyone. I see 2 major problems: 1) The obvious one is that we just need a technologically better CAPTCHA implementation that the current JCaptcha-based one and JCaptcha is discontinued. 2) The current architecture is outdated as well (i.e. wrapped around Struts actions and initializing the VelocityContext with a custom binding) and hard to use (i.e. you have to write your CAPTCHA UI every time you use it, there is no rendering helper). For 1), as both determined a few years ago [2] and also observed from practice, the industry standard is now Google's reCaptcha service (either its v2 or invisible version, or both), so we definitely need an implementation that makes it easy to use in XWiki [3]. For 2), we need: * to allow CAPTCHA implementations to provide their own rendering ** Can be done using a template .vm file (rendered with the TemplateManager), a wiki page or directly from Java code. ** The implementation-specific parameters could be passed to control/customize a particular rendering. ** The syntax ID may not be needed, since the only relevant output would be html. * to move to a ScriptService-based system and to leave the resource (image/audio) accessing concern to the individual implementation (that may choose to continue with Struts actions, or may choose to use something lighter like a REST resource or even or even something more inventive, like temporary attachments on some fixed page). * an administration UI that configures the default CAPTCHA service and its configuration * to allow callers to use a different CAPTCHA than the default configured one, as long as it is available (i.e. installed) Examples: = Display $services.captcha.display() -- default implementation, current configuration $services.captcha.recaptcha.display() -- explicitly requested implementation, current/default configuration $services.captcha.recaptcha.display({'theme' : 'dark', 'size' : 'compact', 'sitekey' : 'xyz'}) -- explicitly requested implementation and custom configuration overwrites $services.captcha.jcaptcha.display() -- other implementation, current/default configuration = Verification $services.captcha.isValid() -- default implementation, current configuration $services.captcha.recaptcha.isValid() -- explicitly requested implementation, current/default configuration $services.captcha.recaptcha.isValid({'secret' : 'xyz'}) -- explicitly requested implementation and custom configuration overwrites $services.captcha.jcaptcha.isValid() -- explicitly requested implementation and custom configuration overwrites Basically, the ScriptService API would be highly simplified to just displaying and validating, while the components would consist of 2 parts: * a generic Manager for the various implementations (listing, getting/setting the default) * various implementations, each responsible with rendering a form-friendly CAPTCHA input and using the current request for extracting the information they needs to read the user's answer and validate it. WDYT? Thanks, Eduard ---------- [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Captcha%20Module [2] http://design.xwiki.org/xwiki/bin/view/Proposal/CAPTCHAinvestigation70 [3] https://jira.xwiki.org/browse/XWIKI-12964

6 years, 3 months

[xwiki-devs] [Translation] Translation migration

by Adel Atallah

Hi, To fix some issues we have, we want to transform translation files so that they have the same structure as the english base translation file. You can have a look at this test commit <https://github.com/atallahade/xwiki-platform/commit/5b89e1d2fd856af58b68b3b…> to see what the migration is about. You obviously don't have to check every changes but if you manage to find something wrong somewhere, please let us know here. We will lock the translations on l10.xwiki.org and do the migration once we know for sure that it will not create other issues. Also, be aware that future translations added to the platform will automatically be changed as soon as a first modification is made by a user. Thanks, Adel

6 years, 3 months

[xwiki-devs] [XWiki Day] BFD#178

by Alex Cotiugă

Hello devs, This Thursday is BFD#178: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status is: * -59 bugs over 120 days (4 months), i.e. we need to close 59 bugs to have created bugs # = closed bugs # * -96 bugs over 365 days (1 year) * -131 bugs over 500 days (between 1 and 2 years) * -310 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#178 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14298 Happy Bug Fixing Day, Alex

6 years, 3 months

[xwiki-devs] [Brainstorming] Importing translations to Weblate

by Adel Atallah

Hello devs, I need your opinion on how we should import new components (i.e. translations) into Weblate <http://l10n.xwiki.org>. Weblate allows you to create components directly on their platform but it will be very difficult for us to so because we would have to run an import script to generate translation files and then fill in many error prone information. So what I was thinking of was to create a script which will just read a file where each line contains: 1. The component name 2. The base translation file path (english translation file) 3. The repository url It will then create or import the component automatically based on these lines. The downside is that you'll have to modify a file each time you want to create (or delete) a component and you'll have to execute the script from the server. WDYT? Thanks, Adel

6 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs May 2018