Project

General

Profile

Feature #4203

expose some web-client details as 4GL global variables

Added by Greg Shah almost 5 years ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
version_reported:
version_resolved:

Related issues

Related to User Interface - Feature #4181: GetComputerNameA emulation Closed

History

#1 Updated by Greg Shah almost 5 years ago

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)

#2 Updated by Greg Shah almost 5 years ago

#3 Updated by Galya B 7 months ago

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.

#4 Updated by Greg Shah 7 months ago

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.

#5 Updated by Greg Shah 7 months ago

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).

#6 Updated by Galya B 7 months ago

  • Assignee set to Galya B
  • Status changed from New to WIP

#7 Updated by Galya B 7 months ago

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... :)

#8 Updated by Galya B 7 months ago

  • % Done changed from 0 to 100
  • Status changed from WIP to Review

4203a r14851 based on trunk r14850 ready for review. Implements FWD-CLIENT-DRIVER, adds short readable names to drivers and also displays them in the Admin Console session list as value for the recently introduced 'Client Driver' column (originally the driver class name).

#9 Updated by Greg Shah 7 months ago

  • Status changed from Review to Internal Test

Code Review Task Branch 4203a Revision 14851

The changes are good.

#10 Updated by Galya B 7 months ago

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.

#11 Updated by Greg Shah 7 months ago

  • Status changed from Internal Test to Merge Pending

#12 Updated by Galya B 7 months ago

  • Status changed from Merge Pending to Test

4203a was merged to trunk as rev. 14856 and archived.

#13 Updated by Greg Shah 5 months ago

  • Status changed from Test to Closed

Also available in: Atom PDF