Hey, all --
I'm looking to run queries (both read and write) over the ignition config DB while the gateway is running (both to grab/copy valid sessions, to check tag config changes, and some other things). Is there a guide out there to how to connect to the in-mem DB or SQLite file that ignition uses as its db by default?
I believe the internal db is limited to a single connection (that is used by Ignition). You can get the majority of data from this db using the built in system functions of Ignition.
There is also additional information you can get if you look through the SDK documentation.
In addition to having a high risk of locking up your gateway, all of this is going away in v8.3, right around the corner. Consider not wasting your time on this. Use the system.* APIs--those don't disappear across major version changes.
3 Likes
Sure, these session APIs generally make sense to me and it's good to hear they're crossversion stable. I do notice that a number of these properties have getters but not setters (e.g. util.session), is there a way around that?
Certain things are read only by design. You shouldn't ever be trying to set something like session info from the outside. What is your end goal by writing to these?
Moving over a user's perspective between multiple gateways (not using ignition redundancy) without losing their session info
Good luck.
1 Like
Sounds pretty risky.
Can you get the info you need via WebDev API calls to the other gateways?
Let each gateway send a response containing their respective Session and/or tag details.
To expand a little on Phil here:
First, session data is not persisted into the SQLite config DB, so your entire approach is flawed. You're going to have to work entirely on the in-memory constructs, using whatever private, undocumented internal methods you can surface.
Then you're going to have to serialize that session information in some way, package it in a format acceptable to both sides of the negotiation, and send it over the gateway network. Then you're going to have to hope you can manage to fool the receiving gateway in just the right way such that the incoming redirect you trigger from the outgoing gateway happens to line up with your newly received and injected session, and thus that recycled session is used instead of a new session being generated.
Every step of that process is going to be undocumented swimming against the tide, and is right on the edge of being a serious security risk, as a bonus.
The dramatically easier thing to do would be to find or create an IdP (not Ignition's) that allows you to persist sessions between gateways, such that the authentication attempt from one gateway is considered valid (by the IdP) on the additional gateways.
2 Likes
Oh, this would absolutely work for me. Where is documentation on the IDP system?
Thank you! And this would allow for Session transfer as well? (The auth flow seems to imply that even if the user is logged in, they would need to repass through auth)
Whether the user needs to reauthenticate is a decision made by the identity provider. In the default, entirely-in-Ignition case, that's true. By contrast, think of e.g. a website that supports "Sign in with Google" - you don't have to reauthenticate your Google account each time, the website just defers to Google and Google 'knows' you're still authenticated.
Terrific, thank you.