I am using a python connector to use snowflake from backend , I need a query or something to check whether my account is valid or it got expired basically for trial account, In Snowflake UI it is showing the error but when using the python connector I need to get a similar error like at the time of login itself
"you trail has expired" is not really a thing that people "normally" need to programmatically know about.
Unless you are repeatedly "programmatically" making more accounts, which seems against the purpose of the free accounts.
I would think that you python would start failing to log in, which it should back off and try again after an escalating timer (1s, 10s, 60s,..) but at the same time tell you there is a failure (of some sort) and at the time the account expires. You stop running your automation/python code.
Right, so I can't find any questions similar to my issue or any possible fixes for my issue.
Basically, I have a Blazor App (Server-Side) which makes use of Individual Account Authentication with use of Roles.
A section of the App, is a listing of currently Logged-In users (Using Signal R, to check for Users currently Logged-In by using a simple List of Users and their last "pinged" datetime.)
A ping happens every 10 seconds to query all connected users, and return their user.Identity.Name along with the DateTime at the moment of ping. Then the DateTime is compared in the list and if any of the Users last pinged time vs latest pinged time is greater than 15 seconds, we assume they are no longer logged in, or have the Tab open and remove them from the list. This all works well enough since we ping every 10 seconds, and have a 15 sec window before marking as logged out/offline.
The problem however, is the AuthenticationStateTask seemingly retains a users Identity even when Logging out?
Eg. I log in as User1 > pings happen as expected. I log-out. Pings still happen... it still hits the AuthenticationStateTask and still picks up a User identity somehow (And still shows as Authenticated). I then log in as User2, and start getting returns for both User1 and User2.
As extension to this problem, even closing the browser window after logging out doesn't actually stop pings from happening... only when completely closing the browser will the pings stop.
If anyone has any clue as to why this is happening, please let me know. Even if I'm being silly, and the problem is obvious tell me where I messed up. If more information is needed let me know, and I'll update.
Much thanks!
I authorized the group of a user to the cockpit-application. I gave the group full access to the Process Definition and Process Instance authorizations. (so pretty much as described in the documentation)
When I try to log the user in, I see the Welcome screen and in the application overview the option to navigate to the cockpit-application.
However, when I click this, I get the Login screen again.
For a fraction of a second I see the cockpit application, but then it immidiatly redirects to the login page. When I try to log in again, it keeps redirecting me to this login screen.
I configured another group to use the Tasklist application and that is working as expected.
I tried to give the authorization on user-level instead of group-level but the same problems occurs.
(n.b.: I am using the Spring-Camunda-Starter for this application.)
I found the problem, I accidentally removed one of the authorizations the system automatically creates when the user is created. I think I might have removed this, as I thought it was not necessary.
It is in the User Authorizations, every user has an authorization from it's own user to that user. When I added this, it fixed the problem.
I found the solution when another user logged in and had no problems. And the found this to be the only difference between the two accounts.
Hopefully this will help someone in the future!
When using Cognito's forgotPassword function, I get a 'LimitExceededException' error if I try to run the forgot password method more than 5 times.
Is there further documentation on this at this point?
This question brought up a similar point several years ago, but there was not guidance on any documentation. And this question brought up a similar issue, with comments noting in frustration there is no guidance on how long to wait.
I am hoping there is guidance available on:
How long does a user need to wait before trying it again? It's not helpful to my users to say "Please try again later", without any guidance on when. In my testing, I waited more than 30 minutes after, and the error still appears. This seems excessive for users.
Can I add this protection to the signin process? (not just the reset password process). This security protection does not appear to occur in the case of signing in. There, I can enter an incorrect password multiple times without a "too many attempts" type warning. I'd assume that is an important security step.
According to https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html,
We allow five failed sign-in attempts. After that we start temporary lockouts with exponentially increasing times starting at 1 second and doubling after each failed attempt up to about 15 minutes. Attempts during a temporary lockout period are ignored. After the temporary lockout period, if the next attempt fails, a new temporary lockout starts with twice the duration as the last. Waiting about 15 minutes without any attempts will also reset the temporary lockout. Please note that this behavior is subject to change.
I am currently building an internal web application used in a factory/warehouse type location. The users will be sharing a single PC between several people, so we need to have a fairly short session timeout to stop people wandering off and leaving the application logged in where someone else can come to the PC and do something under the previous user's username.
The problem with this is a session can timeout while a user is currently entering information into a form, especially if they take a long time.
How would you deal with this in a user friendly manner?
Keep the server informed about the fact that the user is actively entering information.
For instance send a message to the server if the user presses the TAB key or clicks with a mouse on a field.
The final solution is up to you.
Use AJAX to regularly stash the contents of the partially filled-out form so they have not lost their work if they get booted by the system. Heck, once you're doing that, use AJAX to keep their session from timing out if they spend the time typing.
The best advice would probably be to ask the users to close the browser window once they're done. With the use of session-cookies, the session will automatically end when the browser is closed or otherwise on a 30 minute timeout (can be changed afaik).
Since there by default is no interaction between the browser and the server once a page is loaded, you would have to have a javascript contact the server in the background on forms-pages to refresh the session, but it seems a bit too much trouble for such a minor problem.
If the session timeout is so short that the user doesn't have the time to fill in a form, I would put an AJAX script that makes a http request to the server, every few minutes, to keep the session alive. I would do that only on pages that the user has to fill in something or has already started filling something.
Another solution would be to use a session timeout reminder script that popups a dialog to remind the user that the session is about to time out. The popup should display a "Logout" and a "Continue using application" that makes a ajax request to update the session time out.
Maybe that a keep-alive javascript process could be helpfull in this case. If the script capture some key triggers, it send a "I'm still typing" message to the server to keep the session alive.
have you considered breaking the form into smaller chunks?
Monitor the timeout and post a pop-up to notify the user that their current session will expire and present "OK" or "Cancel" buttons. OK to keep the session going (i.e. reset the counter to another 5 minutes or 10 minutes - whatever you need) -or- Cancel to allow the session to continue to countdown to zero and thus, ending.
That's one of lots of ways to handle it.
Using a JavaScript "thread" to keep the session open is, to me, a bad idea.
It's against the idea of session timeout which exists to free some resources if there's no user in front of the application.
I think you should adjust the session timeout with the more accurate time, in order to fill the form in an "typical normal use".
You may also be proactive by :
having a JavaScript alert displaying a non-intrusive warning (not a popup) to the user before the timeout expire, which say that the session will expire soon (and give an link to send an ajax request to reset the timeout and remove that warning - that will avoid the user to lost the form he is currently typing),
and also have a second JavaScript "thread", which, if the session has expired, redirect to the login page with a message saying that the session has now expired.
It think that's the best because it avoid the user to fill a complicated form for nothing, and handle the case when the user has gone away.
As an alternative for the technical solutions, you could make your application in such a way that everytime a particular job is done, for example filling in a form, you ask the user if he wants to continue doing another job or if he's done. Yould could have a startscreen with menu options and if the user chooses an option he first has to enter his credentials.
Or put a password field on the form. Depends on how many forms they have to fill in a session.
When the user posts the form and their session has timed out, you should make sure you save the form values somewhere and then ask the user to login again. Once they have re-authenticated you they can then re-submit the form (as none of their data will have been lost).
I had developed something requiring very long session. The user logged in on a page when he sit on the machine and after doing his work, logged out. Now he may use system for few minutes or for hours. To keep session alive till he logged out, I used timer with javascript, it went to server and updated an anthem label with current time on server.