User bio
404 bio not found
Member since Jan 4, 2022
Pinned posts:
Replies:

I looked through the source to understand how those links are generated and found this:

When you click the Health button in the Management Portal, the list of namespaces that are displayed in the chooser are linked to the default application of the namespace, which in my case happened to be /csp/<namespace>. That was the reason why the URLs were returning 404. After I modified the namespace default application to be /csp/healthshare/<namespace>, the links started working.

So after I upgraded the container, the web application data was stored in durable %SYS and was not updated on container startup. One has to modify the applications manually or via some method after instance startup (%ZSTART, for example).

Here is a short script that I used to update the default application for all namespaces:

Set $NAMESPACE = "%SYS"
Set oldUiUrl = "/csp/" _ namespace _ "/"
Set newUiUrl = "/csp/healthshare/" _ namespace _ "/"
Set namespace = "yournamespace" // Change this to your namespace or add it as a method parameter that is used to loop through all your namespaces
Write "Checking if app " _ oldUiUrl _ " exists...", !
If (##class(Security.Applications).Exists(oldUiUrl, .oldApp, .status)) {
    If (##class(Security.Applications).Exists(newUiUrl, .newApp, .status)) {
        Write "Switching namespace default application from " _ oldUiUrl _ " to " _ newUiUrl, !
        Set namespace = $ZConvert(namespace, "L")
        Set props("IsNameSpaceDefault") = 0
        Set sc = ##class(Security.Applications).Modify(oldUiUrl, .props)
        If $$$ISERR(sc) {
            Write "Failed to modify application " _ oldUiUrl _ ". Error=" _ $SYSTEM.sc.GetErrorText(sc), !
            Return sc
        } Else {
            Write "Application " _ oldUiUrl _ " modified successfully", !
        }
        Set props("IsNameSpaceDefault") = 1
        Set sc = ##class(Security.Applications).Modify(newUiUrl, .props)
        If $$$ISERR(sc) {
            Write "Failed to modify application " _ newUiUrl _ ". Error=" _ $SYSTEM.sc.GetErrorText(sc), !
            Return sc
        } Else {
            Write "Application " _ newUiUrl _ " modified successfully", !
        }
    }
}

If you have any good tips on how to improve the upgrade process, please share them in the comments.

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.

Open Exchange applications:
Certifications & Credly badges:
Kari has no Certifications & Credly badges yet.
Global Masters badges:
Kari has no Global Masters badges yet.
Followers:
Following:
Kari has not followed anybody yet.