Allow custom local hostnames for Opti ID CMS integration
Currently, in order to test Opti ID integration with Optimizely CMS in a local development environment, you must use https://localhost:5000 as the host URL. Custom hostnames are not allowed, and you will get an error message back from Opti ID if you try to use a custom URL.
For local development, we often set our sites up in IIS using the hostname format "sitename.local". However, when using Opti ID, we are stuck with using localhost:5000. If we were to have multiple sites using Opti ID, this could cause conflicts, since every site would need to use localhost:5000.
It would be great if we had the ability to whitelist custom local hostnames for use with Opti ID. Or, at the very least, to allow a range of port numbers so that every site does not need to use port 5000. This would be more flexible and less disruptive to our local site setup process. Thanks!
Alan Keegan
shared this idea
-
Johan Kronberg
commented
With .NET 10 it will be more common that people use *.dev.localhost as local names so good to allow that format.
https://learn.microsoft.com/en-us/aspnet/core/test/localhost-tld?view=aspnetcore-10.0 -
Andreas Runnhagen
commented
To add a bit more context to why this is important:
We are working on a multisite solution that currently has 15 sites. In a couple of years that will most likely be alot more.
When developing such a site it is important to be able to run a development environment that is similar to production.
If we switch to opti id we will have to use a different login locally and if we need to debug something login related we will have to manually reconfigure the site every time to run on local host.This is doable but not what one might expect from a mature product.
-
Thank you for bringing this to our attention. I’ve created a ticket to review and address your request to allow custom local hostnames (e.g., sitename.local) and flexible port numbers for Opti ID CMS integration during local development. Our team will evaluate this enhancement and determine the best approach to make local testing more flexible and consistent across multiple sites.
