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