One of the aspects of the app dev pack yet to fully coalesce is the concept of scopes. But I think it will be key to the future, as an app dev and admin tool. It’s certainly something that will not be familiar to those who have never stepped beyond Domino.
First off, if all your application is focused on is Client access or traditional web options, scopes will be irrelevant. “Hide-from” settings on design elements are used to restrict availability of certain design elements from client or web. And there is only one “application” that accesses the application via nRPC (client) or HTTP/S (web) – the one you design. Scopes are really only relevant when multiple interfaces access the application over a single protocol.
Let’s just recap on what’s available for managing access to Domino data:
- ACL levels – Manager, Editor, Author etc. These can be further restricted via the “Maximum Internet Name & Password” setting, which can downgrade the access available for non-HTTP/S protocols.
- Roles. These can be used to restrict access to particular design elements or navigation options.
- Server settings. These include preventing HTTP access, restricting or allowing DAS / DDS or other custom data services. These will be configured server-wide in configuration.
As Dan Dumont confirmed at Engage in response to my question, scopes will work alongside these additional settings, to refine access still further. Scopes were something I came across with Watson Workspace, although the scopes available were always the same via the Workspace Workspace APIs. Presumably different scopes were available internally though. Scopes make a lot of sense when your application is API-first and built in a microservices approach, where your “official” user interface is just one implementation and you want others to access the same APIs via different application interfaces. This is why it’s not relevant to Client or traditional web applications, because they aren’t built around APIs intended to be called from multiple interfaces. So restricting what APIs are available requires you to change the way the application is built in order to leverage them. And if you want to have REST access to a client application, you may refactor some code, but the entry point for Client and REST will be different, so can be handled differently. Even with REST services on an XPage, they’re not typically intended to be called from outside the XPage.
It’s going to require a new interface – definitely via API, possibly editable only via API or console command, but with some interface to report on it. It would probably make sense to be stored alongside the ACL, because it’s specific to the database and user. And the scopes itself make sense to be stored in the database design, because they will be relevant to any implementation. Of course it’s totally valid for database design is managed fully through an API – the database(s) created on-the-fly as needed during runtime, upgraded as required via code too. That’s what I did for the ToDo applications in my IBM Think 2018 session with John Jardin. And scopes have also been manually coded in the past by, for example, requiring additional keys for use of certain endpoints, preventing them from being initialised outside of dev or test environment etc. It’s still early days, and the actual requirements are still being defined, as developers start to come to grips with different requirements for their applications and different ways of building the applications.