Caché

Syndicate content 116 

Hi guys!

Suppose you developed a tool, framework, library on InterSystems ObjectScript for InterSystems Data Platform, share it via Open Exchange and want people to install it. 

What is the best strategy if it is a library and supposed to be called from different namespaces?

Here are the following thoughts:

1. Tool's developer should be able to use globals to read/store data the tool needs.

2. Tool's consumer should be confident, that the thing he/she installs will not harm the application's data.

3. A tool should be callable from any application's namespace.

4. Tool's installation(in general) should not request manual security changes (e.g. grant the write access to IRISLIB) and %YourClass is not an option.

5. It's easy to uninstall the tool - just delete the namespace/database (maybe delete some web-apps too).

Last answer 5 days ago Last comment 1 days ago
0 3
107

views

0

rating

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.

Last comment 6 days ago
1 4
3681

views

+ 11

rating

Hi guys,

 

Couple days ago, a customer approached me with the wish to enhance their existing legacy application, that uses SOAP (Web)Services so it shares the same authorization with their new application API based on REST. As their new application uses OAuth2, the challenge was clear; how to pass access token with SOAP request to the server.

After spending some time on Google, it turned out, that one of possible ways of doing so was adding an extra header element to the SOAP envelope and then making sure the WebService implementation does what is needed to validate the access token.

0 1
0

comments

51

views

+ 2

rating