August 2019 - xwiki-devs@xwiki.org

[xwiki-devs] [contrib] any interest in another authenticator that deals with failed logins
by Clemens Klein-Robbenhaar 19 Aug '19

19 Aug '19

Hi devs. I noticed that the recent 11.6.x series have introduced a way to deal with attempts to guess a users password by introducing a strategy to handle repeated login failures. I should have payed attention before this was published because I have been implementing something similar because of several user requests. Anyway, my alternative solution has been finished in parallel, and I wonder if there is any interest of hosting this as a contrib project. The implementation differs in the following details: - it does not use the new AuthenticationFailureEvents and the introduced component API, instead it implements its own XWikiAuthService - this means it works for 10.x, too (which my users are mostly running) - otoh it does not work with e.g. the LDAPAuthenticator - it also allows to block IPs (not that I care much about, but some people want this) - it unblocks the user after a given time frame without having an Admin to intervene I guess I can migrate at least most of it into the new AuthenticationFailureStrategy to have a showcase for a different implementation, but for now it is a separate and already slightly outdated implementation. I think I will upload the results to e.x.o anyway (with a big note that this is superseded since XWiki 11.6), but is there any interest of hosting this as an xwiki-contrib project, maybe with the name 'authenticator-blocking', package 'org.xwiki.contrib.blockingauth' and maybe even a Jira project like 'BLOCKINGAUTH' ? Best, Clemens

5 4

[xwiki-devs] [XWiki Day] BFD#220
by Oana-Lavinia Florean 09 Aug '19

09 Aug '19

Hello devs, This Thursday is BFD#220: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -26 bugs over 120 days (4 months), i.e. we need to close 26 bugs to have created bugs == closed bugs * -98 bugs over 365 days (1 year) * -153 bugs over 500 days (between 1 and 2 years) * -376 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#220 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14434 Good luck at fixing bugs, Lavinia

1 1

[xwiki-devs] Use the new Mail Sender API for the Share Page By Mail feature
by Gabriel Raileanu 09 Aug '19

09 Aug '19

Hello everyone! Currently, I'm working on moving to the new Mail Sender API for share page by mail, which is related in XWiki-11786 <https://jira.xwiki.org/browse/XWIKI-11786>. After having some discussions with Vincent, we decided to include the possibility of sending the email to groups, related in XWiki-12112 <https://jira.xwiki.org/browse/XWIKI-12112>. Even if everything looks good for now, a problem just appeared when trying to access the recipient name (it's used in the email body, for addressing the recipient (*Hello ${recipientName}*). It seems like the new API it's not providing other information than the email address, which was confirmed by XWiki-12207 <https://jira.xwiki.org/browse/XWIKI-12207>. For now, I worked here <https://github.com/arcilli/xwiki-platform/tree/XWIKI-12112> with some code from Vincent's commits <https://github.com/xwiki/xwiki-platform/tree/feature-sharepage-group>. Also, after a few discussions with Marius, we concluded that for having the name of the recipient in the message, the code needs some refactoring, which can take a considerable amount of time. Another solution is to exclude the *recipientName *from the body of the message and keep only *Hello *(which would be a regression). This will be a shorter solution, but with the benefit of having the possibility to send emails to groups. What's your opinion on this? Thanks a lot! Have a nice day! -- <http://www.xwiki.com/> *Gabriel Răileanu* *Software Developer Engineer Intern* gabriel.raileanu(a)xwiki.com

2 1

[xwiki-devs] [ANN] XWiki 11.6.1 released
by Simon Urli 08 Aug '19

08 Aug '19

The XWiki development team is proud to announce the availability of XWiki 11.6.1. This is a bugfix release that covers important issues that we have discovered since XWiki 11.6 has been released. It has been released mainly to fix a bug related with the usage of nested wikimacro, which might make some applications unusable. It also fix some other bugs related to the newly introduced async macro. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.6.1 Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [Proposal] Best practice: tests must not output anything outside of the target directory
by Vincent Massol 08 Aug '19

08 Aug '19

Hi devs, I was pretty sure that this was discussed before but I can’t find it so I’m posting it again since I noticed that we continue to have tests (and even add new ones) that use the OS tmp directory to output test data. Tests must not generate anything outside of the target/ directory as this will cause several problems: * not clean generated test data after the test * create a state that can make other tests fail * generate errors in jenkins since jenkins monitors created files and doesn't allow to remove files outside of the worskspace WDYT? If ok I’ll add it to https://dev.xwiki.org/xwiki/bin/view/Community/Testing/JavaUnitTesting/#HBe… Thanks -Vincent PS: Ideally we should have a automatic verification in the build but it doesn’t seem easy to implement, so right now, I’m only proposing it as a best practice.

4 4

[xwiki-devs] [XWiki Day] BFD#219
by Oana-Lavinia Florean 02 Aug '19

02 Aug '19

Hello devs, This Thursday is BFD#219: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -28 bugs over 120 days (4 months), i.e. we need to close 28 bugs to have created bugs == closed bugs * -94 bugs over 365 days (1 year) * -153 bugs over 500 days (between 1 and 2 years) * -376 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#219 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14433 Good luck at fixing bugs, Lavinia

1 1

[xwiki-devs] [Proposal] Use a standard 3-way merge implementation
by Simon Urli 01 Aug '19

01 Aug '19

Hello everyone, I'm currently working on the commons-diff-api to add new capabilities in case of conflict. Yesterday while I was working on it, I added new tests to check my changes and discovered that our current implementation of the 3-way merge was not following a "standard" implementation, and so some expectations I could have was not followed. Actually Thomas did a huge job by implementing by himself the 3-way merge based on the diff of previous-current and previous-next, but AFAIU this implementation does not take into account the diff current-next which can also bring information. So for example if you try to do a merge, with the following lines: origin="Once upon a time","a wolf","started to walk","in the forest" next="Once upon a time","a wolf","dressed in black","in the forest" current="Once upon a time","a wolf","started to walk","dressed in black","in the forest" the current result will be: "Once upon a time", "a wolf", "dressed in black", "dressed in black", "in the forest" instead of treating it like a conflict which can be view as a more "standard" answer. Here by standard, I mean the result that a tool like "diff3" or git merge would do. I dig a bit on internet yesterday and apparently diff3 is really considered as the standard implementation of a 3-way merge. I performed the check with those lines both using git and diff3 and in both cases, they see the "started to walk" as a conflictual line: Once upon a time a wolf <<<<<<< HEAD started to walk ======= >>>>>>> 20b7776... My change dressed in black in the forest I assume we could debug the implementation Thomas done to ensure this usecase is taken into account, as far as I can see it's not easy, but I guess it's possible. Another solution, which I personally prefer, would be to rely on an existing implementation of a diff3 merge, or Git merge: I found yesterday that jgit have their own Java implementation of the merge (https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit/src/org/eclips…) and AFAICS the license doesn't prevent us to reuse it (it's a derived BSD license). I don't think we cannot completely reuse it as it is, but it's at least a good inspiration to do our own implementation based on a standard. A better solution would certainly to use a dedicated maintained library but I did not manage to find it. Now we could also assume that the current behaviour of the merge is what we want and we keep up with it. So what do you think, should we change our implem or keep it like that? Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

1 0