Elevation property in request header does not work

[alxy]

Describe the bug

The documentation for the CredentialModel is a bit mis-leading for the end-users when using the configuration API. For example, we were using the NodeRead action, and there are two places where you can give the authentication information. Once in the ConnectionModel (user section) and once in the ReadRequestModel (header.elevation) section. We needed to go through the code to see which of the both is actually being used.

Expected behavior
Maybe add to the docs where the username and password have to be passed for the actual authentication with the server. I would also like to know what this elevation section actually means, as I didnt really find any content on it online.

[marcschier]

The Elevation property in the request header (as well as the locales) were a holdover from OPC Twin (2.8). They allowed an elevation for a particular service call. In 2.9. OPC Publisher supports most of OPC Twin API, but porting the elevation behavior was not done. I will fix this to override the connection information should the header specify elevation (or locales). The recommendation is to use the connection model's User property, then there should not be surprises. Hence no need to update the docs.

[marcschier]

#2241

[alxy]

The recommendation is to use the connection model's User property, then there should not be surprises.

I would in this scenario recommend to remove the elevation section entirely from the request payload - or what is the intention/use case to keep it now (except maybe for backwards compatibility)

[marcschier]

Agreed, but we need it for backcompat (unfortunately).