I want to limit the number of active sessions a user can have in Plone/Zope. We are selling access to digital content and ideally want to limit how many concurrent logins can use one set of credentials.
What would be the best way to achieve this?
Thanks,
Peter
You can try the NoDuplicateLogin PAS plugin. http://plone.org/products/noduplicatelogin
Related
tried to find an answer here but couldn't find one which would fit my needs.
I'd like to allow the users set the maximum sessions per user from an UI. So, the application would start with an unlimited number of sessions but if the user wants, they can just change a setting and define a number of sessions per user.
Right now my code is like this.
http
.sessionManagement()
.maximumSessions(-1)
.maxSessionsPreventsLogin(true);
So my questions is, how may I change maximumSessions per user from -1 to N number in runtime? Is it possible or I must restart the application?
spring-boot:2.6.7
spring-security-core:5.6.3
Thanks in advance.
How to add different rate limit in Jhipster-gateway? Means for different api end point.
As explained here, I think it's not possible:
Gateways provide rate-limiting features, so the number of REST
requests can be limited:
by IP address (for anonymous users)
by user login (for logged-in users)
I want to write a Server side script / daemon which would monitor multiple email accounts (might become quite a big number) and then send push notifications . My conceptual idea till now is: have a database with accounts and passwords. Iterate through that, check if any new messages are there and then react on that by doing smth with an email and sending push notification to the mobile device of the Client. My biggest concern is perfomance. Looping through thousands accounts doesnt seem right to me , but I cant come up with better solution. Registering an Observer for each account doesnt sound any better..
Any ideas? Im open to any languages (Scripting or programming). Not asking for code, just trying to wrap my head around the concept.
Thank you!
You could do it by blocks. Going one by one through all your database entries may take a long time if we are talking of thousands of accounts, maybe you could divide it on several scripts or script executions, taking, lets say, blocks of 100 accounts. So you would have an environment like this: script/thread 1 checking accounts from 1 to 100, script/thread 2 checking accounts from 101 to 200...
This could be done with threads on the same script/program, by using different scrips, or by using a "wrapper" to call the script many times as needed, depending on the amount of entries/blocks. You may need to keep an eye on you server resources, but performance of the checks should improve.
Hope this helps.
I'm currently integrate Google+ API to my service.
I'd like to know what's the limitation for this kind of api:
https://www.googleapis.com/plus/v1/people/{user_id}/activities/public
in google develop console, I found this:
Quota summary
Free quota 10,000 requests/day
Remaining 9,998 requests/day
99.98% of total
Per-user limit
5 requests/second/user
I think there will be two kind of limitation:
Application level
For example, how many requests can an app send per day(sum of the number for all users), and what's the max qps?
User level
For example, how many requests can an app send per day for a special user, and what's the max qps?
But I can't find the exactly info, does anyone know?
Can't say particularly about this API, but when I used Google Places api the quota was linked with IP address.So if it expired, we need to use different IP for hit.No user / application quota.
you already have those answers in your question:
10,000 requests per day in total, using that developer console key, thus your total "app" calls.
per user there is no limit, there is a rate quota. a single user could at most make 5*(seconds in a day) requests per day.
in this specific api case this is much bigger than 10,000 thus that rate quota is not that useful (except it prevents users from quickly depeting the 10,000 daily quota).
you can edit that rate quota so its lower or higher, and is used so a single user cant consume all the app quota (maliciously or otherwise)
I'm coding a new website that will need users to enter their mobile phone number, the problem I'm facing is that I need to make sure that the user is in fact the owner of (or in this case, has access to) the mobile number.
The solution I've come up with is, upon number submission I send them a SMS with a token and ask the user to enter the token on my website, much like Google Calendar does. However I'm on a short budget and I need to make sure user A doesn't submit 100,000 mobile numbers, if that happens I'll be out of business in no time, since each SMS sent costs me about 0.10 USD.
So far, I've come up with the following solutions:
use a CAPTCHA (keeps some users away and it is still vulnerable to manual registrations)
limit the number of tokens a given IP address request (dynamic IPs, proxies, etc)
limit the number of tokens sent for a given mobile number (a user can request tokens for all the available numbers and when the real user tries to request a legitimate token, his number will be already blocked)
None of these solutions are perfect, how do you suggest I approach this problem?
In a recent project, we were associating SMS numbers with a user account. Each account needed a CAPTCHA and email activation. The user could activate SMS via token, like you are using.
You could rate limit IP addresses (not a total limit). No more than 10 requests from an IP within 5 minutes, or something like that.
And/or you could limit outstanding SMS requests. After an IP address requests a token for SMS, it must be submitted before that IP can request for another SMS number. Or no more than 10 outstanding SMS tokens per IP per day.
Also, like #Alan said, we put a cap on our SMS messages per month.
I would use a combination of CATPCHA and Limit the requests of a Given Mobile Number.
In addition you should be able to specify with your SMS aggregator a preset limit per month. After you reach that limit, service is shutoff. That way if you are a victim of an attack, you will only be liable for a limited amount of money.
Instead of SMS, you can make use of an automated service that calls a phone number speaks out a One Time Password (via Text 2 speech). These services are similar in pricing to SMS, and less likely to get spam abused, as there is more overhead.
Twilio cost $0.03 a minute, or in this case, $0.03 a call.
You could do what Twitter does, which is have the user text you the token (rather than you texting it to them).
This will require you to find a provider that let's you receive texts for free (or close to it), but that might be easier.
Why is SMS costing you a dime? Utilize the EMAIL address that is associated with every SMS system (at least here in the U.S).
http://www.sms411.net/2006/07/how-to-send-email-to-phone.html
If someone tries their best to abuse a system, they will more than likely find a way to do it.
Using a combination of the techniques you've already come up with is likely the best way to thwart most malicious users.
Limit what people can do (no more than 10 requests from 1 ip in 10 minutes, one phone number can only recieve 3 texts a week, captcha before number entry), but more importantly, if people have no control over the content of the message there's no real reason to exploit it.