Thanks for the input, it was obvious when somebody else pointed it out.  I managed to import that sample XML to that object!

Cheers

Hi,

Thanks for the response. I upgraded the container to 2021.2.0.617.0, and it seems the FHIR metadata gets populated with the security related data correctly now.

Thank you very much for the input and have a good day!
Kari Vatjus-Anttila

Thank you for the response.

It seems to work! I set the database permissions to read-only during my Installer script and it seems that the Code database is where it should be and is not persistent. Thank you very much for your responses.

I couldn't set the permissions via the Installer Manifest so I ended up writing a small ObjectScript script to achieve this. Here it is for future reference:

/// Change database permissions
/// <ul>
/// <li><var>dbDir</var> Path to the database.</li>
/// <li><var>mode</var> Permission mode. 0 = read/write, 1 = read-only. Optional</li>
/// </ul>
ClassMethod SetupDBPermissions(dbDir as %String, mode as %Integer = 0) As %Status {
  New $NAMESPACE
  Set origNs = $NAMESPACE
  Set $NAMESPACE = "%SYS"

  Set sc = $$$OK

  Set db = ##class(SYS.Database).%OpenId(dbDir)
  Write "Setting database permission for " _ db.Directory _ ". Setting ReadOnly from " _ db.ReadOnly _ " to " _ mode, !
  Set db.ReadOnly = mode
  $$$ThrowOnError(db.%Save())

  Set $NAMESPACE = origNs
  Return sc
}

Nope, does not make any difference. I checked out the extensions code and I suspect (I might be wrong) that the issue is here:

https://github.com/intersystems-community/vscode-objectscript/blob/mast… Line 289

    const agent = new http.Agent({
      keepAlive: true,
      maxSockets: 10,
      rejectUnauthorized: https && config("http.proxyStrictSSL"),
    });

rejectUnauthorized is going to be true if the scheme is using HTTPS (which I am). If that is the issue, it would be great if this parameter could be overwritten with some general setting provided by the extension for example "Allow Insecure connections".

That works! I must admit, I was a bit perplexed that why setting "http.proxyStrictSSL" to true didn't have any effect but the property you suggested made the difference.

Like Brett said, maybe somebody should re-write the line so it doesn't cause any further confusion among users :)

Cheers and thanks for the quick help yet again!

That was fast!

I downloaded the extension and tested it. It works. 

I removed the objectscript.http.proxyStrictSSLproperty and set proxyStrictSSL to true -> connection failed as expected: VSCode notified that the server is using a self-signed cert. Next, I set proxyStrictSSLto false and tried to reconnect -> connection ok and VSCode prompted me to choose the namespace I want. 

Thank you for your effort, it seems like your change works as expected.

//Kari

Hello,

"Have you made further changes to TestCoverage.Manager"

No, only that if-clause which checks if Coverage related flags are set.

I am not that familiar with the Mocking Framework yet to know if the unit test manager causes any issues. I thought that setting -DUnitTest.ManagerClass=TestCoverage.Manager overrides the unit test manager. I verified that by adding some debug logging to the TestCoverage.Manager class.

At the moment, my solution works as expected. If you manage to find any clues why it does not work, I am very interested to know.

By the way, where exactly are the arguments CoverageReportClass and CoverageReportFile checked? I didn't find any trace of them in the source code.

Hi,

And thanks for testing out the filter @David Foard 

The example I showed is quite simple. Everything (markdowns, src, etc.) reside in the same repo so the Doxygen configuration is simple.

In your case I believe you need to link external documentation to your project, which is in another repo. Check out this link: Linking external documentation.

Also, here you can find all the configuration options Doxygen supports: Doxygen Configuration Reference.

- Kari

Sure, I will submit the solution to Open Exchange. Thanks for pointing that out @Evgeny Shvarov 

Thanks for sharing your thoughts. When you have lots of REST APIs to deal with, it's a real hassle to split them into secure and non-secure apps because it makes maintenance complicated. Plus, the way JWT authentication works in the web app seems pretty basic and doesn't handle scopes properly, as per the docs.

In cases where you're using an external OAuth 2.0 token provider, not IRIS, and you want an easy way to check those tokens in your API, this solution still makes sense.

However, it's important to note that JWT signatures should be validated if they are signed. You can achieve this in a couple of ways: by using an OAuth2 Client defined in IRIS, which contains data about the token server and by using the %SYS.OAuth2.Validation class's ValidateJWT method to validate the token. Alternatively, you can utilize a predefined JWKS_URI parameter inside the REST implementation class to facilitate the validation process.

I'll take a look at the JWT validation using these two methods and update the post accordingly.

Thanks, Kari

I'll send you a DM about this. Most likely, it's a configuration-related issue in GitHub. One thing to note is that you have to select the source branch for Pages deployment as the gh_pages branch.

@Rich Taylor

You've raised some excellent points, and it's certainly something I need to consider for the future. Thank you for bringing up Delegated Authentication. I'll make the necessary modifications to the article to emphasize that Web Applications should not be granted %All permissions but rather only the permissions that are essential for the API usage.

An interesting approach, but it involves custom tinkering with internal classes. Ultimately, it comes down to personal preference, but I tend to favor building on top of verified and tested implementations, reserving the extension of InterSystems base classes as a last resort.

In my approach, there's no need to modify any class implementations. Instead, you can simply use a utility method for validation. As previously discussed, these methods should be invoked as part of the normal authentication process, not within the API implementation, as Rich Taylor mentioned.

If I understand your solution correctly, the client sends a request, and the logic checks whether the application has the correct privileges. Does it also verify whether the provided credentials are accurate? In my method, I verify Basic Auth credentials via $SYSTEM.Security.Login() and then use $SYSTEM.Security.Check() to confirm whether the user in question possesses the required privileges.

I'll need to explore Delegated Authentication in IRIS and adjust the article accordingly.

Hi @Tani Frankel 

I ended up using Data Element Encryption (https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cl…) together with Production Credentials to store my secrets for 3rd party APIs securely, because in my use case that was way more easier than dealing with password vaults.

I encrypt my secrets using the data element encryption key I created (and activated), and then add them to Production Credentials encrypted.

When I need to use the credentials e.g. in a HTTP Operation, I just get the credentials I want and decrypt them with the same key just before sending the request.

I implemented a simple class which handles these tasks for me so I can just call Encrypt() and Decrypt() to get my ciphertext / plaintext when needed.

Let me know if you need more assistance with this approach.

Br, Kari