Known issue

AddEventToSessions authentication changes 19.0.23234.7027

ctaylor 3 years ago updated 2 years ago 7

I manage a PowerShell module that interfaces with Control. 19.0.23234.7027 makes changes to the `AddEventToSessions` endpoint. I am trying to use `Invoke-RestMethod` with the Credential switch. This will create a RFC 7617 basic authentication header and verify that communication follows that standard as well. This method has worked in the past and seems to still work on all other endpoints. With 19.0.23234.7027 I can manually create the header and things work. I am not sure if you are purposely breaking RFC or this change was over looked. Some sort of notice on this issue would be great so I know how I should fix my module. 

ConnectWise Control Version:
Server Affected:
Host Client Affected:
Guest Client Affected:
Known issue

We now require an additional header, "Content-type: application/json" on web service requests.

You have a good point about our communication on these types of changes. I'll bring this up with the team.


I am supplying content-type information. I am using other endpoints under `PageService` (GetSessionDetails,GetHostSessionInfo, UpdateSessionName, etc.) and they act as expected. It is only `AddEventToSessions` that seems to have this behavior. 

Ah, I see that you are. Are you getting a particular error message?

I can send a request to AddEventToSessions just fine with Postman (also on a 19.0.23234.7027 instance).

Correct if I manually create a header instead of letting `invoke-restmethod` create the header it will work fine. When letting iwr create the header it will make sure that other communication standards are met as well. I assume that it is one of these other standards that are not being met. See an example of how github breaks this standard causing similar issues.

I am actually not getting an authentication error. I get an error that the session is not in the specified group.
`errorType:InvalidOperationException, message:Session not in specified group., detail:null`

Please see new branch that shows needed fix to resolve the issue. I can get around the issue but seeing as this is the only endpoint that seems to be effected I assume there are other things that might be going on.

Also on 19.0.23234.7027 and wanted to correlate what Chris is reporting. Confirmed that this is the case when using .Net. Content type was already set to application/json, but passing credentials in the WebRequest didn't work only for AddEventToSessions. Creating a basic header manually and adding that to the WebRequest does work. I just copied the same technique Chris used in the powershell module.

HttpContext.Current.User.GetUserDisplayNameWithFallback seems to be coming back blank without the manually created header, as does Permissions.GetEntriesForUser within the ExecuteSessionProc function.Seems the userName isn't getting picked up correctly?

This issue was marked as a known issue in relation to "Content-type: application/json" but that is not the issue. Knowing if the changes to AddEventToSessions are working as intended or if there is an issue that will be resolved would be great so I know how to patch my module. 

Commenting disabled