FWD » Core Development » User Interface

A customer has the requirement that a user should be able to create more than one web client session with their application, but that this should only be allowed from the same browser instance. Users have the need to open multiple copies of the application, with each copy being configured to a different organizational unit (e.g. department, divison, company, branch office...). By only allowing this from a single browser instance, the customer is implementing a licensing restriction for their application such that many users can't share a single license.

Part of the licensing solution can be implemented using the device-id from #4853. But another aspect is to make it easy to safely open these other sessions. Avoiding the OS login for the subsequent sessions makes the system more user friendly and ensures that the session is within the same browser instance. The idea is that we will add a feature to the virtual desktop mode which will "fork" off a new session as an additional tab in this browser instance.

We can be sure that a new session is in the same browser if we are the code that opens the window. We must implement this in a true JS click event (the button must be in the DOM and the user must click on it). This is needed to avoid popup blocking. The button would be something like "Open New Session". We would have to up-call to the FWD server to get a new FWD client spawned in the current OS account/login context. Then we would need to open the window, pointing to the new FWD client's proper URL. I see no reason to have the OS authentication process again since we have already done it successfully and the OS context already exists.

Is there a need to use cross-document messaging here to securely pass any one-time-use authentication token so that the new session can safely and securely open its connection?

Does anyone see a flaw in my idea? Are there other things we have to implement? I'm assuming that we can implement this as a feature of virtual desktop mode without any need for 4GL code changes or application integration. We would want to allow this feature to be disabled in the directory, but by default it probably should be enabled.

Opening manually multiple browser windows in the same browser instance should fulfill the requirement. The identifier of the browser from #4853 should be one and the same and licensing policy can be applied. Do we still need this task?

Opening manually multiple browser windows in the same browser instance should fulfill the requirement.

The result must be a new FWD session with its own newly spawned FWD client. Just opening another tab or window doesn't no anything. Note the requirement to avoid additional authentication. This is about creating multiple instances of the converted application for the same application user/FWD user/OS user.

Greg Shah wrote:

Note the requirement to avoid additional authentication.

A new login session should be created by the auth server. Since the implementation details of how authentication works in the app are completely left to the customer's code, the only thing we can do in FWD is to request a new session passing in to the auth hook the so called (by me) AUTH-BLOB and ask for a new "session" (success code and a new blob). If that is successful, we can pass it in to a new tab opening the login page with a POST request. It's an option to directly spit the result in the new tab. The POST request will call the auth hook to verify the validity of the blob and redirect to a newly created web process.

The whole thing will also require some custom 4GL method that triggers FWD actions: first on the server get the blob, make the request to the auth hook, then pass the request to the FWD client, generate and execute the js code for the form submission.

May I do a POC for #4856 and #3931 in a new branch? Otherwise the sign-in tasks come to standstill.

A new login session should be created by the auth server.

We cannot assume there is an auth server involved and if one is part of the solution it would only be hidden behind a registered auth hook. We cannot even assume that there is a customer-provided auth-hook since it is an optional feature.

I also wonder if we care about notifying the auth hook in this case. Perhaps it is something we need to do. But we already know that the user is authenticated. We might want to have a flag that determines whether an account can or cannot fork new sessions, but otherwise it might be perfectly reasonable to just spawn the new client and bring up a new tab/window that connects to it.

Since the implementation details of how authentication works in the app are completely left to the customer's code, the only thing we can do in FWD is to request a new session passing in to the auth hook the so called (by me) AUTH-BLOB and ask for a new "session" (success code and a new blob).

I guess if we are indeed supporting this token/blob idea, then it would require that notification. But again: we must not assume that the auth hook is present. If it is not present, we can still implement this feature internally in FWD.

If that is successful, we can pass it in to a new tab opening the login page with a POST request. It's an option to directly spit the result in the new tab. The POST request will call the auth hook to verify the validity of the blob and redirect to a newly created web process.

I don't know why we would need a login page. The entire idea is to avoid that and once we know that the session can be spawned, why can't we just spawn it and load the client?

The whole thing will also require some custom 4GL method that triggers FWD actions: first on the server get the blob, make the request to the auth hook, then pass the request to the FWD client, generate and execute the js code for the form submission.

I don't see why we need 4GL code involved. The idea here was to implement this forking as a built-in feature of the web client (which does have its own menu that is outside of the 4GL legacy UI). If forking was enabled for the account, that menu would be extended with a "Start New Session" menu item. Invoking that item would upcall from the web client to Java which then can do whatever is needed If no auth hook is registered, then it can confirm that the account is allowed to fork and if so, spawn the new client and return with the URL. If the auth hook is registered, then we read the blob from our session state and allow the hook to determine if the fork can occur. If it can occur, then the client would be spawned, the newly returned blob can be stored in the new session's state and the URL would be returned. On the web client, if there was no error to report, the new tab would be launched using the returned URL.

May I do a POC for #4856 and #3931 in a new branch? Otherwise the sign-in tasks come to standstill.

I'm not yet convinced that we have a shared understanding on how this will be implemented. In #3931, I would like to see the proposed API and some description of how it works.

Greg Shah wrote:

We cannot assume there is an auth server involved and if one is part of the solution it would only be hidden behind a registered auth hook. We cannot even assume that there is a customer-provided auth-hook since it is an optional feature.

Web apps need login page. If single login screen preference is enabled, then there should be an implementation of the auth hook, otherwise it can't work. OK, it can be disabled. Then the flow will be simplified.

I also wonder if we care about notifying the auth hook in this case. Perhaps it is something we need to do. But we already know that the user is authenticated. We might want to have a flag that determines whether an account can or cannot fork new sessions, but otherwise it might be perfectly reasonable to just spawn the new client and bring up a new tab/window that connects to it.

Well... If the customer's app has login screen (app users), they need to manage sessions. We can't "just" spawn a clone I imagine.

If that is successful, we can pass it in to a new tab opening the login page with a POST request. It's an option to directly spit the result in the new tab. The POST request will call the auth hook to verify the validity of the blob and redirect to a newly created web process.

I don't know why we would need a login page. The entire idea is to avoid that and once we know that the session can be spawned, why can't we just spawn it and load the client?

This "login page" is invisible and there is no other way to open a new tab/window that does something, but is invisible. Maybe I don't explain it well, but it's not very standard one either.

Greg Shah wrote:

I don't see why we need 4GL code involved. The idea here was to implement this forking as a built-in feature of the web client (which does have its own menu that is outside of the 4GL legacy UI).

Sorry, I misunderstood session and application in:

A customer has the requirement that a user should be able to create more than one web client session with their application

We cannot assume there is an auth server involved and if one is part of the solution it would only be hidden behind a registered auth hook. We cannot even assume that there is a customer-provided auth-hook since it is an optional feature.

Web apps need login page.

FWD does provide a login page. This forking feature is only available after a session is started. It would be inokved from a menu item in an already existing virtual desktop session. I can see that we could also expose this as a javascript feature available to embedded mode.

If single login screen preference is enabled, then there should be an implementation of the auth hook, otherwise it can't work.

This task is not directly related to single signon. It does not require it, but if single signon is active (and there is an auth hook), then indeed we should integrate with it properly.

If that is successful, we can pass it in to a new tab opening the login page with a POST request. It's an option to directly spit the result in the new tab. The POST request will call the auth hook to verify the validity of the blob and redirect to a newly created web process.

I don't know why we would need a login page. The entire idea is to avoid that and once we know that the session can be spawned, why can't we just spawn it and load the client?

This "login page" is invisible and there is no other way to open a new tab/window that does something, but is invisible. Maybe I don't explain it well, but it's not very standard one either.

I don't see why we need the extra login page. Once we have spawned a new client (which is something that the FWD server can do without any web page being involved), we can simply open a new tab that points to the correct URL.

Let it be js click.

So, how do I determine if the customer app has login or not? If single login page is not enabled, but the customer has login page and app users, how to fork a session?

New client process / FWD session will open the same "entry point" 4GL process that has login. It needs to know it's forked. So if the customer app has login or not is critical here.

Let it be js click.

So, how do I determine if the customer app has login or not?

From a javascript/web client perspective, we don't care. We just up-call to the FWD client and the FWD client up-calls to the FWD server where we can process this new session fork request. On the server we know things:

• if there is an auth hook involved or not
• if the account is allowed to fork a new session
• the OS account and broker for spawning a new client

Based on this, we can fork the new session and once the session is running, we would get back the URL for the new web client. We do this today and return it to the login page for redirect. In the forking approach, we just return it back from the FWD client up-call, which returns it back from the web client up-call, which uses the URL to open a new tab.

If single login page is not enabled, but the customer has login page and app users, how to fork a session?

We do the same thing but we don't invoke any auth hook. If the customer's application has its own 4GL based login screen, then it will automatically be part of the application startup of that new session. The user would then be prompted for their application login as usual.

The entire point of this task is to avoid the OS-level login since we already know how spawn another process in the same OS account as the current session.

New client process / FWD session will open the same "entry point" 4GL process that has login.

Yes, that is OK.

It needs to know it's forked.

Why? There is no difference in the application level startup processing for a forked session.

Alright, so we save one OS login screen with the whole operation.

"Session forking" is somewhat too strong expression in my opinion.

Alright, so we save one OS login screen with the whole operation.

Worst case, yes. For the single signon case, we also avoid an extra application login.

This task is just about reducing the friction of a common case scenario. The original legacy application was a desktop app (or ChUI) and it is common for a single user to have multiple instances of their application open at one time. Moving to the web client, we have added an OS login step and if we don't provide this forking capability, we add an extra step to every instance of the application which is super annoying to users.

"Session forking" is somewhat too strong expression in my opinion.

I don't have a better term. We are literally creating another FWD client (which has a new connection and FWD session on the server) using the existing FWD account, the existing OS account and the fact that the user is already authenticated. It seems exactly like forking a session.

To sum up the implementation details: Add button to the web driver wrapper container, click opens a new tab / new client session under the same OS user. Does it fulfill the requirements of the customer?

A customer has the requirement that a user should be able to create more than one web client session with their application

And if single login page is enabled and auth hook impl provided, then call the auth hook to ask for a new forked session and pass it to the new client.

Yes, I think that is correct.

Now can I start the implementation? :) There is not much more to consider in the flow of #4856 and #3931. Better do a POC and see if it works.

Now can I start the implementation? :) There is not much more to consider in the flow of #4856 and #3931. Better do a POC and see if it works.

I'm OK with a POC for #4856 but I would like to see the proposed API for #3931 before a POC is done there.

Maybe it's time to define some basic terms and reconsider the core statements.

a user should be able to create more than one web client session with their application, but that this should only be allowed from the same browser instance.

What is "user"? Is it the human operator on one workstation? Is it the in-app authenticated user?
What is "one web client session"? Is it one session with certain credentials? Is it one session with any of the possible credentials?

Users have the need to open multiple copies of the application, with each copy being configured to a different organizational unit (e.g. department, divison, company, branch office...).

What is "configured to a different organizational unit"? Is it related to different permissions attached to different in-app users? Is it some in-app configuration and then what is it?

By only allowing this from a single browser instance, the customer is implementing a licensing restriction for their application such that many users can't share a single license.

What is "single license"? Is it mapped to a single in-app user?

Under "in-app" I mean a user in the customer's DB or any directory they use. The above questions can apply to any other user authentication (OS / FWD), if applicable, but that should be defined.

One person can open multiple sessions on multiple devices, with multiple browsers and in multiple tabs in each browser. Also one person can open multiple different sessions with different credentials. Multiple people can open multiple session with the same credentials. If credentials represent organizational units, this is quite possible (many people will use the same credentials). We can't control any of the above. We can only provide some non-conclusive information about the browsers, IPs and currently live sessions to the customer app, where a licensing policy can be implemented. By allowing easy forking, we're not fulfilling the customer's requirement in any way, because they are suggesting restriction. Also the new session should be a different one according to the customer's requirements - associated with another configuration.

Basically this is what the above questions aim to clear up.

P.S. auto-login with SSO allows easy creating of new sessions without entering credentials.

Galya B wrote:

Maybe it's time to define some basic terms and reconsider the core statements.

a user should be able to create more than one web client session with their application, but that this should only be allowed from the same browser instance.

What is "user"? Is it the human operator on one workstation? Is it the in-app authenticated user?

We mostly mean "the human operator on one workstation" but that operator must also be authenticated in order to have a session in the first place. Without a session, there is no forking. But for your purposes, user means that operator.

What is "one web client session"?

I mean one FWD web client JVM in virtual desktop mode, which by definition has a FWD server session (security context and dedicated threads/state) associated with it.

Is it one session with certain credentials? Is it one session with any of the possible credentials?

I don't think we care what the specific credentials are, just that there is a session (which means there is some FWD account that is associated with the session on the FWD server side).

Users have the need to open multiple copies of the application, with each copy being configured to a different organizational unit (e.g. department, divison, company, branch office...).

What is "configured to a different organizational unit"?

This is a customer-specific example, so it is something at the application level that would be chosen. In this case, the customer's application has the concept of a single FWD server which represents multiple organizations and the user can pick which organization their application instance is actively processing. So this would be some kind of application dialog.

The point of this is not that FWD is going to provide this support per se. Rather, the session needs to be independent so that the application can be run with completely different internal state. In other words, we need a separate FWD web client JVM and a separate FWD server session. If we deliver that, then the application code will be able to handle the rest.

Is it related to different permissions attached to different in-app users? Is it some in-app configuration and then what is it?

Hopefully my explanation above answers this.

By only allowing this from a single browser instance, the customer is implementing a licensing restriction for their application such that many users can't share a single license.

What is "single license"? Is it mapped to a single in-app user?

This license is a customer application concept. Again, I am mentioning an application thing here which will be naturally bounded by our approach. The core issue is ensuring that this feature is only possible in a single browser instance. If we do that, then we will not break their licensing model.

Under "in-app" I mean a user in the customer's DB or any directory they use. The above questions can apply to any other user authentication (OS / FWD), if applicable, but that should be defined.

I don't think we are directly related to the authentication in this feature. The idea is that the session already exists (presumeably it was authenticated in some way to create the session). At that point, we are just allowing the session to be forked into another sibling session. It needs no extra authentication.

One person can open multiple sessions on multiple devices, with multiple browsers and in multiple tabs in each browser. Also one person can open multiple different sessions with different credentials. Multiple people can open multiple session with the same credentials.

Yes, though in all of these cases we would expect there to be an authentication needed.

If credentials represent organizational units, this is quite possible (many people will use the same credentials). We can't control any of the above. We can only provide some non-conclusive information about the browsers, IPs and currently live sessions to the customer app, where a licensing policy can be implemented. By allowing easy forking, we're not fulfilling the customer's requirement in any way, because they are suggesting restriction.

We don't need to implement anything about the organization units. It is enough to limit the user to a single browser instance. Doing this means that there is only one user (human operator) using all of the related sessions (the original session and the forked sessions). That is OK. It meets their needs.

Also the new session should be a different one according to the customer's requirements - associated with another configuration.

Yes, but that is up to the application to implement.

P.S. auto-login with SSO allows easy creating of new sessions without entering credentials.

We can consider this as the mechanism for implementing the forked session support, so long as it meets all the requirements.

Let me try to put it in other words:

A customer has the requirement that a user should be able to create more than one web client session with their application, but that this should only be allowed from the same browser instance.

FWD can't fulfill the part this should only be allowed from the same browser instance, especially with the words only & same.

Users have the need to open multiple copies of the application, with each copy being configured to a different organizational unit (e.g. department, divison, company, branch office...).

FWD can't fulfill the part each copy being configured to a different organizational unit, especially with the word different.

By only allowing this from a single browser instance, the customer is implementing a licensing restriction for their application such that many users can't share a single license.

only & single again not possible, especially in FWD, it is supposed to be licensing policy in the customer app.

I don't see what we can fulfill from these requirements with easy forking.

Otherwise, I'm understanding what you want. It can be a feature, but not in that context fulfilling the requirements or even having much to do with them.

Also it dawned on me just now that auto-login will not work with multiple different sessions in the same browser.

Can we get some clarifications from the customer on their requirements? I think they want different sessions with different in-app users in one browser.

A customer has the requirement that a user should be able to create more than one web client session with their application, but that this should only be allowed from the same browser instance.

FWD can't fulfill the part this should only be allowed from the same browser instance, especially with the words only & same.

Can't we do the following?

• Limit forking to only occur when there is an existing session. By definition, this must have involved authentication which in combination with SSO means that the application has had a chance to decide if the user is allowed. The application can track and implement its own licensing mechanism.
• Limit forking to only work on the same browser instance. Doing this means that the same authenticated user is using all the forked sessions.

This will meet the customers needs. If it is not possible, help me understand why.

I think they want different sessions with different in-app users in one browser.

No, they don't want this. The same user is able to access multiple organizations and it is an application function to implement this.

In FWD, we need to allow multiple sessions in the same browser instance without forcing an authentication for each session.

Greg Shah wrote:

This will meet the customers needs. If it is not possible, help me understand why.

Because the customer can create "more than one web client session with their application" from different browser instances.

Greg Shah wrote:

The same user is able to access multiple organizations and it is an application function to implement this.

So this application function is not the in-app login we're removing from their app with SSO?

This will meet the customers needs. If it is not possible, help me understand why.

Because the customer can create "more than one web client session with their application" from different browser instances.

That is OK as long as the new session is not forked. We aren't trying to stop login from multiple browsers. We are trying to make it easy for an already authenticated user to create multiple sessions so long as they stay in the same browser.

So this application function is not the in-app login we're removing from their app with SSO?

Correct. They will (or already do) provide a mechanism to set the organization within the application. The user needs to have multiple tabs open, one per organization. This duplicates something they can already do today.

In FWD today, the user has to authenticate for each tab. We're trying to eliminate those extra authentications but only when we are within a single browser instance.

OK, then a button to open a new tab with the virtual desktop landing page address is enough.

The limitation is that SSO with auto-login should be configured.

Also I possibly need to fix Jetty's sessions - the FWD client's embedded Jetty policy attaches cookies for each session, but when one of the sessions ends, all cookies are removed and all sessions end. I'm not sure how much of an issue this is?

Greg Shah wrote:

create multiple sessions so long as they stay in the same browser.

I don't like the phrasing. They can go to another browser and continue creating multiple sessions there as well.

OK, then a button to open a new tab with the virtual desktop landing page address is enough.

Rather than have a button on the virtual desktop, I prefer to add a menu item into the virutal desktop menu.

The limitation is that SSO with auto-login should be configured.

I'm OK with that.

Also I possibly need to fix Jetty's sessions - the FWD client's embedded Jetty policy attaches cookies for each session, but when one of the sessions ends, all cookies are removed and all sessions end. I'm not sure how much of an issue this is?

If closing one of the tabs ends all sessions, that is definitely a problem.

create multiple sessions so long as they stay in the same browser.

I don't like the phrasing. They can go to another browser and continue creating multiple sessions there as well.

I'm specifically talking about whether forking can be used or not.

Is there already a toolbar / taskbar in the DOM where this button can be added?

There is an existing popup menu on the taskbar, add an item to that.

Greg Shah wrote:

There is an existing popup menu on the taskbar, add an item to that.

It is existing only for virtual desktop, so embedded will not support any such "session forking", but users can still open a bookmark in a new tab and auto-login will work for them.

There is an existing popup menu on the taskbar, add an item to that.

It is existing only for virtual desktop, so embedded will not support any such "session forking", but users can still open a bookmark in a new tab and auto-login will work for them.

Yes, session forking is only planned for virtual desktop.

It is fine where it is for now. We will probably reorganize these so that the features that are for analysis or diagnoztics will be more hidden in a submenu while end-user items would remain on the main popup.

Our discussion in #7813 highlights that I did not pick up on a crucial detail.

Also it dawned on me just now that auto-login will not work with multiple different sessions in the same browser.

I recall this excluded auto-login as a solution. Later, you said:

OK, then a button to open a new tab with the virtual desktop landing page address is enough.

I should have asked at that time: why will this work?

On the surface, it doesn't meet the requirements, since it must remain possible for the same user to have sessions with different accounts in the same browser. Session forking in that environment would be broken, if I understand correctly. If I'm misunderstanding, please help me understand.

You can have different users logged in with auto-login. This is not related to opening a new session (so called `forking`). `Forking` is always for one user. Hynek, who knows the customer the best, said we need auto-login. We have it. <customer_name> wants no login forms: auto-login. He has it. The stupid part is that the web session (and the attached cookie) don't do anything after authenticating the user on login, so you can log in with another user, if there is no auto-login. Then the "New Session" menu button (if appears) will open a new login page. But with #7813 it should all be wonderful. Forking is about one user, so what's the concern. Let #7813 open the new session from 4GL.

I'm pretty sure it's not expected the 4GL app to be subscribed for an event from web for a new forked session.

You can have different users logged in with auto-login.

Please help me understand how this can work. Auto-login uses a site cookie approach, right? Only one user can be identified by that token. How can you fork from different sessions and duplicate the session? That is the core requirement in this task.

This is not related to opening a new session (so called `forking`). `Forking` is always for one user.

The core requirement for this task is session forking, NOT auto-login.

Hynek, who knows the customer the best, said we need auto-login. We have it.

Please help me understand where this discussion happened. I don't recall auto-login being a requirement, ever.

<customer_name> wants no login forms: auto-login. He has it.

I don't recall him asking for no login forms. He needed us to allow them to customize/control the login UI. And their approach is not based on auto-login, but rather on loading their own 3rd party auth server's UI.

I'm not understanding how that matches with auto-login.

The stupid part is that the web session (and the attached cookie) don't do anything after authenticating the user on login, so you can log in with another user, if there is no auto-login.

That is needed for some use cases. We have customers that need the same user to login multiple times as different users.

Then the "New Session" menu button (if appears) will open a new login page. But with #7813 it should all be wonderful. Forking is about one user, so what's the concern. Let #7813 open the new session from 4GL.

It is a problem if the core requirement of this task is not met.

I'm pretty sure it's not expected the 4GL app to be subscribed for an event from web for a new forked session.

I agree. Why would this be needed?

The core requirement of the task is to open a new session of the same user easily without dialogs. That is achieved when SSO auto-login is enabled and the button in the menu opens a new tab with the login screen.

Auto-login is not implemented in this task and is not part of it. It's part of 3931a.

The change referred in #52 is as follows: a new button added to Virtual Desktop menu called 'New Session' that opens a new tab with the login url. It had to show up only when auto-login is enabled in SsoAuthenticator (there is a non-null return value from getAuthCookieName), but recently I've seen it show up in other cases as well, might be a bug to be fixed. In every case it's still valid to show the login screen to start a new session.

But let me sum it up again: A new button in virtual desktop's menu opens a new tab with the login url.

Is 7813a involved in future headway on this task?

Greg Shah wrote:

Is 7813a involved in future headway on this task?

Yes. It will use the same mechanism, started in a different way. Do we need the same related-session-id to be present here as well?

Is 7813a involved in future headway on this task?

Yes. It will use the same mechanism, started in a different way. Do we need the same related-session-id to be present here as well?

Yes

Can I directly execute 4GL method from the front-end or I need to create a new WebSocket msg and handle it all the way through?

Can I directly execute 4GL method from the front-end

Not from the virtual desktop. Embedded mode does have tools for that, but we aren't supporting embedded mode right now.

I need to create a new WebSocket msg and handle it all the way through?

Yes, this will be needed.