This article, and following two articles of the series, is intended as a user guide for developers or system administrators, who need to work with OAuth 2.0 framework (further referred to as OAUTH for simplicity) in their InterSystems product based applications.
When defining a server connection in Atelier we are required to enter a username and password because these are mandatory fields in the dialog. However, if the /api/atelier web application definition on that server has only the "Unauthenticated" checkbox set in the section titled "Allowed Authentication Methods", then our Atelier connection will succeed even if we supply an invalid username and/or password.
I need to offer new users on our system a temporary password that is valid for only 48 hours. This is different than a 60-day password expiration window for existing users' passwords (where a password needs to be
Is there a way to pull a user name and password from the Credentials list that is kept in Ensemble? Right now I have a LDAP user that I have hard coded into my ZAUTHENTICATE, which I would like to get away from.
I was running the %File:FileSet class query, with my development user, but I am unable to run this query for an application user. Does anyone know what resource or service is needed to run this query? Assume the
In part 1, part 2, and part 3 parts of this series we set up three user types. In part 4 we saw how to secure model elements and DeepSee items. In this last part of the tutorial we conclude with some remarks on DeepSee security and troubleshooting tips. In particular, we see how pivot tables in User Portal can be "hidden".
In part 1, part 2, and part 3 of this series we set up three user types. In this part of the tutorial we see how to secure model elements (such as DeepSee cubes) and DeepSee items (such as a folder containing pivot tables and dashboards in the DeepSee User Portal).
In part 1 and part 2 of this series we set up two user types, simpleuser and poweruser. In this part of the tutorial we create one last user type having privileges typically needed by an administrator/developer in analytics.
In part 1 we started working on a security model for DeepSee and create a user type having privileges typical of end users. In this part we are going to create a second user type with ability to edit and create DeepSee pivot tables and dashboards.
I have a few cubes and numerous dashboards and I am ready to deploy them to our end users and administrators. How to configure DeepSee so that users don’t disrupt each other’s areas and are restricted from using functionalities specific to developers?