I've searched everywhere but still cannot find a clear explanation of the user timeout process for IdentityServer3. The default seems to be 5 minutes - if a user is idle for 5 minutes, then clicks a menu link, the user gets kicked out. I need to extend this to 20 minutes.
I understand the cookie has its own settings, and I am ok with the default 10 days...but can someone explain how to extend the client idle time to 20 minutes?
thanks!
Related
I have built a flutter app where user is created at backend WEB, in App users can only Login.
What I want to do is if the user attempts multiple failed attempt to login assume for 3 times, I want Login to get disabled for 5 minutes to the user.
help me how to approach it and the best suitable solution.
1.) Create a variable (global variable/ provider) "failed attempts".
2.) On failed attempt increase value =+ 1.
-> When user typed the correct password, delete the current count.
3.) When user failed 3 times -> save CurrentTime in the preference.
4.) Check it before attempting to login again.
-> Current time < (5 Minutes) compared to saved time
-> show popup "Sorry, you have to wait 5 minutes".
As nvoigt pointed out, you can/should store the variables in the backend, to increase security.
I would suggest using storage to store the DateTime of the last failed attempt after N number of failed attempts & checking if current time has passed X days or Y Hours or Z minutes and so on...
Note:
While I am suggesting using the storage for this, it is just out of convinience for you to implement & get going. It is not reliable as the user can change device's date & time settings or can reset/clear storage data.
In case if you are looking for a more secure approach with the same technique use something like firebase DB & Internet time instead of local storage & device time.
What I want to do is if the user attempts multiple failed attempt to login assume for 3 times, I want Login to get disabled for 5 minutes to the user.
This logic must be placed in the backend. When you call the login method on the backend, the backend has to keep track of how many unsuccessful tries there were and then lock the account for a specified time. Make sure you send a specific error code about the account being locked for the period to the frontend, so the frontend can display it and notify the user that trying to login is pointless.
There is no need to block the frontend from trying though. A malicious attacker will work around your protection anyway and a normal user may have reasons to try again (maybe with a different account).
You can use Timer class (link) and set needed delay to it. Block button at incorrect login action and after time runs out set it available again.
Following is my scenario, I need to run the below test with 5 users for 10 minutes. Flow is login -> verification -> 360screen --> logout. I need all the 5 users to login and run verification and 360 screen for about 10 minutes and logout 1 by one. I dont want the test to run login and logout multiple times. Any suggestions?
Use a during loop. This is a very basic question, so you should take some time to read the documentation and have a look a the Gatling Academy.
We're building an app that uses the API v2 to interact with Watson Assistant. We're aware that the "state" of the conversation (among others: the position in the dialog tree) is now kept on the service side using the session_id key.
The problem: the session expires (5 to 60 minutes depending on the pricing plan).
Is there a way to either resurrect an expired session or save the conversation state so that it can be restored ?
We've tried to save and restore the global & skills contexts but they don't hold the conversation state.
Thanks for your help.
The current inactivity timeout period is plan-specific
- lite and standard 5 minutes
- plus and premium 1 hour
In the coming days, you will be able to change that value for plus and premium up to 24 hours. Lite and Standard you will only be able to decrease to a lower value if you want to close sessions faster.
You can always save context at the application level but currently there is not a way under the V2 API to save where the user is in the dialog so that you can pass it back after exceeding the allowed session inactivity timeout period.
Complementing what #oscar.ny mentioned, it's also plan-specific and you could potentially change the timeout timing on the Settings -> Timeout limit field -> Change the value and close, it saves automatically.
Something that I've done before in the past was sending an empty message when the event of 5min inactive happened. This event would call the function that would hit the API message method to send an "Are you still here, I was talking about xyz". Where xyz was the latest message sent to the user to maintain the session.
Ref:
change Timeout limit
I see there is a limit that a user has to respond by before the conversation ends:
"Your response must occur within about 5 seconds or the Assistant assumes your fulfillment has timed out and ends your conversation."
How long does it take for the app to time out and exit the conversation
But is there a maximum that a user can respond for (type voice)? We want to allow for longer responses (and then access the response text).
Ideally we would like an unlimited response time and the ability to access the raw input (type voice) when received
It would be excellent if we could access the audio from the user's response, but as I understand that is not possible.
As I explained here, you can't have access to the raw audio recordings of interactions with your actions as of now. You only get access to the transcription of the user's utterance.
The quote you've supplied:
"Your response must occur within about 5 seconds or the Assistant assumes your fulfillment has timed out and ends your conversation."
isn't about the user's response. Your webhook fulfillment must complete in 5 seconds, otherwise, your system persona will time out.
As far as the length of users prompt goes; if the user doesn't say anything it will trigger a no-input prompt (on smart speakers) or just close the mic (on smartphones) in around 8 seconds. (I don't know if there's an official resource that proves 8 seconds, this is just my experience)
But once the user starts speaking, it will keep listening until the user stops talking. So you can theoretically have a long prompt from the user. However, I wouldn't recommend this since it would be a terrible user experience if you look at it from a conversation design stand point.
I have configured Google authenticator on Linux and my mfa is working fine, but according to me an MFA token should expire in 30 seconds but even after 30 seconds time I am able to use the token.
If I use the token then it is not reusable but if don't use it within my 30 seconds then I am able to use it after sometime also. Is this normal? I want my token to expire in 30 seconds even I used it or not used it. Can somebody help me on this?
Although your timestep might only be 30sec, the RFC specifies that the validating service should search the OTP value back and forth in time. This is recommended due to the drift of the clock. https://www.rfc-editor.org/rfc/rfc6238#section-6
This is why, most systems (including Google itself) allows one previous OTP, so while the code regenerates every 30 seconds, every OTP remains valid for 60 seconds.
You need to check your server-side settings
you must to set PeriodDiscrepancy to 0