once you assign an user to a role in a Volt app, then there is a Domino ACL entry created for that person on the corresponding NSF file. The person receives and Author access level with create (and delete) permissions. The access to a particular document (a submitted form in Volt) is further controlled by $VoltAuthors and $VoltReaders which are managed internally by Volt.
The problem is, that every Volt app users knows the app id from the URI, such as https://voltserver.acme.com/volt-apps/landing/org/app/05388da5-5a4c-4c67-88df-a2aa63edd290
Then user can construct a URI such as http://voltserver.acme.com/volt/05388da5-5a4c-4c67-88df-a2aa63edd290.nsf and get access to all fields of all submitted forms he has got assess to (as controlled by $VoltReaders) or export all documents into XML by ?ReadViewEntries:
In other words, if you Volt app hides some information from users, they can read (or modify) them via Domino web access which is enabled by default. Let's say, that your app allows user in "Department Manager" role to approve request only from their departments only. However, by this "hack" they can see requests from all departments. Unfortunately, in Volt we can assign role permissions only for stages, so the $VoltReaders must be set for all documents in NSF (in the corresponding stage?).
The remedy is quite simple, you have to disable URL open feature:
You need also to block users having access to the Volt server from Notes client. This can be achieved by a Domino passthru server or at network level.
The documentation on Domino ACL in Volt is rather brief https://help.hcltechsw.com/domino_volt/1.0.4/post_install_tasks.html so I would like to ask somebody from HCL to comment on my findings.
You could also "prepare" the VoltApp template NTF by adding a $$ViewTemplateDefault form to prevent seeing any view. With every new Volt app that is created, the modified template will be used and "automatically" will have this element - so no view access anymore :-)
In the particular example, depending on application design, it would be possible to using open roles to only assign the approver role dynamically for documents in that person's department. That way, the person would only see the documents for the departments they could approve, as they would only be listed in the readers/authors fields for those particular documents.
That said, this is very similar to the case of script access to documents that have hide/whens on them. It's true that the fields on the form don't have hide whens based on the Volt conditions - it is not really feasible to do that mapping. If this is a concern, Jan's suggestion of using the don't allow URL open property is a good one.
We don't want to block integration use cases, or extension of the Volt app with "normal" Domino design artifacts - so it is unclear what the default should be here, but that property is one way to solve the issue.
The security model is working as designed. Users are able to see documents for which they have been given permission to see, based on settings made in the Access tab. That being said, this post does raise some follow-on discussions:
Should the product include more robust granular control of ACLs at the field level, for all channels (ex. various REST API's, various Notes/Domino clients)? This is a significant feature request for the product, so if you think it is important then please raise and/or vote for this in our ideas portal.
Should our notion of "Instance Creator" include "Anonymous Users"? At the moment it does, but perhaps it shouldn't.
Should the default permissions for new Volt application be more restrictive?
Should we disable Domino web access to our views by default, and let the Domino-savvy author enable them if they have a use-case for it?
How much effort should we be putting into the functional parity of our generated Domino views and forms (including field-level access control)? Again, this is a significant amount of work so if you think it is important then please raise and/or vote for this in our ideas portal. Specific use-cases are likely the key to success here.
thanks for your answers and I agree with you. IMO the biggest problem is the missing detailed documentation. And my answer to Rob's question are:
the ACL shall work the same across all channels
I am fine with that but I feel it is a licensing issue atm
no
definitely yes
I do not call for it but I am not a Domino admin/developer. It would be more useful to describe which NSF "enhancements" are compatible with Volt. For example, whether we can add our own agents for features which are beyond current Volt capabilities.
on the licensing issue - we are working on fixing the license, because anonymous access is a feature we added to the product intentionally.
As for what you can do with the nsf - it's a real nsf :-) You can add agents, script libraries, forms, views, etc. to customize the application for other facets. Now the Volt data in there is going to be subject to all the readers/authors/acl settings from Volt. But we have taken care... If Volt thinks a person should have Reader access in the ACL, but for other facets of your application Designer access is required, we will not lower that person's access in the ACL.
The subform that contains all the fields on it for the Volt form is (almost) completely rewritten on redeployment, so should *not* be customized, but the form that contains that subform is hardly touched - so that if you want to customize that form for use in the client (or wherever), it should survive a redeployment. So care was taken in architecting the nsf projection to allow integration/augmentation with Designer.
First, please understand that the security model of Volt is working as designed. A key design goal with the product is interoperability of use and design between the Volt applications and customized builds in the Domino design environment. Just like an application created with Domino Designer, if you have access to content, you can access that content through a variety of means. If you don't have access to the content, you won't be able to see it. Volt uses reader and author names at the document level to ensure this.
Now, if you want to prevent someone accessing deployed Volt application content directly using the Domino URL command syntax, you can. Just create a web site rule.
I tested this by creating a Web Site "Redirection" rule. For the "Incoming URL Pattern" I used "/volt/*" and I redirected to "/HelpfulInformation.html" which I created in the /data/domino/html/ directory and put a paragraph of text in explaining why you couldn't use that url syntax.
You can be specific about which volt applications this applies to as well, but being more specific with the "Incoming URL Pattern". For example, you can create a redirection rule specifying "/volt/4e5b65ce-004d-4099-8c95-a7e5dd860cbf.nsf/*" to redirect requests only to that database. You could have as many of these rules as you want, and each could point to a different alternative URL if you are so inclined.
The best I can find is > http://second-ext.inttrust.ru/Lotus/NotesWeb/Today.nsf/DisplayForm/B86A878B9AE5EE0D85256AD8000813A6?OpenDocument
But it still doesn't help me solve this issue, so in the end, I went with the 16 Web Site Redirection Rules, and now it works properly. Logout works again, and direct access still triggers the HTML Page.
I see your point, however if Volt is considered a low-code tool, then Volt developers shall not be in need to change Domino webserver configuration :-) Even more, copying app IDs from Volt both ugly and error-prone.
