Martin Pradny's blog

I wasn't happy with findings in my previous post , because it can lead to security issues, but also can have performance hit when you actually need dynamic evaluation of injected code (I use it for app localization and few other use cases). After some digging I came to conclusion that it can't be easily changed/overridden because getBindingValue simply turns into createValueBinding when value is evaluated to a String with #{} inside. Only solution I see is to wrap binding with code that checks possible injections or runs the evaluation in case I really need it. Another benefit is that I can easily log/notify when possible unwanted injection happens. For the most simple use case that I used in demo I added two beans that implement DataObject to the app, so I can use following syntax ssan[..]/seval[..] (it's not possible to pass arguments in EL method calls in XPages, so this is a bit hacky way of doing this). Now when I repeat my test I get: Partial refresh to t...

While working on app optimization I experimented a bit more with 'Compute on page load' vs. 'Compute dynamically' behavior. There have been several discussions in past about possible combination of ${} and #{}, for example posts from  Marky Roden ,  Sven Hasselbach  and  Paul Withers  . What struck me today was risk of code injection. In this app many elements are read from configuration documents that are loaded into beans and later used using ${} binding. This is recommended way as it is static information, so it's efficient. It works nicely until you insert expressions into your data. This way I realized that a lot of code is prone to code injection that can be contained either in configuration documents or any string that is stored and later read this way. To simulate the issue I created simple page with one field, one button and one text: All it does is saving entered value into applicationScope and then displaying it. Since the text uses ${} Compu...

While doing optimization of application load time I found that XPagesPreloadDB notes.ini parameter didn't work in way I expected. With quick google search I realized that I'm not the first one to hit this problem as John Dalgaard wrote about the issue few years ago  https://www.dalsgaard-data.eu/blog/caching-in-xpages-not-as-straightforward-as-you-would-believe/ . My goal was similar. Just preload configuration as it's loaded from several places and even worse it's loaded using SessionAsSigner. First of my issues was caused by my stupid mistake. I copied parameter in syntax for Notes client, so it contained server name. It worked, kind of. So if you want to try it, just check the URL from request that's processed by XPages and you get: With Notes.ini setting: XPagesPreloadDB=dev/pradny!!test/appload.nsf/entry.xsp result was: http://localhost:80/dev/pradny!!test/appload.nsf/entry.xsp Which is different context than you'd normally use, so it's actuall...