in auth0 the user is active only if has authenticated in the last 30 days.
I have not found how to modify this value programatically
Is there a way to modify this value from 30 to 60 ?
Auth0 uses the concept of "active user" to determine how many users are using your applications, in order to charge you for the different pricing plans: https://auth0.com/pricing
If users don't log in for 30 days they will not count towards this total, but they will still be able to log in any time they want. This value can't be modified, for obvious reasons.
Related
whether I use the lastonline endpoint https://api.roblox.com/users/[USERID]/onlinestatus/, or the new presence one https://presence.roblox.com/docs#!/Presence/post_v1_presence_users, it's returning different dates and times for a specific user, lastOnline": "2022-02-25T06:56:39.283Z" from the presence one, 25-02 is the date their account was created, & "LastOnline":"2022-08-08T06:32:36.567-05:00" from the lastonline endpoint, date is right, given that the user was showing online and in a game today on the website portal, but the time is wrong
Say, data needs to be kept for 2years. Then all data that were created 2years + 1day ago should not be displayed and be deleted from the server. How do you manually test that?
I’m new to testing and I can’t think of any other ways. Also, we cannot do automation due to time constraints.
You can create the data with backdating of more than two years in the database and can test, if it is being deleted or not automatically, In other ways ,you can change the current business date from the database and can test it
For the data retention functionality a manual tester needs to remember the search data so that the tester can perform the test cases for the search retention feature.
By Taking an example of a social networking app , being a manual tester you need to remember all the users that you searched for recently.
To check the time period of retention you can take the help from the backend developer so that they can change the time period (from like one year to 10 min) for testing purpose.
Even if you delete the search history and then you start typing the already entered search result the related result should pop on the first location of the search result. Data retention policies concern what data should be stored or archived, where that should happen, and for exactly how long. Once the retention time period for a particular data set expires, it can be deleted or moved as historical data to secondary or tertiary storage, depending on the requirement
Let’s us understand with an example, that we have below data in our database table based on past search made by users. Now with the help of this table, you can perform this testing with minimum effort and optimum result. We have Current Date as - ‘2022-03-10’ and Status column states that data is available / not available in database, where Visible means available, while Expired means deleted from table.
Search Keyword
Search On Date
Search Expiry Date
Status
sport
2022-03-05
2024-03-04
Visible
cricket news
2020-03-10
2022-03-09
Expired - Deleted
holy books
2020-03-11
2022-03-10
Visible
dance
2020-03-12
2022-03-11
Visible
Using the latest Twitter API is there a way to get your followers handles? I don't know the correct term for this but I am referring to their name with that # symbol. For example: #MyTwitterHandle
The code I am looking for would do this.
///Necessary Twitter Code
Outputs:
Your followers are:
1. #IFollowYou
2. #MyTwitterHandle
etc...
35k more followers etc...
The most efficient way to do it is a two-step process:
Get all user IDs with followers/ids. This lets you get 5000 at a time.
Perform a users/lookup, which will give you the screen_name. This gives you 180 requests every 15 minutes for 100 users at a time.
This will take you about a half hour if everything is working well. The alternative, using followers/list, will take you over 3 hours because you only get 200 users in a 30 minute window (for app-only auth).
I was told redis was born for analytic, and I came across some bitmap using cases. They are useful when counting based on yes/no(0/1), but I can't find an efficient way to count the number of user who login at least 4 times during the last 10 days. Because redis runs in memory, I tried using bit map to keep track login flag of each user, and using bitcount to filer, on my laptop, it took a minute to return the count from about 4Million users' login activity.
Is there any way to solve this problem? I guess the round trips between my node redis client and redis server may be the issue, I'll try batch command or lua script to see if it works.
I think you need to use SortedSets with user id in value, and timestamp in score.
When user logs in, score (time stamp) for this user updates to current. Than you can get ether N last logged in users (ZREVRANGE), or users, logged in between some datetime range (ZRANGEBYSCORE)
I am working on Login Form in perl. I wish to limit 3 times for invalid login attempts for 30 min. In which way shall I use. Give me some idea where to store the invalid login attempts.
You have a few different options:
Cookies - least secure, as different browsers, clearing cookies, etc. can all impact this. Not recommend but listed for completeness.
Database - if you are using a database then you can create a table that records every failed login attempt. Within this table login_attempts you record the following values: date, username. Then during any attempted login you (pseudo SQL) SELECT COUNT(*) FROM login_attempts WHERE username = '$the_user_name' AND date BETWEEN '$now' AND '$now-30m'. If the returned value is >= 3, deny the login. Make sure you create a clustered index on username and date descending. If you are concerned about space then you can have a job that runs nightly and removes any records with dates older than, say, 8 hours. (Though left in tact this serves as an audit log.)
File system - this option is so Byzantine I'm not going to go in-depth describing it, assuming you have some sort of database backing store already in place. If you have to go this route, then it looks like the database solution, above, without the SELECT statement and likely involves user names as directories with a file containing each login attempt and where the (mtime + 30m < now) will have to be true to permit a successful login. You'd need to make sure you have mtime enabled for the disk of course, or record the time within the file.