FRULE!!!: 9h to find ignoreRequestParams=”true” needs to be set!!!

In continuation of this I faced another problem in my target database. The first time the dialog for the sensitive data was called, it worked just fine. All subsequent calls just failed. After a very long time (you know it………) I finally figured out: the dialog box was using the parent document in subsequent calls.. but why? And why did it work on my test application.

With help from a coworker I finally, by accident!, figured the only difference between test and my actual database was ignoreRequestParams=”true”!! On test this parameter was set and there it worked. I gave it a try, without actually knowing what I was doing. Why I didn’t know? That’s a rhethorical question, right? 😉 On the web I have been stumbling across some other blogs mentioning it, which might have been the reason why I, ghosted  as I was through the lack sleep, tried it out on test. I honestly don’t know how that parameter came there.

But what the heck… finally my approach worked and I could save all my special infos with special access rights to another document!

Anyone: Would it be possible for someone knowing in detail what this parameter is about to write about it? Would be highly appreciated.

What I then figured was also very interesting in itself: Even though the “events” for the data source were not “visible” in the events viewer they were available! Under all properties etc.. you will find it:

That’s by the way also the place where you can toggle the flag for “ignoreRequestParams”!
The cool thing with those events: my defined document datasource is acting like an xPage in itself! Means I can change fields, run my custom validation approach etc. to my liking. Really neat!

Comments

  1. If this parameter is set to true, the datasource ignores all URL parameters like documentId, action, databaseName etc. If it is not set, all datasources will be forced to use the given URL parameters instead the (hardcoded?) parameters in your XPage.

    Not using this parameter (set to true) can cause security problems because it allows to overwrite the original values (think about 'mail.box' as the databaseName parameter).

    If you need to control your datasources with URL parameters you should think anout the paramPrefix parameter. It gives you a way to control multiple datasources at once.

  2. Hi Sven

    thanks for the explanation.

    Did I understand correctly: it SHOULD be (if possible) set to TRUE always?

    Cause if it is NOT set to true (i.e. not available at all), the URL parameter could point to wrong data sources etc?

  3. Yes. Like in any web application which is reachable from outside you should only allow what is really necessary.

    It is a possible way to access databases even if they are not visible to the www and a way for DOS attacks against a domino server (the server will try to open the database even it is on another server…)

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.