Hi!

You don't actually need to configure a certificate on your Apache or even to encrypt the communication between Apache and the SuperServer with SSL/TLS.

You can create a CSP Application that is Unauthenticated and give it privileges to do whatever your web services need to do (Application Roles - more info here). I would also configure a "Permitted Classes" with a pattern to only allow your specific web services to be called. I would also block CSP/ZEN and DeepSee on this CSP Application.

More info on configuring CSP Applications here.

Then, for each web service you want to publish on this application (that is mentioned on the Permitted Classes), you will create a Web Service Security Policy using an existing Caché Studio wizard for that (more info here).

The wizard will allow you to choose from a set of options and several variations for each option on securing your web service. You may choose from the combobox "Mutual X.509 Certificates Security". Here is the description for this option:

This policy requires all peers to sign the message body and timestamp, as well as WS-Addressing headers, if included. It also optionally encrypts the message body with the public key of the peer's certificate.

You can configure Caché PKI (Public Key Infrastructure) to have your own CA (Certificate Authority) and generate the certificates that your server and clients will use.

This guarantees that only a client that has the certificate given by you will be able to authenticate and call this web service. The body of the call will be encrypted. 

If you restrict the entry points of this "Unauthenticated" csp application using "Permitted Classes" and if these permitted classes are web services protected by these policies, you are good to go. Remember to give to this application the privileges (Application Roles) for your service to be able to run properly (privilege on the database resource, SQL tables, etc.).

This doesn't require a username token. If you still want to use a username/password token, you can require that using the same wizard. Here is an additional description that the wizard provides:

Include Encrypted UsernameToken: This policy may optionally require the client to send a Username Token (with username and password). The Username Token must be specified at runtime. To specify the Username Token, set the Username and Password properties or add an instance of %SOAP.Security.UsernameToken to the Security header with the default $$$SOAPWSPasswordText type.

If you decide to do that, make sure your CSP application is configure for authentication  "Password" and do not check "Unauthenticated". 

Also, don't forget to use a real Apache web server. My point is that you don't need to configure your apache or its connection to the super server with a SSL certificate for all this to work. Caché will do the work, not Apache. Apache will receive a SOAP call that won't be totally encrypted. But If you look into it, you will notice that the body is encrypted, the header includes a signed timestamp, the username/password token will be encrypted, etc, etc. So, although this is not HTTPS, the certificates are being used to do all sort of things in the header and the body of the call that will give you a lot more protection that plain HTTPS.

But please, don't get me wrong. You need HTTPS if you are building an HTML web application or if you are using other kinds of web services such as REST, that don't have all the alternative enterprise security provided by SOAP. SOAP can stand alone, secure, without HTTPS. Your web application can't. 

But I miss a lot a nice For Each sugar... This:

ForEach MyVar(key) 
{ 
    Write !,key 
} 

Is much better to read than:

Set key=""
For 
{ 
    Set key=$Order(MyVar(key))
    Quit:key=""

    Write !,key 
} 

I mean... We write code like this all the time, right? Locals and Globals are so important to us... Why not giving them some sugar?

Of course that the ForEach command would only try to $Order the last variable just like it works today with $Order. So instead of:

Set key1=""
For 
{ 
    Set key1=$Order(MyVar(key1))
    Quit:key1=""
 
    Write !,key1

    Set key2=""
    For 
    {
         Set key2=$Order(MyVar(key1, key2))
         Quit:key2=""

         Write !,$C(9),key2 
     }
} 

We would have:

ForEach MyVar(key1)
{ 
     Write !,key1
     ForEach MyVar(key1, key2) 
     { 
          Write !,$C(9), key2 
     }
} 

Much clearer and nice to read, don't you think? And if you really want to be fancy:

ForEach MyVar(key: value) 
{ 
    Write !,"The value for key ",key," is: ", $Get(value)
} 

Where value could be <UNDEFINED> if that local/global node ends up having no value defined (that's why the $Get on value).

I know it would be a lot of work, but, on a side note, It would be awesome if we could open up our virtual machine and give people the tools necessary so the community could implement other languages for our virtual machine. We could move our VBScript and TSQL implementation to this new, open, framework and have people use it as templates to build their own languages or language improvements.  I know building a compiler is not an easy thing and there are things that you have to hammer on the code. But it would be an interesting challenge and investigation project.

Here is my wish list (from the most important to the most desirable):

- There were more frequent releases. Why waiting months for the next release... If there is a small harmless feature that is good to go, why not publish it on a new release? 

- Support for seeing the other (.cls of CSP, .cls of a CLS, .int of a MAC, etc.) and the ability to jump to a relative location inside the INT: zNameOfMethod+10 (for instance).- Support Javascript syntax coloring on CSP

- Support for javascript files with long lines (such as the "min" version of javascript frameworks such as jquery or bootstrap). Atelier will mark these files with an error flag even though they are ok.

- Support for opening Management Portal of a specific server connection

- Support for using Studio wizards of a specific sever connection

- Support for seeing a CSP page (like when we click on the globe icon and the CSP page opens)

- Being faster

- Support for the Add Relationship wizard to classes

- Support for the other wizards such as add index, add property, add method, etc. These wizards are very good for beginners that don't know CDL or COS. I always use these wizards on my Sales demos because people then realizes that it is very easy to use our technology.

- Better testing with common source control plugins like GitHub, specially when developers are using a mix of operating systems (windows, linux and mac). There are many problems with CRLF x CR and character encoding. When the source is uploaded from a Windows machine into GitHub and downloaded on a Mac machine, it will synchronize with the server that will then change the CRLF to LF and make Atelier think that I touched the source when I didn't. The git diff then will add all those files to my pending GitHub list of files and I will have to upload them again to GitHub for them to disappear. I have only solved this problem by making all developers work with the same combination of encoding (utf-8) and end of line character (LF) on all platforms. My suggestion was that Atelier should be forcing UTF-8 and LF on all platforms to eliminate this problem.

- Support of a plugin to run SQL queries on the database with SQL syntax coloring, code completion etc. like WinSQL or Squirrel does. I mean: We could have Atelier installing some plugins that any developer would need. The same goes for UML editors that could allow us to see the application model more clearly.

I have not. In fact, I don't want to do it because I want to install the csp gateway under a folder called /aupoldb/cspgateway instead of /opt/cspgateway.

That is because this folder is a logical volume system (lvs) and the plan is to have a snapshot of aupoldb file system (that is mounted on /aupoldb and includes caché on /aupoldb/cache and CSP Gateway on /aupoldb/cspgateway) before any patching so we can quickly rollback the entire filesystem if anything goes wrong with the patching.

Apache default installation is on /etc/httpd that is on the root logical volume. I wasn't planing on doing a snapshot of the root logical volume when patching Caché or CSP Gateway. At most, I would be saving httpd.conf before doing it as part of the backup procedure...

I just realized that CacheGitHubCI will try to load classes from GitHub as XML. As I am using Atelier with the Eclipse GitHub plugin, the source code on GitHub is not stored as XML but as the source we see on Atelier when editing the class/csp/etc.

I can contribute to CacheGitHubCI, but before I do it, I wonder if anyone has implemented a new version of CacheGitHubCI that will load source as exported by Atelier...

I just realized that CacheGitHubCI will try to load classes from GitHub as XML. As I am using Atelier with the Eclipse GitHub plugin, the source code on GitHub is not stored as XML but as the source we see on Atelier when editing the class/csp/etc.

I can contribute to CacheGitHubCI, but before I do it, I wonder if anyone has implemented a new version of CacheGitHubCI that will load source as exported by Atelier...