Yes you absolutely don't want to hard code those in the code. You have two options: 

1) have a login form which will ask for those and save them in either local variables (will have to enter login password after each page refresh) or local storage (not secure because password is available in plain text). You can try some silly endpoint like _ping to check if it returns 200 or 403 to check if credentials are valid. 

2) use web sessions and store session information in cookies. Here you can use usual iris login page to authenticate, but it's not rest best practices because use of session is discouraged

Or 3) set up and implement jwt authentication as described in documentation https://docs.intersystems.com/iris20242/csp/docbook/DocBook.UI.Page.cls?...

I'd say from my experience, best for security and production use is 3, most people implement 2, and 1 is only good for prototyping/experiments because it's not secure

Hi Stephen, this is a valid approach however you will lose information about problematic calls such as json can't be parsed or API key in headers is wrong. I prefer to actually save the http call in full as http generic message and then call a process or operation with transformation to the proper message format, as Alex demonstrated in his third example. You can still call operation manually if you want, passing the parsed message. 

Hi Bob,

That's good news and I like new names much more than old ones. I hope old tags for old releases will still be available?

A couple of entries from my container tagging wishlist (one can dream, you know)

- provide :latest tag for all containers, but especially for community ones, which will just pull the latest working release without having to rebuild dockerfiles every year when license expires

- provide 2023.1.x tag which will follow the latest minor version