Web Users are receiving "Session Expired" when using Acumatica ERP, I have made the following changes to the Web Config file as per documentation:
changed the ReminderRequestPeriod
report Time-out settings
Query Time-out settings
Depending on when/where the users are receiving the timeouts it could be various items.
If the timeout is happening at a consistent duration, then chances are the users are hitting the standard ASP "Session" timeout.
In the web.config file look for the "sessionState" tag and see what the value in "timeout" is. This is in minutes. Increasing this value can increase the amount of time before a users "session" times out.
When modifying this value, you should also look to the "forms..." tag and see what the "timeout" there is set to. This is the duration of the forms authentication duration. These should match or be close or you'll have the authentication timing out before the actual session does.
If you are having random issues (timeouts occurring at various times to various users or multiple users at the same time), one thing to look at is the Eventlog on the server. If there is a problem where the IIS Application pool is recycling (does this by default) or if it is crashing, the end user sessions are not persisted and will show the timeout message.
If it's a recycling issue, you can adjust the the amount of time before it recycles in the Application Pool.
If it's an issue with the pool crashing, there will be an event log showing the crash to help isolate where this is occurring. I had a customer who had this issue recently. After applying some updates they never restarted the server which was causing periodic application pool crashes. Running low/out of memory can do this as well.
These won't guarantee a fix however it might help you isolate the cause of the timeouts
I have similar issue. In my case it worked increasing available memory at web server
Also, remember that if your site was upgraded, you may need to reset your license keys. (you will probably need to contact Acumatica to do this)
We have had clients where their license became invalid after upgrading to a newer version and then only 2 users could log in and if a 3rd user logged in one of the other users received the "Session Timeout" error.
Related
We have a Vaadin 14 (Flow) application which is fronted by an Apache reverse proxy that integrates with Gluu for authentication using OpenID (mod_auth_openidc).
This is generally working fine, except when users leave their browser open with the application idle for a long time, until the max session time of the OpenID session is reached. The problem is, at that point the Vaadin client keeps trying to send heartbeat requests. This, in combination with this mod_auth_openidc issue, results in state cookies piling up and reaching a limit so that the user has to close her browser before being able to re-login.
I've tried various things (unsuccessfully) in order to get the server to instruct the browser to visit a logout URL when a heartbeat request is received after session timeout (in combination with vaadin.closeIdleSessions=true), but even if it worked it wouldn't be a solution for other browser tabs that may also be open at that time and sending heartbeat requests.
What we really want is to limit the number of times the Vaadin client retries to send the heartbeat requests (say max 3 times) and then just stop sending requests (maybe display a message to re-login).
Is this possible in any way? The current workaround is to disable the heartbeats completely, but this doesn't seem ideal (Vaadin won't detect idle UIs).
The UI instance has a ReconnectDialogConfiguration which includes reconnectAttempts property to control how many times to re-try requests (including heartbeat requests). Default seems to be 10000.
In Vaadin 14 (LTS) this can be set using PageConfigurator.
In Vaadin 18 (latest release) this is done using AppShellConfigurator
Disabling the heartbeats is the way to go. If you need something more nuanced than that, you'll need to make a change (maybe add a configuration option) in how Heartbeats work in Vaadin. Creating a ticket in GitHub could be a good place to start.
I have a website that requires a lot of data entry. It hasn't been an issue until recently. Now the user is getting a 403 error, which I assume is caused by the session timeout. The problem I am having is that now, every page gives you a 403 error, even the logout. So, until I clear all the site cookies, the user is unable to do anything. I have to believe there is a better way to resolve this without having to resort to clearing cookies. Thanks.
Wade
There are so many reasons behind the session timeout:
1)Application Pool is recycled
2)IIS/worker process is restarted
3)Application Domain is restarted.
4)Some times system admins(IIS server admins) restricted the applications due to heavy burden of database log files please check the database log files
First, check the iis log for the sub status code.try to set the session time and application pool recycle time the same value. iis ideal time out default value is 20 minutes.
you could also set the iis HTTP keep-alive setting by following below steps:
https://learn.microsoft.com/en-us/iis/configuration/system.webserver/httpprotocol/
you can use the Auto-Start behavior to keep the app "Always Running".
https://weblogs.asp.net/scottgu/auto-start-asp-net-applications-vs-2010-and-net-4-0-series
I have an application with claims based authentication and recently I have been having an issue where at random I lose authentication. The application usually gets it's Identity, Claims information from System.Security.Claims.ClaimsIdentity and it authorizes fine. For some reason after clicking around different pages I lose authentication and it seems to be looking in System.Security.Claims.WindowsIdentity and it exits with a null exception as there is now no more authorization information. I am also using IdentityServerV3. I apologise for the lack of specific technical data but was wondering if anyone has ever had this issue. There is no specific time that this does this after as I first thought it might be expiring. It happens very randomly. I have included screen grabs:
This was when I was authorized
and this was 10 seconds later
If you need any further infromation let me know and thanks in advance!
I had similar issue where losing authentication randomly, caused by three reasons I can remember,
1) multiple threading - code was executed by a different thread that doesn't have identity context
2) cookie size exceeded browser limit authentication cookie get chunked when pass back to server
3) identity server hosted in multiple instances and identity server configured to store token in memory.
Regarding your case, my gut feel which might be completely red herring, is the 1) which the thread executing your code 10 sec later is under a different identity context , I would suggest try to verify any path of your code can by multiple threading first, at the mean time check the thinktecture log that can be found in output window if you are using default logging provider to see if anything suspicious
Hope it helps
(APEX 4.1.1.00.23)
I have two applications A and B that share the same session (because they use the same session cookie), and each has Maximum Session Idle Time set to the same value N. Having established a session and visited both applications, if I then spend more than N seconds working in application A (doing lots of page loads so not timing out), if I then navigate to application B it immediately times out and sends me to its login page.
I tried also calling APEX_UTIL.SET_SESSION_MAX_IDLE_SECONDS(N) in both applications, with p_scopr defaulting to 'SESSION', noting that the API docs say
This would be the most common use case when multiple Application
Express applications use a common authentication scheme and are
designed to operate as a suite in a common session.
However the same thing happens.
I want the timeout to apply to the session as a whole, not to each application independently. Is this not what the above is supposed to achieve, or am I doing something wrong?
I got the answer to this from Christian Neumueller on the Oracle APEX forum:
... it's no issue anymore in 4.2. Looking at the 4.1.1
code, it seems that the problem is how we stored the last access time.
While the APEX_UTIL call with SESSION scope would set the idle timeout
for both apps, we maintained a timer (FSP_LAST_REQUEST_TIME) for each
app. Working in TIMTEST1 only updated the timer for TIMTEST1, not for
TIMTEST2. After working with one app and switching back to the other
app, Apex sees the stale timer and decides that the session expired.
This is clearly a bug. The bad news is that a backport is not
feasible, because so much has changed in session state management.
I have an MVC 4 app and am using the default authentication provider. I'm not using persistent cookies.
I don't have any problems in development but when hosted at HostGator, I SOMETIMES get logged off when I try to create a new item (HTTP POST). When this happens, I end up at the log on page like I wasn't authenticated.
HostGator does NOT have the app on multiple web servers so I'm thinking I shouldn't have to worry about machinekey stuff. Am I wrong?
When this happens, I just log in again and create the item again and it will succeed. Once this happens, I can't recreate the issue. I try reopening the browser and even different browsers but creating items will always work. It only seems to happen again if I try much later.
Some additional info, the timeout is set to 2880 (the default for an MVC project), which I know is long but I can't see how it would be related. Still, thought I'd mention it.
So I can't look at IIS logs or event viewer to get any idea what could be happening but I can add more logging to the app. Can anyone provide ideas for what to check or what logging to add to diagnose?
Thanks
EDIT
I realized that I could get to the IIS logs so I compared the POST that succeeded and the one that failed and immediately noticed something.
When I first did the GET to load the Item/Create page/view, the cs-username was populated but when I did the POST to create the item, it was gone. I can see that when I logged in again and was able to successfully create the item, that POST did have the cs-username populated.
Why would it disappear between the GET and the POST? There was a 7 minute delay from the GET to the POST but I can see I logged on 1 minute before the GET so the session was only 8 minutes old when the post happened. I've double checked that I don't have sessionstate explicitly configured so the default should be 20 minutes. I feel like I'm onto something but not sure exactly what.
Might be worth adding Glimpse, although running that on deployed code is kinda risky. It would have the benefit, though, of letting you see what's actually happening on the server. I've never used HostGator, so I can't say for certain, but if they recycle app pools aggressively, that would invalid your login, and explain why the logoff seems to happen randomly.