Yeah, it has happened to me too, it seems WRC is not interested in fixing/reporting bugs when any sort of workaround is possible/available, like using a different class in this case.

The community is frequented by InterSystems product managers, developers, sales engineers and many other InterSystems people, maybe out of compassion will report it and will get it fixed, so maybe in IRIS 2026 we will see it fixed! 😂

Fixing this does not seems to be difficult, it's just  matter of filtering/checking the XData block  before (blindly) using it as JSON map.

I'm not holding my breath....

Set sc=##class(%File).GetDirectorySpace("D:",.FreeSpace)

Write FreeSpace

Classreference:

classmethod GetDirectorySpace(Name As %String, ByRef FreeSpace As %String, ByRef TotalSpace As %String, Flag As %Integer = 1) as %Status
Return the amount of total space and free space in either Bytes,MB,GB on a drive or directory
Name = Valid Drive or directory specification
Flag = 0 - Return bytes
Flag = 1 - Return MB (Default)
Flag = 2 - Return GB

MB and GB returned are rounded to 2 decimal places.
Any error status returned is O/S level error. Note that on Windows only drives have a measurement for free space and directories can not so the FreeSpace is only returned for drives.

@Julius Kavay , nice code.

But the point was "more efficiently than using a serialization/deserialization", with this code it takes more than 4 times as serialization/deserialization.

I think that using serialization/deserialization IS very efficient.

@Rodrigo Werneck , are you having performance issues? What makes you think serialization/deserialization is inefficient? Did you measure the performance in your use case?

Enrico

Please note that "%PosixTime values have a 1 microsecond resolution", see %Library.PosixTime class reference documentation.

Then:
USER>set ts="2023-12-12 19:46:19.000"
 
USER>set Posix=##class(%Library.PosixTime).TimeStampToLogical(ts)
 
USER>write ##class(%Library.PosixTime).LogicalToTimeStamp(Posix-18000000000)
2023-12-12 14:46:19

Enrico

Personally I usually prefer to assign permissions to Web Applications and assign to the users only the role necessary to use the application.

Often I don't need/want the user itself to have direct access to resources (i.e. database, tables//classes etc.), what I want is the ability for the user to access/use the Web Application (the FHIR server in this case), then the application itself has the required privilege.

In short, I don't what the user to be authorized to mess with the "internal" stuff...just use the application.

Of course this is a matter of preferences and use case scenario.

Enrico

My guess is that the user does not have enough privilege (role/resource permissions) to access your FHIR server, maybe the database resource?

If so, you have two options:

1) add to the user the required role(s) with proper access to the required resource(s)
2) add to the Web Application the required role(s) with proper access to the required resource(s)

Personally I would prefer option 2.
Just for testing, try to temporary %All role to the Web Application and see if it works.

Enrico

Using correct length of 16 characters for IV and 32 characters key.

This Javascript:

var iv CryptoJS.enc.Hex.parse("00000000000000000000000000000000");
var stringyouWantToEncrypt "HelloWorld";
var base64Key "RXJjb2xpbm9zZW1wcmVpbnBpZWRpMDEyMzQ1Nzg5MDE=";
var encrypted CryptoJS.AES.encrypt(
    stringyouWantToEncrypt,
    CryptoJS.enc.Base64.parse(base64Key),
    {
        iv: iv,
    }
)

And this ObjectScript:

Set text="HelloWorld"
Set IV=$c(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)
Set KEY = "RXJjb2xpbm9zZW1wcmVpbnBpZWRpMDEyMzQ1Nzg5MDE="
Set KEY=$SYSTEM.Encryption.Base64Decode(KEY)
Set text=$ZCONVERT(text,"O","UTF8")
Set sCrypt=$SYSTEM.Encryption.AESCBCEncrypt(text,KEY,IV)
Set sToken=$SYSTEM.Encryption.Base64Encode(sCrypt)
Write !,!, "Encoded -> "_sToken

Both return the same:

Encoded -> 2s4qbUJC6romvsp7TP2L4A==

Enrico

Ciao Barbara,

In your JS code:

var iv = CryptoJS.enc.Hex.parse("0000000000000000");

Convert the HEX sequence to a string, the resulting string made of 8 characters, all with ascii value of zero.
In AES, IV *must" be 16 characters long, I have no idea how your JS library handle this invalid value, IRIS correctly returns an error if IV is not 16 characters long.
The sample in the page you linked uses an IV made of 16 characters, converted from an HEX sequence.

In addition, you are passing to $SYSTEM.Encryption.AESCBCEncrypt() the KEY encoded in base64, in JS th base 64 KEY is decoded before use, so it should be:
Set sCrypt=$SYSTEM.Encryption.AESCBCEncrypt(text,$SYSTEM.Encryption.Base64Decode(KEY),IV)

Moreover, as Ralf pointed out, make sure the key is 16, 24, or 32 characters long

Ciao,
Enrico

Outstanding article, congratulations Kurro! 👏

Just one note on base64 conversion.
In fact you don't need to worry about the base64 conversion, all you need is to set ContentTransferEncoding to "base64" and then %Net.MIME* will take care of it, including adding the header "Content-Transfer-Encoding: base64" in the mime part header.

So, all you need is:

set content.ContentTransferEncoding = "base64"
set content.Body = pImage ; pImage is binary stream

Enrico

I think to remember (I might be wrong) that Service Unavailable error can be caused by a license limit and using csp pages/application can consume license slots quickly due to the sessions not being cleared and license grace period.

Maybe you are using IRIS Community Edition (limited number of connections/license), if so, try to restart and see if it works right after restart.

You may also check in Management Portal in System Operation -> License usage

Again, I'm guessing! I might be wrong.

Enrico