controlling visibility and access to swagger api services

Skip to first unread message

Simon Opper

Aug 10, 2022, 6:34:44 PMAug 10
to TopBraid Suite Users
Hi folks

At SURROUND we've been building a very comprehensive set of script functions covering aspects all the way from s3 data ingestion and data landing, on-the-fly graph validation and automated workflow creation, and auto-publishing to explorers and other graphs. 

It's truly awesome what this deep connection through the EDG stack now supports !  We are just scratching the surface.... Amazing work !

So now that we have a very large set of services setup we want to be able to control who sees these services and where.

Is there a mechanism or recommended approach to control the visibility of API services shown in the generated swagger page ?

We would like to have the following control over the swagger page:

  1. hide dash , TBS, tosh and other "under the hood" type services
  2. hide most of our own services that are used "under the hood" 
  3. generate different versions of swagger pages for different EDG roles - make certain services only available to certain roles and also control read/write depending on role
  4. generate different swagger pages for different graphs - scope certain services to specific graphs. I know changing import closure can do this, but perhaps it can be made conditional on graph params

I first tried using the dash hidden and sh: deactivated flags and found these don't change the api generation.  I didn't try the dash:defaultViewForRole, but assume this may not work either. I guess the js function generation is happening in a separate layer to the intended use of node shapes.

We will have a user base of authenticated and public data consumers and I'm developing an ontology with the intent to control how the api's are logically grouped/themed, exposed and controlled. Ultimately I would also like to support skilled power users to create their own api as part of this control.  

So are there mechanisms available in the usual 'front end' view of resources ?

Or is there control of visibility and access available in the JS script functions themselves once they are generated ?

Many thanks in advance

Simon Opper 

Chief Data Scientist

SURROUND Australia

M    0447 641 837


A    Level 9, Nishi Building, 2 Phillip Law Street; NewActon Canberra 2601 

Holger Knublauch

Aug 11, 2022, 5:01:48 AMAug 11
Hi Simon,

I am glad you find this useful. I don't think we have the filtering capabilities that you seek at the moment. If I understand your requirements correctly, you need a flexible way of filtering out certain services from the generated OpenAPI/Swagger views. I assume you don't want to actually disable the hidden services, e.g. because even TopBraid itself may expect them to be always available.

So thinking out loud, I guess you're asking for a parameterized version of the Swagger page where you can add something like a SPARQL filter condition where you are free to define your own conditions on what should be visible. For example you can annotate services with extra triples and only show those where that triple exists. Or look at the user roles. If the /tbl/service servlet would accept such a filter argument, you could define a new plugin for the Reports page (cloning the existing teamwork:ServicesSwaggerPlugin) or add such hyperlinks from elsewhere.

Would this be sufficient?



You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Reply all
Reply to author
0 new messages