Event Listener Hijacking Password Reset

Help / Discuss
1

Hello All,

Password reset seems to be failing on my XWiki instance and I think it has something to do with an event listener I’ve implemented (using org.xwiki.observation.EventListener) as described in the tutorial.

Picture1

After entering the new password at the prompt I get redirected to the page containing the above objects. The password doesn’t get changed either. The only entry on my profile page is refreshed password reset token.

I’ve tried to delete the objects in the page and the entire page but keep getting redirected to the altered or deleted event listener page.

However, if I completely delete the page everything works as expected.

Any ideas on what could be causing this?

2

Hi Ben. I don’t see any reason but then you can put anything in a listener so maybe your listener is listening to an even triggered when a password is reset (the reset password page is XWiki.ResetPassword). The docs says:

When receiving the username via form submission, generate a random verification string which is stored (as a hash) inside a ResetPasswordRequestClass object attached to the user’s profile page. If no such object exists, it is created, but an existing object will be reused, meaning that at most one password reset request can be active at a moment."

So maybe you’re listening to doc modified, xobject modified kind of events and are doing something that prevent the user profile page to be modified?

3

Hello Vincent,

Thanks for the reply.

I couldn’t see any reason either, at least not explicitly within my code anyway. This is a quick summary of what’s in the listener:

In getEvents:

{{groovy}}
import org.xwiki.bridge.event.*
xcontext.method.output.value = [new DocumentCreatingEvent(), new DocumentUpdatingEvent()]
{{/groovy}}

In onEvent:

{{velocity}}

#set($mydoc = $xwiki.getDocument("Content Manager.Code.On Event Objects")) 
$mydoc.getRenderedContent()

{{/velocity}}

In Content Manager.Code.On Event Objects (this is in a separate document because I wanted to have inpage syntax highlighting):

{{groovy}}
import com.xpn.xwiki.objects.BaseObject;
import org.xwiki.model.reference.EntityReference;
import org.xwiki.model.reference.DocumentReference;
import com.xpn.xwiki.plugin.rightsmanager.RightsManagerPluginApi;

def docSource = xcontext.method.input.get(1)

if (docSource.space == "FooBar") {
     ...
     ...
}
{{groovy}}

So as far as I can tell I’m not doing anything outside of the FooBar space. And it’s almost as if the presence of this event listener is causing the problem, not the code itself. I say this because even if I delete everything inside the event listener I still get problems. It’s only when I delete the page from the recycle bin that I get password reset capability back.

Out of curiosity, does the event listener get “registered” at wiki startup? I ask because I did happen to restart my wiki after I completely removed the listener. So that might be introducing a new variable into my diagnosis.

4

Yes. All components are registered at startup. Components defined in wiki pages are also (re-)registered when the corresponding page is modified, and unregistered when the corresponding page is deleted (http://extensions.xwiki.org/xwiki/bin/view/Extension/WikiComponent%20Module#HBindcomponentimplementationstodocuments).

5

It turns out the problem is due to calling the code via $mydoc.getRenderedContent(). If I paste the code in directly it doesn’t cause any errors.

It might be worth noting that def docSource = xcontext.method.input.get(1) causes a null object error on the Content Manager.Code.On Event Objects page, but this has never affected the event listener behaviour. As I understand it, this is only due to the page trying to render itself.

I’ll mark this as resolved but if anyone has any suggestions on the correct way to “include” my code in this way that would be very welcome.

Thanks again.

6

I think you could try using the old xwiki.includeTopic() or xwiki.includeForm() APIs.