We have always used independent web servers for production.

However, with the release of container deployment, can I get clarity on the webgateway container provided by ISC is NOT affected by the same vulnerabilities? I understood this to be a full apache instance with modules pre-installed.

If so, are there any recommended practices one should use for this container in a production environment?

Hi John.

I don't allow SMP interaction due to this binding. We have a strict policy internally in the sense  that noone can checkout and modify anything unless "bound" to a project. As such the VC project ensures that on checkout of an existing file, and/or on checkin of a new file, a project name is associated. This is then additionally linked to our R&D system for the official bugfix/requirement and associated comments.

Still waiting on a supported method of more visibility to look Atelier as a viable alternative for us.

All i need is a visible project name as i think they now cater for exposure of the full package.classname.

I could modify the version control software to do away with this concept and insist on manual selection of the log in R&D but thought it simpler to ask for the exposure of one variable from Atelier to make it all work.

Still waiting :)

Excellent, thanks. The security setting on the api/atelier/ application has performed exactly as you described.

Regarding the use case for the project name, we have a tight binding between project names and version control.

e.g. A Defect # is raised in our tracking system for code change. Currently, a cache studio project of the same name is utilised and all files in relation to the defect are associated to the cache studio project. This int turn is reflected in our cache source control system creating a binding between the file(s) involved in the correction and the project name they are linked to.

Assuming Atelier is now the source of truth for project names, we need to be able to bind this into our source control tracking process.

Maybe all the environment variables could be passed in to the process? e.g. resource_name, project_name, etc

Bill, I have developed our own Cache based solution that is hooked into our build process too. To utilise Atelier in future versions without compromising the effort put into SC hooks, what would be useful is an example Eclipse/Atelier project as an add-in for launching web pages as custom menus. Such that they can be added to and emulate the existing capabilities offered in Studio of calling web pages from such menus that can utilise the concurrent license login of the operator connected to the cache DB. Additionally, the ability to trigger such actions based on existing capabilities at edit time to co-ordintate the current edit state on the server. I assume this would be an option exposed via the REST inrterface.

We could only move forward with Atelier in 2016+ with support for such hooks and only really need a guiding Eclipse add-in project with appropriate REST calls available as example to build our own add-in.

Without this, we would need to continue to work with Studio on PCs and Servers which i assume will be an option.