I'm currently working on a way to hand off creation of users in a Userpool to my product team so that I don't need to handle user creation and password resets anymore. The key here is that the tool I give them needs to be simple and non-technical, and not require them going into was with permissions, knowing how to use Cognito and make the users within Cognito. This also needs to not be a public facing signup (i.e. the folks using the page need to never see the signup form). This is for my team's developer documentation which integration partners cannot see until they meet with us.
Looking at all the possibilities and the AWS API documentation has been making my head spin, though. I'm not sure what the best way to create this tool - the Cognito SDK? The AWS AdminCreateUser API? Or is there a way to set this up with the built in signup page UI provided by Cognito but host the signup page elsewhere (somewhere that people who look at our documentation will never see a signup page)?
Please let me know what your approach would be if given this problem. I'm a pretty green jr. developer and don't have much experience with AWS.
If you really don't want to use the built-in Cognito UI to create users, you would need to come up with an alternative custom solution. Mind you will need to implement all features you expect from such user administration tool, including login for administrators into the tool itself.
With AWS Cognito APIs you can do everything native UI can do (and even more, like setting user attributes which is not available at Cognito console).
Quick google search led me to this project: https://github.com/jzoric/cognito-user-manager-ui which may be a good starting point if you decide to go this route.
Alternatively you may want to explore other SAAS solutions (Auth0 or Okta) which may provide better native UI out of the box.
I'm looking for the right approach to solve the following problem:
For my own non-business Instagram account I like to read which accounts follow me and which accounts like and comment my posts.
I read about the old and the new API, about API deprecation etc. Now I'm unsure which approach shall I choose?
Instagram Platform API
Graph API
other approach like browser automation (e.g. InstaPy)
Instagram/Facebook says "If you are building apps for Instagram Non-Business Accounts, please use the Instagram Platform API". But the process to get an account seams to be complicated. And as I understand until 2020 Instagram will deprecate this API completely.
Additionally as I understand the sandbox mode doesn't help me, since it is restricted and won't show the real results.
From what I can tell, you should use the Instagram Platform API. I think you're right that the Graph API is only for servicing Business Accounts.
I'm in the same boat. I made an app that lets users sign in with their own non-business accounts. Setup OAuth flow using the old API, which works in sandbox.
However, I submitted for approval this week and haven't heard anything. There's no way to contact Instagram or know how long it will take to get approved.
I personally have some experience with InstaPy and I can tell you that it is used mainly for directly interacting with said accounts. You can follow, comment, like, etc... on these accounts that follow you but actually accessing a list of all of them would be more tricky. That's why I wouldn't recommend browser automation for the goal you have set out for.
We would like to develop an app which can be used by multiple customers (of ours). Each app will be customized to each customer of ours.
What we are unsure about is how to handle authentication keys and API keys? Do we create one set of these for each of our customers or do we just have one account and all our customers use the one set of API keys. The latter approach makes me nervous because if one customer is banned (for what ever reason) then all my customers will suffer since they all share the same API key.
Any guidance from Postmates development team would be appreciated.
Currently, we do not support provisioning multiple API keys for a single account.
I recommend having each client create an API key. This also would allow your customers to use their own payment method, versus a single payment method for every customer.
Hope this helps, let me know if you have any more questions!
How to Signup and get LoginID and password to access RedBus Api?
From what it looks like, Redbus has not yet opened up the web service to the public. Aparently the web service exposed is for only Bus operators with their own credentials.
The API is open only to registered merchant or integrator. I got one and they will give based on your operation country. As in my case, I registered only for Malaysia, paid about 300 usd for the registration and given the api key. Although I would say their technical support is not the best as I've implemented in PHP and they didn't really have the expertise to support integration using PHP. The most problematic part is the seat selection process. The rest was quite straightforward.
I suggest that you take a look at their website and see what if there is any merchant registration link. As in my case, we came to their regional office and registered there.
Several web service APIs have you sign up for an API key. For example, UPS Web services requires a key, which is included in calls to their service -- In addition to the username and password.
What is this key used for by the provider? Perhaps UPS is the only one to require both API key and username/password?
One idea is that they use it to limit or measure API usage, but it seems to me that a setting in the users profile could easily do the same thing -- especially since you generally have to get an account w/ username and password to get the API in the first place.
There are two predominant use cases. The first is to measure, track and restrict API usage. If someone is building a service that allows third parties to access it, the service provider may want to control (or at least know) who has access so that they can try and prevent things like denial of service attacks. On the measure and track side, interesting information can be obtained such as knowing which applications are popular for accessing the service or which features people use the most.
The other use case is related to security and authentication. It is unwise for a service provider to have third party applications and services require users to give up their username and password for the primary service. This is a huge exposure. That is why many services are standardizing on protocols such as OAuth, which provides delegated access via authorization to a user's data. While not foolproof, it is definitely preferable to distributing user credentials to unknown, and untrusted, parties.
Most of the time it is to monitor how developers are using the web-api. If they somehow disagree with your usage of the api it provides a means for them to shut it/you down without hurting the other users. And the statistics per user/app are always valuable.
I've used the flickr api - in that situation the key is yours, but the login data might be those of people using your app, so the api key is the only way to differentiate between the apps.
Usually it used to get stats on how much application performing queries to API.
I think asking username/password with API key is ambigious in some cases, but it is a way how it is implemented - so we can't do something with it.
They ask for API key because you could have more than one API under same account - in case you have more than one site which are use same API.
They could use it to signify which version of the API you are trying to use. Perhaps in Version 1.0, there is a method that takes a POST on www.UPS.com/search and there is another one in version 2.0 at the same address, but takes a different parameter set, or even returns data in a different format/style. Your program was built on V1.0 and expects a certain API contract. They want to be able to create V2.0 without interfering with their customer's products.
That's just a guess, but it sounds good to me.
I think Gracenote does a similar thing for cddb. I forget the details, but I remember something about some token.
(They have/had really draconian rules about using their service too.)
Simon reminded me what the gracenote thing was. Gracenote and Fedex and other webservices have lots of developers writing apps for the software. So the developers get a token to put into their apps, but the end users have their own user name and password. It lets the services keep an eye on abusing programs, etc. That is probably te primary reason. (like a browser or a webbot informing the webserver who/what it is)
Originally, Blogger required you to apply for an API key (a la Google Maps) and used it to restrict access to the API. As Blogger evolved into Metaweblog, the requirement for the API became less important, and Blogger no longer requires you to apply for a key. As noted by others, it can still be used for tracking purposes.
In our situation, our clients want it for:
Tracking/analytics - figuring out who's doing what and building what products. Because a number of users are desktop apps, just looking at referrers isn't always enough.
Permissions - which resources should a user have access to? How can a user build apps that have access to specified resources?
Licensing/legal - enforcing that users have read and accepted ToU/licensing information.
Security - passing around usernames/passwords is a really bad idea.