amazon-archives / amazon-cognito-identity-js

Amazon Cognito Identity SDK for JavaScript
Other
985 stars 451 forks source link

Most confusing thing ever #408

Open bradennapier opened 7 years ago

bradennapier commented 7 years ago

Ok so what the... hell? aws-sdk is useless in this case? No information here. You hve multiple api's and sdk's for javascript and only the one that you don't even mention supports promises? Am i not supposed to the use the built-in aws-sdk for this and instead use this EXTRA library for some reason which appears to not support things and works differently yet has some of the same functions from what I can tell?

Is this just a wrapper around aws-sdk to make things easier?

In my case I do everything through API Gateway/Lambda so I want to handle the auth flow through that rather than directly using AWS in the app itself -- however it appears you don't have documentation that I can find for the actual SDK and instead only for this wrapper -- are there reasons for that ?

From what I can tell this is also not documented? You show some examples but I have no idea what will happen without reading through and leanring the code how MFA works -- I see mfaRequired will be called after the code is sent but I don't know what the callback will loook like and I don't know as f right now how I would event send the code to the API once the user provides it... I'm sure its all there in the code but having to read through all the source code to learn how you did it is kind of crazy.

Perhaps some sort of information anywhere on SPA_A or w/e and how to generate that? Nothing in any documentaiton I can see-- just says in one place "use SRP_A" -- Is that something we can create? Is it standard SRP ? Are there other ways to implement it? Is it a specific subset of the protocol?

Seems like it will take months to figure this all out

My bad, of course, if all this information is sitting in front of me and I am missing it.

If the InitiateAuth call is successful, the response will include PASSWORD_VERIFIER as the ChallengeName and SRP_B in the challenge parameters. The app will then call RespondToAuthChallenge with the PASSWORD_VERIFIER ChallengeName and the necessary parameters in ChallengeResponses.

Ok? So ... what are these mystical "required parameters" ? Nothing? This is just stupid

bdschr commented 7 years ago

I agree with you, the AWS Documentation seems to be very inconsistent for some services. This extra package seems to be topping that list.

MattEttler commented 7 years ago

I would also agree this is very confusing. I've found myself having to just trial and error/digging through the packages source code to try and comprehend anything. Would love some actual documentation on this package.

itrestian commented 7 years ago

This library is built on top of the main AWS SDK for Javascript that you mentioned. The main AWS SDK for Javascript just gives us the capability to make requests to the Cognito User Pools service operations.

This library mainly provides authentication by implementing the Secure Remote Password protocol described here: http://srp.stanford.edu/

The parameters you mention, SRP_A is generated by this client library and it is a large integer specified in the Secure Remote Password protocol. The other parameters are generated through this library and passed to the Cognito User Pools service to ultimately receive access, refresh, id tokens that this library manages internally to user retrieve, update, delete attributes.

pfeilbr commented 7 years ago

+1 The whole aws cognito service is disjoint and hard to grasp. This separate non-aws sdk npm package further exasperates the issue. Even the aws console UI for cognito doesn't fit in with the rest of the services. Totally feels like an org silo within aws. The aws-sdk cognito library should support what is included in this. This really feels like a bolt on. Not consistent with the rest of the "extremely pleasant" aws-sdk experience. I love solutioning with AWS, but this feels rushed / not thought through. DISCLAIMER: I understand identity and security is hard.

jhchill666 commented 7 years ago

Agreed. Confusing as! Some apis accept callbacks upon completion, some take { onSuccess, onFailure } objects. None use promises. No consistency at all!

To grasp what's going on is requiring a ridiculous amount of my time.

bradennapier commented 7 years ago

For what its worth, I have been attempting to equalize a lot of those issues and make things a bit easier to reason about. This is obviously pretty fine-tuned to my needs but you guys may find some clarity in looking through it.

I had originally planned to clean it up and build it into a library but haven't found much time.

https://gist.github.com/bradennapier/7b4d765c927f2972f8a1762ef200c04b

It attempts to bring most things which are asynchronous into promises and any multi-step callback situations uses a library called promise-queue-observable which uses promises to asynchronously communicate back and forth instead of the "magical" feeling callback web that the current implementation seems to create.