Hi Eugen, 

Groupshare backend services hosting Rest API endpoints require the Authorization header to be set. Most of the times this is the only required header. If it's missing authorization will fail. Can you detail maybe what headers you see going through WebSeal and what you consider as missing?

There is no setting that you can configure for running behind a proxy, as Groupshare doesn't need to know it's behind a proxy. This needs to be configured from the proxy, either to not remove specific headers or to re-add it. 

Maybe this section in WebSeal documentation can help out: https://www.ibm.com/support/knowledgecenter/en/SSPREK_9.0.6/com.ibm.isam.doc/wrp_config/concept/con_http_transforms.html. As noted there "WebSEAL administrators can configure the following modifications. You can apply these transformations to HTTP requests and HTTP responses (except where otherwise noted):

• Add a header
• Remove a header
• Modify an existing header"

Hello, has anybody tried to run Groupshare 2020 behind WebSeal? Everything works, except of Reporting module. Dashboard screen ends with 500 error.  IIS log shows /api/authentication/token/reportingSignIn with 500 error.

If you are on GroupShare 2020 CU03, there should be additional error details logged in the application service logs.

In CU04, this problematic "reportingSignIn" will actually be removed.

The general idea/problem is as follows:

When a user logs into the website:

1. The http request "http(s)://<servername>/api/authentication/token/reportingSignIn" is sent as follows:

Browser -- Network (including proxies, if any) --> GS Web Server (IIS) --> GS Application server (Application Service)

This request contains "requestOrigin" in form data, which is generally set to the URL via which the user accesses the GroupShare website.

2. Then the application service (on the application server) sends a further http request to

<requestOrigin>/Reporting/rdTemplate/rdGetSecureKey.aspx

This request is supposed to reach whe GS Web Server (IIS).

If it fails, the original reportingSignIn will be failed with a 500 status code.

So, until you upgrade to 2020 CU04, you would have to ensure that the request <requestOrigin>/Reporting/rdTemplate/rdGetSecureKey.aspx originating from the GS Application server (Application Service) can successfully reach the web server.

Possible problem that can occur or I could image:

A) The server name in requestOrigin cannot be resolved on the application server or is resolved to the wrong machine

B) If https is used: ssl secure channel cannot be established (depends on your network setup)

C) (never saw this, but possible your case) the request from application server to web server goes via proxy and proxy requires authentication. Probably the application service does not know how to authenticate with the proxy.

In any case, first step would be to check Application service logs ("C:\ProgramData\SDL\Service\Logs\Sdl.Application.log") whether anything is logged at the time of the failed request.

Thank you for your comprehensive answer. It perfectly complements everything what I found out by analyzing our logs, but communication from application server to web server is quite problematic and unexpected and that is the cause why it fails.

The only way is to use proxy, so I would like to ask how to set proxy for Groupshare to use it correctly for this situation?

Maybe better solution is to avoid this "reportingSignIn" and "rdGetSecureKey" in such a way at all, so I would like to ask when CU4 will be ready for download?

And one more question - in CU4, is there any other communication from application server to web server that is initiated by application server except "rdGetSecureKey"? 

Hello!
Sorry for the late answer, it seems the forum does not want to send me notifications about responses!

"The only way is to use proxy, so I would like to ask how to set proxy for Groupshare to use it correctly for this situation?":

- I dont have any specific instructions at hand (and instructions tend to not cover all special cases anyway), but if proxy authentication is the problem, you may want to check out https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/network/defaultproxy-element-network-settings and apply this to "C:\Program Files (x86)\SDL\SDL Server\Application\ApplicationService.exe.config" (and ExecutionService.exe.config; this is a feature provided by the .NET Framework, so public documentation will be more extensive and accurate than what SDL can tell you.

This of course assumes that proxy authentication is the problem. To confirm, if you have CU03, you may want to check the logs to confirm this, in a previous version you might have to run a network trace (for outgoing requests from SDL Application Service) to confirm.

"so I would like to ask when CU4 will be ready for download?"

- I dont have official information regarding that, but should be "soon".

" is there any other communication from application server to web server that is initiated by application server except "rdGetSecureKey"? "

- Yes, especially when creating projects on the website or via the RestAPI (but also for a minor number of other features, e.g. viewing project settings and project templates on the website), requests are sent from the application server to the URL of resources used in the project (TMs). The URL is generally referring to the external server address. Unfortunately, I do not have a complete list of possible requests for this.

Hello!
Sorry for the late answer, it seems the forum does not want to send me notifications about responses!

"The only way is to use proxy, so I would like to ask how to set proxy for Groupshare to use it correctly for this situation?":

- I dont have any specific instructions at hand (and instructions tend to not cover all special cases anyway), but if proxy authentication is the problem, you may want to check out https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/network/defaultproxy-element-network-settings and apply this to "C:\Program Files (x86)\SDL\SDL Server\Application\ApplicationService.exe.config" (and ExecutionService.exe.config; this is a feature provided by the .NET Framework, so public documentation will be more extensive and accurate than what SDL can tell you.

This of course assumes that proxy authentication is the problem. To confirm, if you have CU03, you may want to check the logs to confirm this, in a previous version you might have to run a network trace (for outgoing requests from SDL Application Service) to confirm.

"so I would like to ask when CU4 will be ready for download?"

- I dont have official information regarding that, but should be "soon".

" is there any other communication from application server to web server that is initiated by application server except "rdGetSecureKey"? "

- Yes, especially when creating projects on the website or via the RestAPI (but also for a minor number of other features, e.g. viewing project settings and project templates on the website), requests are sent from the application server to the URL of resources used in the project (TMs). The URL is generally referring to the external server address. Unfortunately, I do not have a complete list of possible requests for this.