So I have a user management project that needs to be able to switch between gateways. I got it to switch gateways but the credentials don’t transfer over to the new app. Is there a way to try and validate a currently logged in user on a different gateway? Also when you switch on the perspective app it kicks you to your default browser which isn’t a big deal but annoying to deal with.
edit: Reworded to clarify
I know its been a long time, but did you have any success with this? I'm looking to do the exact same thing.
No, our IdP isn't set up to handle this, nor is switching users seamlessly across gateways likely to happen anytime soon.
Your best bet is probably an external IdP, though it may or may not still distinguish between the two different applications and require the additional sign in.
I am experiencing the same issue described in this post. However, rather than transferring credentials, my goal is simply to trigger a login at a specific access level in order to retrieve the “Diagnostic Bundle.”
I was able to identify the URL that initiates the download, and it functions correctly when the Gateway is already logged in with the appropriate access level. However, once the Gateway session logs out, access to the download URL is blocked, which is expected behavior.
Is there an alternative method to trigger the Diagnostic Bundle from Perspective using a different approach that I may be overlooking?
Worth note that I am using version 8.1.4, so I am unsure whether the same solution applies to newer versions.
With 8.3 you'd be able to pre-generate an API key and use that to call the HTTP route from scripting or an HTTP binding, though you would have to be careful not to 'leak' your API key.
In 8.1 or 8.3, if you use scripting to get access to a GatewayContext object (examples abound on the forums), then get the DiagnosticsManager, you can retrieve or generate a DiagnosticBundle which exposes a CompletableFuture<File>, essentially a non-blocking reference to a file (eventually).
I'm not providing exact instructions on how to get a GatewayContext, because doing so is:
- Explicitly unsupported. Anything you do that relies on importing an internal Ignition class is subject to change without notice between Ignition versions
- Potentially risky. From a gateway context reference, you have access to a variety of internal subsystems that you could use to completely break your gateway.
1 Like
I’ve done some digging on how to obtain a GatewayContext, and every example I’ve found comes with a clear warning about the potential risks and the fact that it’s unsupported.
The sole purpose of putting this behind a scripted button is simply to reduce user interaction with the Gateway — just to allow maintenance staff to generate and download the diagnostic bundle from a Perspective session.
If there’s any real risk of breaking the Gateway by relying on internal classes, then it’s definitely better to stay away from that approach.
This is more a “nice to have” feature rather than “most have”.
Us module developers do it all the time. The risk is that there are no, or fewer, guard rails.
1 Like
To be clear, if you stick to doing what I suggested it's ~zero risk. All you're doing is running a script that does the same thing as clicking the button does. I just want to emphasize not to go gallivanting around, because that could lead to problems.