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