WebNotification.axd URL cannot be Validated

[jliberta]

Hello,

We have an issue with the CRM WebNotification solution. It is unable to validate the WebNotification URL we have provided in the settings when we click Save & Publish. When we browse to the URL + /WebNotification.axd we get a response with an "OK" displayed on the screen which is expected as per the Wiki on this topic. As a result we cannot update web notification entities and CRM changes are not propagating up to our portal. Is there a problem with the CRM solution or the configuration in the portal Web config?

Any help is appreciated.

Thank you,

Julien

[amervitz]

Are you able to navigate to the URL from the CRM server itself? The portal URL cannot be referenced via an IP address and must use a fully qualified domain name.

[jliberta]

Hi,

The CRM instance is a Dynamics 365 online one. We don't have access to the actual server. We can navigate to the WebNotificate.axd URL from our computers and IIS web servers no problem. It gives the "OK" message, but when we enter this exact URL in the Settings in CRM and then click save and publish, D365 can't validate this URL so the web notifications are not saved.

[amervitz]

D365 can't validate this URL so the web notifications are not saved

Please elaborate on this, what is the failed validation you are seeing. Is there an error message? A screenshot would help.

[jliberta]

This is the error we receive in the solution.

[amervitz]

You could try looking at plugin trace logs and the JavaScript console to see if any additional information is provided. The CRM solutions aren't part of this project so there is limited support we can provide. Microsoft did not open source them.

[jliberta]

Looks like it was a CORS error, do you know if Cors is enabled by default in the community edition? We had originally modified the web config to allow custom headers such as Cross Origin Allow Access and it seemed to be giving us problems, but now we removed it and there are no longer any CORS limitations.

[amervitz]

I'm uncertain if there is anything that specifically enables cross-origin requests, nothing stands out at a glance in the web.config file at least. It could be that by enabling CORS in the web config, the web notification plugin then became subject to CORS which it probably hasn't been programmed to follow.

[jliberta]

I see, for now it seems to be working. I will report if I have any other weird findings related to this.

Thank you for your help!

[jliberta]

After further review (4 hours +) we've determined that the web notification solution sends 2 origins in the header of Access Control Allow Origin, enabling this in Web.config causes an error because it only allows 1 header, not multiple. I believe a ticket must be opened with Microsoft for this.

[amervitz]

The plugin is unlikely to be updated, the solutions were distributed as a one time release in managed form without any support.

If you can describe the steps you took to set this up and the diagnostic information you see, we can see if there's a workaround.

[jliberta]

Hey,

So the set up that was causing the errors was done in the Web.config, we originally had a section defined as follows: `

  </httpProtocol>`

This essentially allows our portal to only share resources with our D365 instance (in this case our plugins make calls to certain end points on our portal). This section allows only one access control origin header to be present.

When we attempt to validate the URL in the CRM solution as above, the chrome developer console refuses to retrieve, validate, and Save and Publish our settings because the response headers contain more than one value, and only one header is allowed as per our web config. We looked at the network tab and concluded that the WebNotification CRM solution attempts to send 2 headers.

[amervitz]

Please add a screenshot showing what indicates the header is sent twice.

[cmsnyder]

I had to add <add key="WebNotifications.Enabled" value="true" /> to my appSettings to get the web notifications url to work.

[jliberta]

Thank you! I have another question for you, we are hosting our portal on 2 VMs in Azure. Currently our portal config type is set to "onprem" this is a web config setting as follows:

The other options are online and azure. What are the differences? And what are you using?