Say, for development purposes, I created too many vline users, i.e. in a loop.
Is there a way to remove/delete them completely from my service? Also, is there a limit on the number of users created?
Thanks.
You can't currently delete users in our system, but you can delete them or prevent them from logging in to your system through whatever user account system you are using. There is currently no limit on the number of users created.
Related
I need to implement an authentication system where a super admin can create multiple different roles with different rights for users. That is, not a system with a set number of roles, but have the option to create as many roles with different combination of rights as the superadmin wants, and then assign them to new users. Also with the option of editing these roles, deleting them etc. I'm fairly new at Node Js. Is this something hard to implement? Are there any articles/videos I can read/watch, to start understanding the process? Where do I start? I'd really appreciate any help. Thank you in advance!
You're thinking about Role-Based Access Control (RBAC). I have actually implemented this in Node.js before, feel free to checkout how I implemented it here: https://github.com/JLCarveth/nodeblog.
It's relatively simple. You need a table for tracking roles. Each role has 0 or more permissions. These permissions can be comma-separated strings, or IDs referencing a permissions table. Each user is then assigned a role.
Each route is protected with a middleware that specifies the needed permissions. If a user accesses this route, check that they have the necessary permissions and continue, reject if not.
I am working on a social app that needs to let users add new venues to Foursquare in rare occasions. Many if not most of these users may not have a Foursquare account, and I would then like to avoid requiring them to create one just for that feature.
I've read the related thread about Adding Venues without Authentication. Although ideal, this solution is unfortunately not accessible to us since we're a small startup.
So here's my question: could I use a single default FS account, that would be registered to my startup, to add venues on the behalf of all my users? In other words, each a time any user needs to add a venue, the app would be authenticating to FS using the same account in the background.
Would such model be allowed and supported by FS, or considered abusive?
Thanks a ton in advance for any guidance on this.
Since you said adding venues is a rare occasion that should work fine. You'll be rate-limited on that single authenticated account, but it shouldn't be an issue at low volumes. I believe the default limit is 500 requests per hour per authenticated user. If you're adding more than that, you're not a small startup :)
Is the baseUrl value returned per user or can it be used by all future users of the same account? I want to cache this value and as far as I can tell this is actually an account setting even though it's only retrieved after a user specific login. Any chance two users of the same account could have a different baseUrl? Just want to know at what level i really need to cache this.
thanks,
-mike
It is Per Account
Is the baseUrl value returned per user or can it be used by all future
users of the same account?
restapi/v{#}/login_information
This call will give you back the list of accounts that the username/password has access to. Along with the list of accounts, you'll receive the baseUrl for that account.
baseUrl defines two things:
The server that the account resides on
The account number
If there is a specific account that you're going to add users to, the baseUrl will be the same for future users of that account.
If you do not have multiple accounts logging into your application.
You can cache the information from this call so you don't have it in every workflow. It is mostly used for setting up new workflows and moving between Demo and Production.
If you do have multiple accounts logging into your application.
I would advise that you call this information at the start of your workflow. It'll ensure that you're calling the correct account for that user.
One thing to keep in mind, that 1 set of username / password can have access to multiple accounts. So you may receive more than 1 array as a response, your application should handle this accordingly.
DocuSign's LoginInformation method enables the implementation to provide dynamic re-direction of the clients at a macro-level.
Currently, or in the future, DocuSign might use the feature for a number of different reasons that I can imagine.
Using an undocumented "feature" (properties of the baseURL result) can result in a brittle client that may fail in the future. Be careful of the siren-song of pre-mature optimization.
The baseURL value changes only when you move from different environments (i.e: DEMO vs PROD). I would encourage you to store/cache it yes. Keep in mind when your application is ready for PROD, you will want to get the baseURL for PROD and store/use that appropriately.
I want to add venues to foursquare from my app but I don't want to make the users sign in into foursquare. I created one fake user that my server uses for all the real users of my application, but I'm afraid foursquare will block this fake user becauase it's going to add many venues, and from different places at the same time.
What's the best solution?
thanks.
Your set up is definitely not recommended, but as a way to mitigate your risks, limit the number of venues a user can create via your app (like 1 per day). Otherwise one abusive user can cause your entire user account to be suspended.
I've been asked to create a solution which detects the dead accounts and cleans it up from a SharePoint site.
I found a code snippet here (in the comments) which checks each user against the AD and cleans up the account. But the LDAP details are hardcoded in the code. What happens if i want to detect it dynamically and check the dead accounts? Is there a more elegant solution to do this?
Any ideas?
I looked at the code and it does NOT use LDAP at all. There are no authentication details anywhere in the code. All the code assumes is that an Administrator is running it from the server. It itterates the site collection users and removes them all.
This doesn't check for dead accounts. For that you'd have to check the value of web.SiteUsers[offsetIndex].ID against your LDAP database for suspended and/or deleted users and then ONLY remove those users.