Although I am hugely impressed with ARC on the whole, there is one aspect which is - “not smile inducing”, if I may be charitable about it.
If you’re on mode 1 security, it doesn’t cache your password. That in itself is OK if that can’t be done safely, notwithstanding that regardless of the settings on your sever the timeout duration seems to be “As soon as you take your eyes off the screen”.
This in itself isn’t a problem because if you are working on, say, a TI process, you don’t lose your changes if the connection drops; they just remain there until you connect again, then you can save them.
So you enter your password to do that BUT if you make EVEN ONE TYPO… boom. Not only do you get an invalid password warning but all of the code that you were working on, and every change that you have made since the last save is gone. Vanished into the digital ether. It’s not cached, it’s not there, it’s just gone forever.
The timeout in Arc is determined by the HTTPSessionTimeoutMinutes in tm1s.cfg. By default I think it is 20 minutes but it didn’t always work correctly in early versions of the REST API. The whole session mechanism was rewritten but I can’t remember the version.
As @cw-ch-scott suggested I would recommend enabling the TM1 Credentials > Store Credentials in the About page. On a successful login the credentials are stored in local browser storage and are encrypted using a public key. Only the Arc server has the private key that can be used to decrypt the password.
With this option Arc will automatically log you back in after a timeout if it receives a 401 (Unauthorized) error from the TM1 server. It is personally my favorite feature of Arc, no more login dialogs.
That’s interesting… because I DID have that setting set. After reading these posts I unset it, shut down, started up again and reset it. The first time after that, I was still asked for a password. However since then I haven’t been asked for one; it has just given me a warning of the timeout and asked me to re-execute my last command.
You get the “Re-execute the last command…” message when request that triggered the 401 error (unauthorized) is something other than a GET action to the REST API.
I figured that; that message doesn’t worry me. It was just weird that the credential storage wasn’t working until I toggled it off then back on. I’d noticed it before but hadn’t paid it a lot of heed because it’s not something I’ve had time to look into. Since it’s not thus far a reproducible issue there isn’t anything that can be done about it, but if I encounter it again I’ll let you know.
