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