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
Related
In salesforce, can we allow specific user to login one at a time globally ? If he is login into the salesforce already, then he should not be able to login again, unless first active login gets loggoff. Is there any way we can achieve this using OOTB?
I don't think this is possible. Sessions in Salesforce can be locked to the original IP address though, which would prevent you from logging from two different locations. You can also set sessions to have a 15 minute timeout, so if they logged in a second time, after a little bit, the first session would be terminated.
I have an application deployed on GAE. It allows users to register for an account, and I use the google user id as the primary key to link to their account.
I have a registration link that should be visible if either the user has not been authenticated by google and/or they do not have an account on my site.
What I am trying to figure out is what is the best way to figure out if the user has an account on my site as they go from page to page. I have an authentication filter that is triggered on every page, and the filter looks at their google id (if they are logged in), goes off and determines if the user has an account on my site, and sets a request parameter, that I use in the jsp to determine whether or not to show the registration link.
It seems wasteful to do that every time, so I refactored it and had the authentication filter store the Key object tied to their user account on my site in a Session. If the key attribute is not null, I take that to mean that the user is registered on my site.
Does that seem logical, or are there better approaches? The complexity to me comes from the fact that the user may be logged in with google, but that doesn't necessarily mean they have an account on my site.
My question
When it comes to storing authentication data, you have two options :
Store the data in session
Store the data on client side, in a cookie typically
Storing the data in session is a perfectly valid mechanism, and that's actually the most common.
However, managing a session is costly (you need to store it). In App Engine's case the sessions are stored in the Datastore, with probably some caching. So it's still a call to the datastore.
That should be totally acceptable, however if it turns out managing a session really decreases you app's performance, you can always store the data in an encrypted cookie. That way the information is provided by the browser every time it sends an HTTP request. Note that it means you must get encryption right and that HTTP requests will be slightly bigger (the size of the encrypted data).
So in the end it's a tradeoff. I would recommend sticking to sessions unless you experience performance issues. The advantage of sessions (compared to your fist approach) is that if you ever want to store additional data, you will have less code to add.
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
How to know if a user is currently logged-in in your Google App Engine application?
The application allow its users to browse other users' profile. If the viewed profile is also using or logged-in in the application, i want a notification that the viewed profile is online.
How to achieve this requirements?
If you are managing user profiles, you know when a user logs in. At the end of the login process, just save the user's log-in information in the memcache somehow.
You will later be able to check if a user is logged-in just by searching for him in your memcache.
This way is easy to catch and track the connection events, but you also have to react when a user disconnects, to have your list up to date. To achieve this, you can use a Channel. See the google documentation.
You could, as Gaël suggests, use the Channel API to track this, but it's probably overkill. If you wanted to go that route, just listen for the connected & disconnected messages, and update a field in the db that indicates that the user is signed in.
A less expensive route might be to just update a field in your user's record that's something like "last time this user requested a page." If it's been more than n minutes since the last time the user requested a page, assume they're signed out. Indeed, you could even do this in memcache with a map from userid to last access time.
It comes down to what you want to do with the "signed in" information: if you just want to give a general sense of whether a user's around, or how many users are online, using the datastore or memcache solution is probably good. On the other hand, if you want to reflect the user's presence so they can respond to eg. IMs, then you'll probably want the Channel API anyway so you can immediately deliver messages to them.
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