Best way to get data from restricted database with XPages

0
votes

I'm working on two Domino databases that contain XPages :

  • the 1st database is a public database,
  • the 2nd one is restricted to a group (let's say the HR team)

I'm building an XPage in the public DB and I need to populate a sessionScope variable with the data of the HR's database (for example the HR id of the user)

So, as the normal users will not have access to the HR DB, a @Dblookup is not allowed.

Using sessionAsSigner method needs to re-sign all elements of the db each time a developer is modifying a XPages component (otherwise the sessionAsSigner element is unknown).

Then, how to query a database that I do normally not have access ? Do I have to call an agent with higher access than the connected users ? And then, how to populate the sessionScope variable ?

Any help will be greatly appreciated

1
xpages
sessionAsSigner is the right thing to use. You should anyway sign your databases in production with an "official" id (not a developer id). – Knut Herrmann
Knut, I agree with what you said, but during the development phase, it can not be done like you recommended, specially in case of we are a team that works on the db. It slows down the development phase. – Techn0fil
Can't you give developers access to restricted database during development phase or can't you create a copy of restricted database with test data and test against this database? – Knut Herrmann
Knut, thx to think again about my question. All the developpers have access to the restricted DB in development environment. The pb is not to access data during the development phase, the pb is to build an access to some data in the restricted db for the end users once the application will be in production. So, if we use the sessionAsSigner method, it will work, but, during the development phase, we have to re-sign the application after each modification made by another developper. – Techn0fil
If you just need to lookup some values, you could create a view with public access and use the good old "category security hole" – Sven Hasselbach

1 Answers

3
votes

There are a few options, but as Knut says, without a shadow of a doubt, the best practice approach is to use sessionAsSigner.

Source control can be used to allow multiple developers to work on their own instance of the design. Swiper can be used to suppress signatures from the source control repository to minimise conflicts.

All other options I can think of (e.g. periodic exports, using a runOnServer agent) will take longer to code, be more complex and will require you, as the developer, to manage the security implications of exposing the data.