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

by Alex Cotiugă

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

7 years, 3 months

1
1
0 0

[xwiki-devs] [UX][Idea] User Index Cards

by Ecaterina Moraru (Valica)

Hi devs, This proposal displays an additional layout mode for the User Index, where users are displayed using cards. http://design.xwiki.org/xwiki/bin/download/Proposal/Users/UserIndex/UserInd… This idea was proposed / discussed by Nicolas Lemoine. The initial purpose was to improve the UI of our User Index. I've iterated also on some other ideas, like application specific actions integration inside content menu, user actions (send message, follow) in the card display, user groups display, etc. Proposal: http://design.xwiki.org/xwiki/bin/view/Proposal/Users/UserIndex/UserIndexCa… Let me know what you think, Caty

7 years, 3 months

3
6
0 0

[xwiki-devs] [Brainstorming] Best practices on indentation for rendering macros in scripts

by Vincent Massol

Hi, Context 1: https://jira.xwiki.org/browse/WIKIEDITOR-58 Context 2: Fill the “velocity code style” section of http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/ Option A-1: No top level indentation ========================= {{velocity}} #set ($var = …) #if (…) … #if (…) #end #end {{/velocity}} Nested example: {{velocity}} #if ($doc.fullName != 'XWiki.AdminInlineSheet') #set($formname = 'inline') #set($saveaction = 'save') #set($previewenabled = true) #set($xnotification = $!request.getParameter('xnotification')) {{html}} <form id="inline" method="post" action="$doc.getURL('preview’)"> <div> … {{/velocity}} Pros: * This is what we currently do which IMO means it’s the more natural way * Makes content more visible when editing inside xwiki since it takes less horizontal space * Less typing and less chance to make it wrong Option A-2: Top level indentation ======================== {{velocity}} #set ($var = …) #if (…) … #if (…) #end #end {{/velocity}} Nested example: {{velocity}} #if ($doc.fullName != 'XWiki.AdminInlineSheet') #set($formname = 'inline') #set($saveaction = 'save') #set($previewenabled = true) #set($xnotification = $!request.getParameter('xnotification')) {{html}} <form id="inline" method="post" action="$doc.getURL('preview’)"> <div> … {{/velocity}} Pros: * More logical since a macro is a container (even though it’s different syntax - wiki markup vs velocity - so it’s arguable) * More legible? Cons * This means slowly changing everywhere we use scripting. WDYT? I think my preference goes to A-1 FTM since I’ve never thought to myself that it was an issue all these years of using it. Thanks -Vincent

7 years, 3 months

9
13
0 0

[xwiki-devs] Nexus account creation

by Vivek Iyer

Hi everyone! I want to release v0.1 of the Blockly extension, and I need a Nexus account as per the steps given here ( http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HJIRARelease). I would like my username for the Nexus account to be Remorax. Please do the needful and get back to me! Thanks and regards, Vivek iyer

7 years, 3 months

2
1
0 0

[xwiki-devs] [GSoC] Reminder: First evaluation deadline on 15th of June 16:00 UTC (1 week)

by Eduard Moraru

Hello, GSoC students and mentors. I would like to remind you that the first evaluation deadline is approaching at the end of next week. Below is an extract from the timeline[1]: June 11 16:00 UTC Mentors and students can begin submitting Phase 1 evaluations June 15 16:00 UTC Phase 1 Evaluation deadline As a result, please make sure students talk to their mentors and make sure they are prepared and understand what is expected from them in order to successfully pass the evaluation. Very important: Do not forget to actually fill in the evaluation, when asked by Google, as not doing so (either by the student or the mentor) will cause the student to be failed by default, even if they did a great job so far. So *both* mentors and students need to fill in evaluations, and not only mentors! Hope you're having a great time, learning and building cool stuff! Thanks, Eduard ---------- [1] https://developers.google.com/open-source/gsoc/timeline

7 years, 3 months

1
0
0 0

[xwiki-devs] [Proposal] Display user messages in the notifications.

by Guillaume Delhumeau

Notifications application is almost ready to replace the Activity Stream's UI. The only remaining thing is the display of the messages from the Message Stream in the Notifications. We have made a quick brainstorming with Caty and Vincent, and here is our conclusions. 1/ We think it make sense to display user messages in the notifications because it is typically what notifications are made for: pop-up important information concerning what the user cares. In the past, we decided to disable the Message Stream by default because messages were lost in the Activity Stream. But in the case of the notifications, users can chose what they want to receive so there is less chance to miss messages in the middle of thousand of events. 2/ Like all other types of notification, there should be a button in the notification settings of each user to decide to enable or disable these messages in the notifications. It should be enabled by default. 3/ We should add the "send message" gadget in the "alert" menu (via an UIX) so it's easy to find and to send messages. 4/ Provide a form to be able to reply to a personal message. 5/ Let the message stream disabled by default. Users who are used to it will not lose the feature but we don't make it visible for now until we make some other improvements. This is what I am starting to implement right now with the hope it's done for XWiki 10.5. In the future, we should add the following features: a/ Having a real "inbox" application (a "Message Center") to handle all messages. b/ Be notified when someone mention you in a content or in a comment (example: "@vmassol: You may want to read this page" will trigger a notification to Vincent Massol). c/ Handling correcty messages sent to a group if the first implementation do not handle it (group filtering could be a problem with SQL). Caty, Vincent, please reply if I've forget something. All others: if you have any recommendation or counter argument, please post it quickly :) Thanks for you time and have a great day, Guillaume -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

7 years, 3 months

6
16
0 0

[xwiki-devs] [Regarding XWiki.Registration ] Hi devs@xwiki.org

by Kwan Kim

Hello devs(a)xwiki.org<mailto:devs@xwiki.org> I has a question for the XWiki.Registration I tried to add input validation for the registration and it seems the following link has the information about it. http://extensions.xwiki.org/xwiki/bin/view/Extension/Administration%20Appli… When I read this document, there is the text like: Things which you may configure by editing XWiki.Registration However where can I find XWiki.Registration ? Is it configuration file ? I already check Registration section of the Administration Interface but I can not find. Please let me know where can I find XWiki.Registration. Thanks Kwan

7 years, 3 months

2
1
0 0

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

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

7 years, 3 months

1
0
0 0

[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

7 years, 3 months

3
9
0 0

[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

7 years, 3 months

4
4
0 0

[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

7 years, 3 months

1
0
0 0

[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

7 years, 3 months

1
0
0 0

[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

7 years, 3 months

3
5
0 0

[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

7 years, 3 months

4
8
0 0

[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

7 years, 3 months

2
3
0 0

[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

7 years, 3 months

1
0
0 0

[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

7 years, 3 months

2
2
0 0

[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

7 years, 3 months

5
9
0 0

[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

7 years, 3 months

1
0
0 0

[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

7 years, 3 months

2
3
0 0

[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.

7 years, 3 months

2
1
0 0

[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

7 years, 3 months

3
4
0 0

[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

7 years, 3 months

4
7
0 0

[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

7 years, 3 months

1
0
0 0

[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

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