Domino Upgrade

VersionSupport end
Upgrade to 9.x now!
(see the full Lotus lifcyle) To make your upgrade a success use the Upgrade Cheat Sheet.
Contemplating to replace Notes? You have to read this! (also available on Slideshare)


Other languages on request.


Useful Tools

Get Firefox
Use OpenDNS
The support for Windows XP has come to an end . Time to consider an alternative to move on.

About Me

I am the "IBM Collaboration & Productivity Advisor" for IBM Asia Pacific. I'm based in Singapore.
Reach out to me via:
Follow notessensei on Twitter
Amazon Store
Amazon Kindle
NotesSensei's Spreadshirt shop
profile for stwissel on Stack Exchange, a network of free, community-driven Q&A sites

« Lessons from Project OrangeBox | Main| GIT deploy your static sites - Part 1 »

Serving Single Page Applications with Domino

Single Page Applications (SPA) are all the rage. They get developed with AngularJS, ReactJS or {insert-your-framework-of-choice}. Those share a few communialities:
  • the application is served by a static web server
  • data is provided via an API, typically reading/writing JSON via REST or graph
  • authentication is often long lasting (remember me...) based on JWT
  • authentication is highly flexible: login with {facebook|google|linkedin|twitter} or a corporate account. Increasingly 2 factor authentication is used (especially in Europe)
How does Domino fit into the picture with its integrated http stack, authentication and database? The answer isn't very straight forward. Bundling components creates ease of administration, but carries the risk that new technologies are implemented late (or not at all). For anything internet facing that's quite some risk. So here is what I would do:
Red/Green Zone layout for Domino
The main rationale for this approach is a best in breed selection of components separated by firewall components. In detail:
  • The front facing machine is a NGINX http server. I would configure it to support http/2, PageSpeed and Certbot. All calls to http would get redirected to https provided by LetsEncrypt (or buy your own). Running in a VM or a Container I would wipe it from time to time (daily), so anything that might have established a foothold dies then
  • The http server would contain the SPA with proper manifest and http expiry headers. That makes delivery fast and saves server resources up the chain. Deployment would be bound to the VM/Container creation process, so the http server would be mainly readonly
  • The authProxy would be a NodeJS application using the PassportJS framework. It offers an unparalleled selection of more than 300 ways to authenticate. The identified user then can be passed on to Domino. In addition some URL sanitisation could be performed. Since only API calls would land there, checking them for plausibility can be done cheap and easy
  • The Domino server's role is the provision of API access powered by its NoSQL NSF store. If so choosen its LDAP could serve as the identity source for the passport authentication
Who is member of the green or red zone is subject to debate, so you might want to go with a different approach like the one below.
Alternate layout for Domino SPA
As usual: YMMV


Gravatar Image1 - Can you pass the NodeJS Passeport user to Domino and have this user authentified on Domino (including Reader / Author fields and so on ?)
If so, how can you do that ? (Specific HTTP Header for IHS/Was plugin, other)


Gravatar Image2 - @Michael: Yes you can using HTTP Headers and the HTTPEnableConnectorHeaders notes.ini variable.

Reader/Author fields have nothing to do with AUTHENTICATION. They are a matter of (document level) AUTHORIZATION which happens after the user is identified. Authorization is generally oblivious about the way authentication has happened.

Kind of: As long as I know who you are, no matter how I found out, I can tell what you are allowed to do.

Gravatar Image3 - You'll find that people working on variants of this idea, including CrossWorlds, use the ODA to ensure that sessions for the API layer have the identity requested by the AuthProxy.

This principle alone would make me choose to put the AuthProxy in the Green Zone.

Gravatar Image4 - Woah! I'm really loving the templatetheme of this website. It's simple, yet effective. A lot of times it's hard to get that perfect balance between usability and visual appeal. I must say you have done a great job with this. In addition, the blog loads super quick for me on Firefox. Excellent Blog! kkeeebdbfckaegdc

Gravatar Image5 - Totally pent subject matter, appreciate it for selective information. deefbdakeekakecb


This site is in no way affiliated, endorsed, sanctioned, supported, nor enlightened by Lotus Software nor IBM Corporation. I may be an employee, but the opinions, theories, facts, etc. presented here are my own and are in now way given in any official capacity. In short, these are my words and this is my site, not IBM's - and don't even begin to think otherwise. (Disclaimer shamelessly plugged from Rocky Oliver)
© 2003 - 2017 Stephan H. Wissel - some rights reserved as listed here: Creative Commons License
Unless otherwise labeled by its originating author, the content found on this site is made available under the terms of an Attribution/NonCommercial/ShareAlike Creative Commons License, with the exception that no rights are granted -- since they are not mine to grant -- in any logo, graphic design, trademarks or trade names of any type. Code samples and code downloads on this site are, unless otherwise labeled, made available under an Apache 2.0 license. Other license models are available on written request and written confirmation.