Question on using IssuerUri to solve multiple url license error from ports in url

[gregcetti]

Which version of Duende IdentityServer are you using?
7.0.8

Which version of .NET are you using?
.NET Core 8

Describe the bug

We are seeing the same behavior as noted in issue #1300 - we are constantly receiving event logs "Your license for Duende IdentityServer only permits 1 number of issuers." Our system is similar to what is noted in issue #1300 where we have a load balancer that is forwarding requests, and we see issuers of oururl.com & oururl.com:port referenced in the event log error. We see repeated errors in the following requests:

/connect/checksession
/connect/authorize
/connect/token

The solution notes that we can manually add the IssuerUri in the options - but my question is will that have any consequences of either causing authentication errors if the issuer does not match what we explicitly enter, or other event log errors of the same nature?

Note: This behavior just started recently when we upgraded from 7.0.0 to 7.0.8.

[AndersAbel]

Adding the IssuerUri manually is something I would recommend to avoid as long as possible. The reason is that when the issuer resolution fails, it is usually caused by infrastructure level issues.

You do not state what port it is you see when the address is on the form oururl.com:port. Is it 443? And is the protocol always https? What is the address that the end user actually sees in those cases (i.e. the address in the browser's address bar)?

[gregcetti]

The port we are using is 8054 - and will always be https. The end user does see the https://oururl.com:8054 in the address bar when authenticating.

There is no http binding available on the IIS site configuration, and the load balancer redirects port 8054 to 8054 on the host machine - there should be no situation where https://oururl.com is called, but the event log reflects the following:

Your license for Duende IdentityServer only permits 1 number of issuers. You have processed requests for 2. The issuers used were: https://oururl.com:8054, https://oururl.com. This might be due to your server being accessed via different URLs or a direct IP and/or you have reverse proxy or a gateway involved. This suggests a network infrastructure configuration problem, or you are deliberately hosting multiple URLs and require an upgraded license.

This just started recently when we upgraded to the 7.0.8 update with no known changes to our infrastructure.

[maartenba]

(note: we're moving this issue to our new community discussions)

[RolandGuijt]

Did we change something in the code, introduced in 7.0.8, that might cause this @josephdecock ?

[RolandGuijt]

I discussed this with the team and there were no changes introduced during the transition from 7.0.0 to 7.0.8 that touch the way the license validator works. Except for performance optimizations.
Could it be that something in your infrastructure changed?
Also: are you using forwarded headers middleware? That could cause a conflict with the load balancer forwarding the headers.