FWD » Core Development » User Interface

Create the following 4GL global variables and ensure they have valid values when requested:

GUI-DRIVER-MODE which can be SWING, VIRTUAL-DESKTOP-WEB-CLIENT or EMBEDDED-MODE-WEB-CLIENT
WEB-CLIENT-EXTERNAL-IP-ADDR which would be the browser's IP address as seen by the FWD client's embedded jetty
WEB-CLIENT-INTERNAL-IP-ADDR which may be a real internet IP (if the same as WEB-CLIENT-EXTERNAL-IP-ADDR or it can be the true internal network IP of the browser behind the NAT or proxy) - this can be calculated via WebRTC (see #4181)

May I ask if the IPs will be used for licensing in 4GL? Because I would hope, since the IPs (the external one and the one behind proxy) are available before the client is spawned in SsoAuthenticator, we motivate the customers to save on resources and ports and have license policies before the user is in.

Also the internal IP behind NAT can't be accessed by WebRTC any more (since one year ago the browser specs have changed), as I've mentioned in #4853-23.

May I ask if the IPs will be used for licensing in 4GL? Because I would hope, since the IPs (the external one and the one behind proxy) are available before the client is spawned in SsoAuthenticator, we motivate the customers to save on resources and ports and have license policies before the user is in.

I think the original idea was that the IP values would be used for that purpose. I agree that licensing decisions are best implemented at the same time as authentication, with SSO this is now before 4GL code is run.

We can drop the IP values here.

I think the GUI-DRIVER-MODE should be changed to FWD-CLIENT-DRIVER and each driver should have a specific string that it reports. This will make it possible to use this for decisions beyond just GUI things.

The value should be added to ClientParameters at startup so that it is always available at the server (without the need for a down-call).

Greg Shah wrote:

The value should be added to ClientParameters at startup so that it is always available at the server (without the need for a down-call).

Good that I didn't implement it with a down-call... :)

I've tested with testcases all types of drivers. The procedure I used is a simple message FWD-CLIENT-DRIVER. I also tried to convert with assigning a value which doesn't get converted as expected. And finally checked Admin UI for regression.