$DYNAMIC_PORT$ is overwritten

Hello,
I will log this as a bug.

Thank you

Regards

Hello,

I investigated and it seems to be caused by the way we resolve the $DYNAMIC_PORT$ variable for web browsers specifically. Out of curiosity, is there a reason why your website isn't configured like this instead: http://localhost:$DYNAMIC_PORT$
This should be the intended configuration method (using $DYNAMIC_PORT$ instead of inputting a port) when using the dynamic port on a website.

We will see what we can do to improve the way it resolves the variable but if this can help you achieve what you want, that would be a good way to work around it at least.

Regards,

Yes there is a reason why the website isn't configured like http://localhost:$DYNAMIC_PORT$. The variable can also be used in other sections of the entry and thus the URL may does not need to contain the dynamic port anymore. -> Before/After action(s).

Hello,

Could you show screenshots and put more details? I'm not sure I understand your limitations on why you can't configure the entry this way.

Regards,

I already mentioned the Before/After action(s) which can technically do everything what you can imagine. A script triggered e.g. requires the dynamic port but the URL is still a static port.

Alright, I think I see what you mean. Unfortunately I'm not sure there is any workaround so you will have to wait for us to fix the original issue.

Regards,

Hello,

We're now working on this issue, but we want to make sure we understand you correctly before making any considerable changes.

The dynamic port and the destination port are two different things, so $DYNAMIC_PORT$ will in fact never resolve to 4321 in your example. There is indeed a bug where it doesn't resolve correctly for Web Browser entries, but we think it still won't resolve to what you think.

So basically, we'd like to know if you need the dynamic port or the destination port to be resolved. If it's the latter, could you provide us with the exact scenario where you'd want this to work ?

Regards

You are right @Jonathan, the dynamic and destination port are in fact different things. My description was incorrect. I modified the scenario a bit, see the first post again.

There is no dynamic port assigned in the explained scenario, it's always the port from the website.

We would like to always open the same website, let's say localhost:1234, but also have a dynamic port created for the tunnel.

It should be possible to pass the dynamic port to a Events -> After Open -> Command line. For example this line:
cmd.exe /k echo $DYNAMIC_PORT$

The example should start cmd and print something like: 52495 or 43495 or 53456, but never 1234.

Hello,

Thanks for your detailed explanation. We went ahead and fixed the resolving of the $DYNAMIC_PORT$ variable for web browser entries. The change will be included in version 2021.1.9.0.

Regards

Let me know if I need to start a new thread for this, but I have an issue which might be the same as above but also might be different.

Using a dynamic tunnel with an web entry where the entry has something like "https://10.1.5.1:8443".
When I open the entry in RDM, it opens https://10.1.5.1:50128:8443 (the dynamic port with the original port appended.

If I choose "open external" so it opens in a browser, it just opens https://10.1.5.1 and doesn't even include the dynamic port.

If I manually put https://10.1.5.1:50128 in my browser, underlying connectivity works correctly.

Let me know if you need more detail. This is in RDM 2020.3.29.0.

Thanks!

Hello,

I don't seem to be able to replicate this issue. Could you maybe send us the web/tunnel .rdm files (without the actual host/credentials) ? If not, maybe a more precise explanation of your setup (exact types of entries, fields used. etc) would help us greatly.

Thanks

There's actually a bunch of items linked together that would be pretty difficult, anyone available in the next hour for a quick screen share?

Hello,

I took the liberty of opening a support ticket on your behalf in order to be able to schedule a remote session.
I will send you a calendar link through DEVO-30789 shortly.

Best regards,

Hi Chris,

We've made a fix internally for the double port issue. It will be included in version 2021.1.26.0.

Regards

As always, thanks to you and the dev team for
1) Believing the customer
2) Working with the customer quickly and efficiently to gather the pertinent details
3) Working efficiently to quickly create a fix without a bunch of back and forth with the customer

I know that's just how you always operate, but it's a large deviation from many other vendors. Thanks!