Is there a setting somewhere that controls when active sessions timeout?
We are on prem, using SSO with Local AD testing the browser with 2024.1 and while I have not timed it 4 hours seems to be when the session times out and I have to close all the tabs and relaunch.
Is there a way to fix this so I can work for at least a standard day without loosing all my work halfway through?
Please tell me I am just missing something in the configuration somewhere.
It is not the idle session timer as that is set to 12 hours and I am definitely seeing it well before that and with current activity.
I also do not believe it is the license timeout on the user as it is set to the default 15 minutes and I have been idle in my session for over an hour without this issue popping up but if I cross that apparent 4 hour mark it will kick in, active or inactive.
I have not tried this version with the smart client (timeout problem that is) as we are focused on trying to use the browser since that is the future. SSO with this setup works perfectly otherwise, whether I use the smart client or the browser, I am logged in without prompting, exactly like it is in the smart client on 2022.2.
According to support it is a known issue that was resolved in 2024.1.15 though given quality of the thread before they revealed that I am not super hopeful and kind of suspect that they are just saying that to pawn me off a bit.
I wish I had more to offer in terms of a solution, but weāre still kind of seeing the same thing in 2024.1.15. The issue is limited to the browser for us only. Iāve done some testing in the smart client and Iāve not been able to replicate it in that environment as of yet.
Iāve had an ongoing ticket with support regarding this for (4?) weeks now I think and while it seems a little bit better after the update, some logins are still being kicked out at the same rate they were prior to the supposed fix that has been implemented. Iāve tried every different value for License Timeout as theyāve suggested, but nothing has seemed to work. 9000 minutes, 15 minutes, 300, 600, all the same results.
Iām still actively digging into this, so if I stumble on anything that works Iāll be sure to update here ASAP. All I can offer in terms of ideas is to just make sure youāre saving constantly just in case your session times out during a larger workload. Iāve also had it where my session will have already gone stale but when I go to save/refresh/move to another tab in the Nav. tree, THEN it will kick me out. So, none of the work I just completed actually saves as a result.
Sorry youāre dealing with this. I know itās a pain and weāve been chasing it for months as well, so Iām hoping there will be a firm resolution to this soon.
That is not promising that you are still seeing it. We are still testing 2024.1 and while most users are supposed to be logging in at this point to spend a bit of time each day in it I am probably the only one that has it open for nearly the whole day as I work through uplifting different pieces to Kinetic from Classic.
I am worried that when we go live we start running into this problem with more or all people, that will be a major problem.
Agreed. Iāve been pretty hopeful that this is a big enough issue that it would be resolved in a smaller timeframe, but Iāve just been doing my best to make it work in the meanwhile.
As I understand it, this issue is only affecting IdP/SSO logins. A workaround that Iāve used for my more frequent users is converting their accounts over to Basic IDās for now. These types of logins donāt seem to have the issue occur as frequently if at all. So thatās an avenue you could explore in the interim if needed.
Weāre late in our implementation stage as well so it concerns me for go-live as well. This issue coupled with individual users consuming multiple licenses at once has been stressful. However, it seems like the license issue has now been resolved, so thatās a start.
The problem does not occur with basic auth as far as I have seen, but there is a reason we have chosen Azure auth and we shouldnāt be forced back to less-secure basic logins due to this bug. Problem also does not seem to occur in the client, only in the browser, but again, isnāt Epicor the one who wants us to move to the browser?
Haha thatās a very valid point. I agree with you 100%. Using the basic logins is a pain also because our users have a tendency to get confused because with one they are using an username and the other an email/different password. Security is definitely a concern with these as well.
They have been pushing the browser pretty hard for the past few months, and these are some pretty glaring issues. Iāve mostly just been going in circles with support about it for a couple weeks now, just trying the same solutions repeatedly.
Just out of curiosity, would either of you be willing to share a case number where you have demonstrated to support that the issue is still present in .15. I told them that I was seeing several users here saying it was not fixed and asking if it was actually still with development or if they consider the issue resolved and I just got back:
āHi Austin, I reviewed this and found that this is a known issue with IDP and the issue will be addressed in the next patch update that is 2024.1.15ā
This most recent response was from about two weeks ago. Iāve had multiple tickets opened regarding this issue and the license issue where single IDās were consuming multiple licenses (which I believe has now been resolved, so thereās hope!).
So after I asked them to review on of the other cases they came back and claimed that it will be solved in .16 and that there is a hotfix available.
HI Leonard,
This will be fixed in .16 patch.
However you can download the hotfix which is available in epicweb
2024-10-30 09:55:58 -Leonard Pothier
Can you please double check as like I said, I am hearing from other customers on .15 that this issue is still happening.
It apparently has been called out on another companies ticket: CS0004528159
In response they told me that it was actually going to be fixed in .16 and that I could install a hotfix for it but when I looked up the hotfix I was pointed to it was for:
Short Description
This Hotfix fixes two issues: KNTC-23451: layers not loading properly when switching from one layer to another. KNTC-23426: Grids not refreshing properly when clicking the refresh button inside overflow menu.
We have all our production team (300+ users) in MES on Basic logins and they have all been having this problem for 4+ weeks. Havenāt taken them all to SmartClient yet, but we are about to try that.