I'm developing a web application that needs to access 100 or more different Google Calendars using OAuth2. All the calendars are on different accounts with their respective users. I came across this paragraph from Google:
"Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients. You should save refresh tokens in long-term storage and continue to use them as long as they remain valid. If your application requests too many refresh tokens, it may run into these limits, in which case older refresh tokens will stop working."
My app, as advised, is using access tokens and then storing the refresh tokens in a database for later use. I am wondering if I will reach a limit to the number of calendars my refresh tokens will work with? Has anyone experienced difficulty before with refresh tokens stop working after a limit is reached. The paragraph mentions two limits but I'm not sure if my app will be affected as each calendar is a different user. I'm not sure what Google means by 'and another per user across all clients' limit?
Anyone with experience or knowledge in this please help.
Thank you in advance.
Neither of the limits applies to your scenario, so you shouldn't have any problems.
The "one limit per client/user combination" is 25, so you can't obtain more than 25 refresh tokens for any given user. But you only need one, so that's fine.
"per user across all clients" is saying either:-
that a user can only authorize a certain number of projects, but I'm guessing that's a pretty big number.
It's saying there is a limit on how many clients per project are allowed, but again, you only need one.
Here is the doc that shows the limit of 25 tokens:
https://developers.google.com/identity/protocols/OAuth2
Related
In one of my Projects i need to implement Login Step-up. That means a user can login an application with simple username and password to get some readonly access access on website and API behind it.
If user want to performan any sensetive data operations like "write/update", he need to authenticate via second factor (via SMS code).
second factor login is for maximum 10 minutes valid, if user does not interect the website for 10 minuets, he will be automatically logout from second factor, but he still remain logged in with one factor.
can identityserver4 support this szenario out of the box? or do i need to implement it by my own ?
Here is my solution proposal:
for one factor login, identityserver provide a one factor scope, which client need to understand. it provide a access token which also have limited scope.
when client application need two factor scope, it call identityserver again where user must provide second factor authentication. hence a new token with second factor scope sent back to client. with this token client can call API methodes which need second factor authentication.
second factor authentication token has a validity of 10 minutes
after 10 min token is invalid, but one factor token is still valid as it has long life time.
Questions:
- Can IdentityServer4 offer Login Step-up out-of-box? if no, what are the alternative solutions ?
what is your suggesstion regarding my solution proposal?
Thanks in Advance
What you wrote in the bullet points is basically how I'd see it implemented in IdentityServer4. It's just setting up two different scopes and issuing two separate tokens for the same user. First scope 'readonly', lifetime=24h, acceptable only by safe operations in the application api, second scope 'full' with lifetime=10mins acceptable by all operations. No big problem, it should be perfectly doable with basic IdentityServer4. However, you will have to RT(F)M and configure the scopes, clients, tokens, etc. in the IdentityServer4 config. And also, you'll have to implement the two-token access policies in your app's backend api implementation, and of course client apps will have to be careful about which token they obtain and which token they use for which backend call.. but all of that is more-or-less obvious (and you seem to understand that, judging from that bullet points) so I don't quite see what you'd want by saying "out of the box" or what are you worried about in terms of support for that on the IdentityServer4 side..
We have a couple of users which we might are sharing their user account with other users. We are thinking on adding functionality within IdentityServer4 which limits the number of concurrent sessions a user can have to prevent this behaviour.
This won't prevent the users from sharing user accounts from time to time during the day, but we will at least be able to stop concurrent use of our systems.
We are thinking on counting the number of refresh tokens used by each user account and if they exceeds a certain limit, the oldest refresh tokens and access tokens are deleted for that user, this until the amount of refresh tokens is equal the allowed limit.
Any input on how this functionality can be implemented using IdentityServer4? We would also like to inform the user why the reference token was deleted therefore causing an log-off.
Logically when a user exceeds its limit of concurrent sessions, it still should have the ability to be authenticated, so I would vote against considering identityserver as the right place for such functionality.
What are you planning to return to the user when limit is reached? you are not authorized to access this resource? this does not sound right.
I recommend applying such feature in the resource itself, count the current sessions using your application logic, then redirect the user to a page telling that limit is exceeded.
UPDATE:
Check this Github discussion where IdentityServer contributes responded to a relatively similar query.
https://github.com/IdentityServer/IdentityServer4/issues/736
I have just developed a mobile apps which basically for users to upload, download photoes, add, update, search , delete, refresh transaction, and query report. Every action need submit request to Appengine Server.
I am using CloudEndpoint, oAuth2.0 and Objectify to implement this appengine. When I'm testing alone, The instance hours has used up 40% . How much billing for instance can I imagine if 100 people using this app? How does it calculate the instance hours? by request of submitting? or by time of instance working on multiple request??
is it worth?
If my target is more than 100 users to using my apps. Is it worth? Could you please share me what exactly I misunderstood about this instance.
Thanks
As others have commented, the question is very hard to answer. The easiest answer I can think of is by looking at the response header "X-AppEngine-Estimated-CPM-US-Dollars". You have to be a member of the Cloud Platform Project (see the Permissions page in Cloud Platform developers console) to see this header (you can check it in your browser).
The header tells you what the cost of the request was in US Dollars multiplied by 1000.
But think of it as an indication. If your request spawns other processes such as tasks, those costs are not included in the number you see in that header.
The relationship between Frontend instance hours and the number of requests is not linear either. For one, you will be charged a number of minutes (not sure if it's 15 minutes) when the instance spins up. And there are other performance settings that determine how this works.
Your best bet is to run the app for a while against real users and find out what the costs were in a given month or so.
Recently I came across an old project for Nokia Asha with app tracking in it.
For every screen accessed by the user a Http request would be made to report to the analytics service and one of the parameters sent was the IMEI in the mobile device.
As far as I know, retrieving information like the IMEI on Windows Phone and iPhone is not permitted but on Android it's still an available function but requires the permission to read the state and identity of the phone which I've been told scare some users.
From what I'm seeing, using this kind of information is being discouraged in which case what alternatives are being more encouraged to implement to identify a device when it comes to analytics services or similar?
You can use a random ID to identify each client.
Odds: With a 64-bit random ID (using, say, nextLong()), the odds of accidental collision are exceedingly small. You'd need 4 billion clients to get the probability of the first accidental collision up to 1/2. This is plenty good enough for analytics.
Implementation: The server can use Java's SecureRandom to generate the ID and put it in a cookie on the HTTP reply if the HTTP request doesn't already have one. Either way, the analytics would associate that request with that cookie.
If the client is a native app rather than a web app, it will need to store the cookie and attach it to future HTTP requests.
Alternatives: If users need to log in to your app, then you can associate usage with their login ID. Otherwise, generate a token.
There are many reasons to not ask the user for their cellphone number including privacy, reliability, and annoying people. Many potential users will drop out rather than enter their cellphone number, while others will enter something like all ones. A random ID will be more unique.
If you need to do account validation via SMS, then you'll have to ask for a phone number. In that case you'll need a privacy policy, a data retention policy and plan, encrypted storage, you'll have to explain it to users, and cope with a substantial fraction of dropouts.
Even if you don't retain the phone numbers, you could construct a one-way secure hash from it to use for the client ID, but phone numbers get recycled so over the long term, random IDs will be more unique than verified phone numbers.
I read somewhere that the Salesforce API has a 10 request limit. If we write code to integrate with Salesforce:
1. What is the risk of this limit
2. How can we write code to negate this risk?
My real concern is that I don't want to build our customer this great standalone website that integrates with Salesforce only to have user 11 and 12 kicked out to wait until requests 1-10 are complete?
Edit:
Some more details on the specifics of the limitation can be found at http://www.salesforce.com/us/developer/docs/api/Content/implementation_considerations.htm. Look at the section titled limits.
"Limits
There is a limit on the number of queries that a user can execute concurrently. A user can have up to 10 query cursors open at a time. If 10 QueryLocator cursors are open when a client application, logged in as the same user, attempts to open a new one, then the oldest of the 10 cursors is released. This results in an error in the client application.
Multiple client applications can log in using the same username argument. However, this increases your risk of getting errors due to query limits.
If multiple client applications are logged in using the same user, they all share the same session. If one of the client applications calls logout(), it invalidates the session for all the client applications. Using a different user for each client application makes it easier to avoid these limits.*"
Not sure which limit you're referring to, but the governor limits are all listed in the Apex documentation. These limits apply to code running in a given Apex transaction (i.e. in response to a trigger/web service call etc), so adding more users won't hurt you - each transaction gets its own allocation of resources.
There are also limits on the number of long-running concurrent API requests and total API calls in a day. Most of these are per-license, so, again, as the number of users rises, so do the limits.
Few comments on:
I don't want to build our customer this great standalone website that integrates with Salesforce only to have user 11 and 12 kicked out to wait until requests 1-10 are complete?
There are two major things you need to consider when planning real-time Sfdc integration beside the api call limits mentioned in the metadaddy's answer (and if you make a lot of queries it's easy to hit these limits):
Sfdc has routine maintainance outage periods.
Querying Sfdc will always be significantly slower than a querying local datasource.
You may want to consider a local mirror of you Sfdc data where you replicate your Sfdc data.
Cheers,
Tymek
All API usage limits are calculated over 24 hours period
Limits are applicable to whole organization. So if you have several users connecting through API all of them count against the same limit.
You get 1,000 API requests per each Salesforce user. Even Unlimited Editions is actually limited to 5,000.
If you want to check your current API usage status go to Your Name |
Setup | Company Profile | Company Information
You can purchase additional API calls
You can read more at Salesforce API Limits documentation