xwiki-devs May 2018

xwiki-devs@xwiki.org

19 participants
56 discussions

[xwiki-devs] [Brainstorming] Should we support multibranch translations?

by Adel Atallah

Hi, Following my previous email on "How should we review translations?", I'd like to know here if we should support automatic multibranch translations in Weblate. What I mean here is that with the old l10n platform, we would apply new translations on multiple git branches (for some projects like XWiki Platform). It was important to have new translations applied on LTS releases and other branches. The problem is that we can't tell Weblate to automatically push changes on multiple branches. We have discuss the problem with the maintainer here: https://github.com/WeblateOrg/weblate/issues/2016. What we can do is to duplicate Weblate components (a component is just a file to translate) for as many branches as we need. Making a change to a translation key (e.g. tour.homepageTour.pageMenu.contentB) will propagate the change to every other components with the same key. This way we can have a PR made with the same change on every branch we want. So here are the two options: 1) We keep the actual behavior Pros: - We will only have one PR to review (on master branch) Cons: - We will have to apply new changes to other branches ourselves when needed 2) We duplicate components Pros: - Changes will automatically be made for every specified branches Cons: - Some work to do: we can't create all the new components by hand so we will have to generate every components in some way - It will make Weblate much more complex because you can't hide components (https://i.imgur.com/YJ8qtUz.png) I prefer option 1 because it will make Weblate easier to use. For option 2, we can also disable translation propagation and let people make translations on the branch they want. Thanks, Adel

6 years, 7 months

[xwiki-devs] [ANN] XWiki 10.4 released

by Vincent Massol

The XWiki development team is proud to announce the availability of XWiki 10.4. In this version we've improved the Navigation panel by allowing pages to be excluded from the listing. We've added a new macro for Notifications that allows it to be embedded in other pages. We've also improved the History's Changes view by providing more navigation options between versions. We've continued to tweak the edit protection, added in the previous version, for some default extension pages (like Skin, Color Themes, Dashboard, Sandbox, etc.). 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/10.4/ Thanks for your support -The XWiki dev team

6 years, 7 months

[xwiki-devs] [contrib] Request for blockly contrib application

by Vivek Iyer

Hi all! This mail is a request for the creation of a new contrib project named blockly-editor-application, which adds a Google Blockly code editor to XWiki. Just as an FYI, my GitHub username is Remorax :) Please do the needful and get back to me ASAP! Thanks and regards, Vivek Iyer

6 years, 7 months

[xwiki-devs] [Brainstorming] XWiki and accessibility

by Vincent Massol

Hi everyone, I just realized that: 1) we're not testing WCAG as part of our QA efforts (we have some basic WCAG automated tests but they cover only a small part - see http://dev.xwiki.org/xwiki/bin/view/Community/WCAGTesting). For ex we don't test how readable our UIs are with a screen reader and how user can use the UI without the mouse. 2) As we progress and make our UIs more "usable", for example by replacing input fields with nice drag and drop UIs (see Applications Panel, the new Nav Panel Admin in 10.5, etc), we actually make our UIs less usable for persons with disabilities 3) We can always argue that everything can also be done by using the object editor and thus we have a fallback. We have a way in the user profile to indicate that the user is requesting accessibility. However when active, we don't change the UI in lots of places (for example in the App Panel admin UI, we don't point link to the object editor instead of displaying the drag&drop). So I was wondering if we wanted to have a plan/direction for this. Seen the manpower we have I think we need to do the simplest thing that can work. The objet editor is a good direction IMO. So IMO, if we wanted to improve XWiki accessibility, we should do: A) Have someone test with a screen reader and report issues B) Have someone test without the mouse and report issues C) Review places in the UI where we should check if accessibility is active for the current user and if so, fallback to some links to the object editor with some explanation text. Report issues WDYT? Thanks -Vincent PS: I’m not saying we should do this now, but more making sure we have a plan we agree on.

6 years, 7 months

[xwiki-devs] [Page type] What about Main.WebHome

by Thomas Mortagne

Hi xwikiers, In 10.3 I introduced a "home" type with Main.WebHome in mind with the following defaults: * edit allow * delete forbidden * no upgrade if modified I tough that deleting the wiki home page was not so great. Eduard argue that since the wiki home page is configurable there is no reason to restrict delete right. WDYT ? I feel that most people don't change the configured home page so I'm +1 to keep it like this but I'm not strongly against allowing delete if others think it's fine since I don't have much experience with configured home page use case. -- Thomas Mortagne

6 years, 7 months

[xwiki-devs] [Brainstorming] How should we review translations?

by Adel Atallah

Hello everyone, As you probably know, we have decided to use Weblate <https://weblate.org/> as our new translation platform (l10n.xwiki.com). We still need to make some decisions before making an official announcement to the community. I'd like to know here how we should deal with translation reviews. I'm thinking of two ways to review translations: 1) Reviewing directly on the Weblate platform Pros: - Users can only make suggestions for already approved translations (which means we'll only have approved translations in the commits) - We can compare the translated keys to the source one (English) - We could push commits directly on the git repository instead of making PRs Cons: - AFAICS we can only review one translation key at a time (and overall the review process seems to be quite hard) - It seems that we receive an email for each new suggestions/translations (and we can't group them) 2) Reviewing on Github (with PRs) Pros: - We can review everything in a single view (github diff) - We know exactly what we are merging in the repository Cons: - Can't see the English source next to the translation (even if we mostly don't need to) - It's harder to manage spam as people could change every translations (no locking/suggestions) - You'll have to go on Weblate and revert rejected keys (one by one) I'm in favor of option 2 as it's the simplest and the safest one as everything can be checked on the PR. If you need to see how reviews are being made on Weblate, I can probably send screenshots or just give, for some of you, manager rights on the platform. WDYT? Thanks, Adel

6 years, 7 months

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

by Adel Atallah

On Fri, May 18, 2018 at 9:35 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: > On Thu, May 17, 2018 at 10:10 PM, Kwan Kim <kwk9002(a)nyp.org> wrote: >> 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. > > It's not very clear to me what this mean. In which context exactly the > javascript inserted in the user name is executed ? The inserted javascript can be found on the profile page. See this screenshot for instance: https://i.imgur.com/NNcSFb0.png We could either escape HTML tags whenever first name and last name fields are displayed or we can escape the tags directly when saving the information on the database (but we'll need to make a migration). > >> >> 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 ? > > Its possible to disable registration and let admins create accounts > but I don't think there is any support for admin validation of self > registered users (but it's possible I missed it). > >> >> >> 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? > > It's not a really a all or nothing central place so we would need to > know where exactly you have this issue to see if there is a way to fix > it in a case by case basis. > >> >> >> >> 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 ? > > Would be great if you could create an issue about that on > http://jira.xwiki.org. Looks easy to fix, just need to discuss if we > should do it or not. On my side I did not know we were displaying the > user id in this page and I agree that it's probably not a good idea. > >> >> >> >> >> 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? > > It's possible to add a lot of constraint in the registration form. See > http://extensions.xwiki.org/xwiki/bin/view/Extension/Administration%20Appli…. > >> >> >> >> These are the all issue they addressed. >> >> Please let me know the answer. >> >> Thank you and have a good day >> >> Kwan Kim > > > > -- > Thomas Mortagne Thanks for your report Kwan Kim :), Adel Atallah

6 years, 7 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 ? [cid:E6CD6E35-B5EA-48C1-86BD-525C5F1940F3@med.cornell.edu] 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? [cid:4EB11B1D-6F82-4E58-BA22-A828358F5F9F@med.cornell.edu] 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 ? [cid:7C406F30-67F3-4868-A874-1E9DF704AC75@med.cornell.edu] 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? [cid:38B73B7C-A420-4478-8BA0-A89E8897C1AC@med.cornell.edu] These are the all issue they addressed. Please let me know the answer. Thank you and have a good day Kwan Kim

6 years, 7 months

[xwiki-devs] [Brainstorming] Should we keep the current translation naming rules for class property translations?

by Vincent Massol

Hi devs, Context: I had some quick discussion on this PR () and it led to discussing our current naming rule for class property translations. Right now our rule is: http://dev.xwiki.org/xwiki/bin/view/Community/L10N%20Conventions#HTranslati… I.e. for example: Gardening.Code.GardeningScriptConfigurationClass_activeQueryScripts I see at least 2 problems with this: 1) Problem 1: It’s not consistent with how we name other translations (we use lowercase everywhere and the prefix is the module name, not the space name). For example: gardening.wiki.selectScripts=Sélectionnez les scripts de jardinage actifs gardening.wiki.startJob=Démarrer le jardinage gardening.wiki.start=Jardiner ! gardening.job.success=Terminé ! gardening.job.error=Une erreur est survenue, consultez les journaux pour plus d'information. Gardening.Code.GardeningScriptConfigurationClass_activeQueryScripts=Scripts de requête actifs 2) Problem 2: It’s fragile as it depends on the location of the class. BTW just realizing that we may have broken lots of translations (and still are) when we moved code pages under the Code space… Did we check that? FTR, the LT solves this by offering a translation prefix that can be specified by the dev. WDYT? Do you agree with the problems? Do you see any other problem? Do you have any solution to propose? Note: I’m not suggesting to change this right now but I’d like that we come to an agreement to what we’d like to have in the future. Thanks -Vincent

6 years, 7 months

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

by Alex Cotiugă

Hello devs, This Thursday is BFD#177: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays 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 # * -91 bugs over 365 days (1 year) * -119 bugs over 500 days (between 1 and 2 years) * -308 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#177 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14297 Happy Bug Fixing Day, Alex

6 years, 7 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