I'm working on my enterprise SaaS application and some of my users would like to be charged on a per-seat approach.
I was wondering how to make sure that the access will indeed be limited. I can see right now that people with the same login/password are logging from different IP addresses, different user agents at the same time, even though the company have paid only for one seat.
What would be the best way to implement the limitation from business and technical perspectives? I don't want to be too strict, at the same time I want companies to pay for the number of seats they actually need.
Don't filter by user agent, I think that would be too strict, some people may have a variety of browsers installed. Filtering by IP could also be tricky, some users may have a dynamic IP that changes at regular intervals.
One idea I have would be to force users to install a browser extension, the browser extension could generate a unique ID from something on the operating system. Maybe use a HDD volume number or Windows serial key, anything that will be unique to that computer.
Once you have this unique ID, use it in the back end tracking every time the user logs in. If the user exceeds a certain number of seats you can either block the user account or contact them first.
It would also be a good idea to allow the user a certain amount of freedom, so that if they have one seat then the back end will allow maybe 2 seats for a month (rolling period), this would be in-case the user buys a new pc or installs a new HDD.
Using IP seems a bad idea - people in a LAN will (usually) all have the same IP.
Assuming PHP has no API to access inspect sessions different than the current one - one idea is:
if you're not already doing it, for each login cookie you issue, also issue an unique id (an UUID will serve your purpose)
store those ids somewhere (in java you could store them in the application context, maybe in php you'll need a db table for that - I'm no php expert), together with two timestamps: "session start" and "last activity"
at each request, record the current timestamp in "last activity"
Then, when you get a new request, count how many other active have
last activity >= current session start
last activity >= now - session TTL (only needed if can't prune expired sessions in a timely fashion)
That should give you the number of occupied seats.
Note you will not notice a violation of the number of seats until after the surplus user has logged in and precisely until you see activity in some other session – I don't see any way around this issue since you don't know exactly when a seat becomes vacant (well, you might say it's vacant only when its session has expired, but that seems unfair).
Related
Does someone know what "sf_max_daily_api_calls" parameter in Heroku mappings does? I do not want to assume it is a daily limit for write operations per object and I cannot find an explanation.
I tried to open a ticket with Heroku, but in their support ticket form "Which application?" drop-down is required, but none of the support categories have anything to choose there from, the only option is "Please choose..."
I tried to find any reference to this field and can't - I can only see it used in Heroku's Quick Start guide, but without an explanation. I have a very busy object I'm working on, read/write, and want to understand any limitations I need to account for.
Salesforce orgs have rolling 24h limit of max daily API calls. Generally the limit is very generous in test orgs (sandboxes), 5M calls because you can make stupid mistakes there. In productions it's lower. Bit counterintuitive but protects their resources, forces you to write optimised code/integrations...
You can see your limit in Setup -> Company information. There's a formula in documentation, roughly speaking you gain more of that limit with every user license you purchased (more for "real" internal users, less for community users), same as with data storage limits.
Also every API call is supposed to return current usage (in special tag for SOAP API, in a header in REST API) so I'm not sure why you'd have to hardcode anything...
If you write your operations right the limit can be very generous. No idea how that Heroku Connect works. Ideally you'd spot some "bulk api 2.0" in the documentation or try to find synchronous vs async in there.
Normal old school synchronous update via SOAP API lets you process 200 records at a time, wasting 1 API call. REST bulk API accepts csv/json/xml of up to 10K records and processes them asynchronously, you poll for "is it done yet" result... So starting job, uploading files, committing job and then only checking say once a minute can easily be 4 API calls and you can process milions of records before hitting the limit.
When all else fails, you exhausted your options, can't optimise it anymore, can't purchase more user licenses... I think they sell "packets" of more API calls limit, contact your account representative. But there are lots of things you can try before that, not the least of them being setting up a warning when you hit say 30% threshold.
One customer had a problem where an incorrect email (from another customer) was assigned to a case. The incorrectly assigned email is a response to a case that was deleted. However, the current case has the same tracking token as the deleted one. It seems that the CRM system uses the same tracking token as soon as it is available again. This should not happen! Here Microsoft has a real programming error from our point of view. The only solution we see is to increase the number of numbers to the maximum so that it takes longer until all tracking tokens are used up. But in the end, you still reach the limit.
Is there another possibility or has Microsoft really made a big mistake in the way emails are allocated?
We also activated Smart Matching, but that didn't help in this case either, because the allocation was made via the Tracking Token first.
Thanks
The structure of the tracking token can be configured and is set to 3 digits by default. This means that as soon as 999 emails are reached, the tracking token starts again at 1, which is basically a thinking error on Microsoft's part.
If you have set "Automatic replies", these will be reached in the shortest possible time. We therefore had to increase the number to 9 digits, which is also not a 100% solution. At some point, this number of emails is also reached and then emails are again assigned to requests that do not belong together. Microsoft has to come up with another solution.
I want to make multiple chatrooms like dynamic and I want to make them like this that if we refresh the page it retains the chat and users inside the rooms, I am new to socket.io and looking for the solution.
This is a pretty broad question so it's not really possible to be very specific with an answer. The general steps to retaining one or more "rooms" for a given user are as follows:
Install a session manager on your server. express-session is popular and you can then pick which data store you want to use with it (there are dozens of choices). This will give you a semi-persistent session object for each user who connects to your server.
When a user connects to your server for the first time, a session object and matching session cookie will be created that allows your server to identify that browser the next time it connects.
You can initialize a rooms property in that session to be an empty array or perhaps a Set object (which makes lookup a bit simpler for the later steps).
When this user gets put in a specific chat room, you add that room name to the session.rooms array or Set.
When the user leaves a specific chat room, you remove that room name from the session.rooms array or Set.
When a user re-connects, you look in their session and automatically join them to any rooms that the session says they should be connected to.
You probably need some sort of timeout process so that if a user remains disconnected for a certain period of time, you remove their session or at least clear their rooms list.
I am studying CalDAV protocol.
I have some question for time conflict or overlap for CalDAV.
Let me explain by instance for some scenario.
I made an event PM1 ~ PM6 in calendar. And then I try to made another event PM2~7 in same calendar. It is time conflict or overlap.
How does CalDav server resolve this conflict? Does server make error when second event make?
I did search out RFC 6638. But I could not find solution.
Please help my question.
Thanks for reading.
It is up to the CalDAV client to decide how to behave when overlap is involved.
If the client decides to write an event that overlaps another the server will write the overlapping event.
When scheduling is involved (userA wants to invite userB to a meeting but would like to avoid picking a time slot that is already busy in userB's calendar) the CalDAV client can query the FREEBUSY status for a user (see RFC 4791). There's also availability which allows a CalDAV client to retrieve a user's availability (think business hours).
The functionality Kim is asking for a very common one for business calendaring systems (not have the same person booked twice etc).
I think in the CalDAV world there are two parts to this:
a) First the client is supposed to perform a freebusy query to check
whether a user is available. And then show a conflict warning or
whatever seems appropriate.
This is how many systems, including btw Exchange work. Siri also does this kind of conflict detection (“hey, you already have an event at the time, shall I still create the conflicting one, master?”)
b) But in a reasonable system you actually need to guarantee that
the information isn’t outdated at PUT time. I.e. that no second
client has scheduled the same attendee/resource.
I think in CalDAV you can accomplish that by testing the sync-token or the CTag using an If header on the PUT. I.e. let the PUT only succeed if the whole underlying collection didn’t change. And if it did (the PUT will fail with a conflict), redo the freebusy, then try again.
I don’t think that there is a reliable way to do this in CalDAV cross collections (calendars), that is, if the availability of a resource changed because it got booked in a different calendar, the targeted sync collection won’t usually change its sync tag and the PUT would run through.
The bad thing about CalDAV (w/ scheduling) is that PUTs are not idempotent anymore. Otherwise you could do the PUT, recheck whether it still has no conflicts, and if so drop it after the fact.
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.