[BUG] Could not access multiple HTTP targets in the same session

[joseluisgonzalezca]

Hey!

I'm having some issues while using HTTP targets within the Warpgate project. I’ve noticed that it's not possible for a user within a certain session to access more than one HTTP target at the same time.

Example scenario

For example, I have configured two HTTP targets:

• WEB-01
• WEB-02

When I initially access WEB-01 target, everything works correctly. However, when I then access the second one (using the same session), any further traffic to WEB-01 is routed to WEB-02 instead.

This behavior makes it impossible for a user to interact with multiple HTTP targets simultaneously. Accessing multiple web applications at the same time is a common usage pattern (e.g. opening several internal tools or dashboards in different tabs). However, I think that Warpgate does not currently handle this scenario correctly.

According to Warpgate's documentation:

While the target is active, Warpgate will pass-through all HTTP traffic in this session straight to it.

This seems to imply that HTTP routing is session-wide rather than target-specific, which likely explains the behavior. However, this limitation conflicts with normal real-world usage where users frequently need to access several web applications at the same time.

Actual behavior

• Traffic that was previously routed to one HTTP target is now redirected to the newly accessed one.
• Because of that, only one HTTP target can be effectively used per session.

Expected (or desired) behaviour

• A user should be able to interact with multiple HTTP targets simultaneously. This is a common usage pattern while working with web-based tools.

My temporal workaround

The only workaround I’ve found so far is to open each HTTP target in a separate browser session by using incognito mode. This effectively forces Warpgate to create a new session for each target. While this works for the moment, it’s not a convenient or straightforward solution for users and negatively impacts usability.

Could it be possible to modify the tool to handle this scenario in a proper manner. Is there a better workaround?

Thanks for your time!

[alistarle]

Hi, this issue is actually really impacting, some workaround is to use a domain based routing in warpgate, but there is also another bug impacting this feature (the session cookie is not shared making warpgate to not propagate your login)

[alistarle]

Looks like this latest commit try to fix this issue again: 40d4ba3, maybe give it a try !

[Eugeny]

Currently the target selection is bound to a session cookie. An alternative would be to track it via an URL parameter, but retaining it across redirects / resource loads is not as trivial as I wish it was, so for now only one target per session is possible unless you use domain binding, which this last commit was about: https://warpgate.null.page/http-domain-binding/

[joseluisgonzalezca]

Hi @Eugeny !

Thank you for your response. If I have understood you correctly, when using domain binding it should be possible to use multiple targets at the same time. I have just done a quick test, but I don’t see how this solution would allow me to achieve that.

My Warpgate instance is configured with the domain wg.example.com and I have configured a target that is a subdomain of that domain, for example mytarget.wg.example.com. The certificate configured in the Warpgate works for both, and the SSO part is functioning correctly.

However, I see that the “normal” Warpgate session used to access the admin panel and the session for my target are still the same.

Is there something I am not understanding correctly? What would I be missing or need to configure?

Thank you for your time!

[joseluisgonzalezca]

Hi again @Eugeny !

I have been running several tests with different scenarios, and I still don’t fully understand how domain binding and the external_host option are supposed to work in relation to changes 40d4ba3 and #1476.

Case 1

I configure external_host with domain wg.example.com, and I configure a target as a subdomain (for example, target.wg.example.com).

In this case, I encounter the same issue I mentioned initially: it is not possible to access two targets simultaneously.

Case 2

I configure external_host as the domain wg.example.com, and I configure a target as a completely independent domain, for example target.wgtargets.example.com.

In this scenario, I end up in an authentication loop because the cookie is still being set for the domain configured in external_host, not for the actual target domain.

Case 3

I removed external_host from the configuration file. The Wargpate domain is still wg.example.com.
If the target is configured as a subdomain, I continue to have the same issue described in Case 1.
If the target uses a completely independent domain, the system works as expected.

However, when external_host is not configured, the domain binding cannot be set from the UI because it is limited at the frontend level (I’m not sure if this restriction really makes sense). What's more, I can't use SSO.

Summary

My understanding is that it should be possible to configure external_host, and in Case 2, instead of ending up in an authentication loop, the system should return the cookie with the correct domain. Additionally, the external_host option seems to be mandatory if SSO is to be used.

Given all this:

• What would you recommend in this situation?
• Is there something that needs to be changed at the implementation level?
• Or is this behavior considered a bug?

Thank you again for your time