Amplify-js: Question about common code error using AuthClass

[Jasminou]

Do you want to request a feature or report a bug?

ask question
What is the current behavior?

just wondering if it's possible to have a list of common expected code error when we are using Auth class, something like this: https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html
where each method of Auth class is listed with its possible error codes.
this, will be very usefull in order to manage the different use case in our code. if something like this already exists, can you please refere it to me.
Thank's

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than AWS Amplify.

What is the expected behavior?

Which versions of Amplify, and which browser / OS are affected by this issue? Did this work in previous versions?
last version of Amplify with angular
You can turn on the debug mode to provide more info for us by setting window.LOG_LEVEL = 'DEBUG'; in your app.

[vahdet]

I also want a reference or documentation on it. For instance, when the user cannot be found for Auth.signIn, I want to route the user to the SignUp page. See the commented-out line below:

Auth.signIn(this.username, this.password)
        .then(user => {
          logger.debug('sign in success', user)
          this.$store.commit('account/setUser', user)
          return user
        })
        .then(
          this.checkUser()
        )
        .catch(err => {
          // HERE, ROUTE TO SIGNUP PAGE IF THE USER DOES NOT EXIST 
          this.setError(err)
        })
    },

[Adwich]

Maybe this could help you: This function is returning some of the error message upon login. You could check
if (err === 'User does not exist') //route to signup

[Jasminou]

@Adwich thanks, this is what i did to figure it out whe code error, by printing the errors. but it will be very usefull to have a clear documentation about that

[vahdet]

Well, I am also gonna give a try to that if (err === 'User does not exist'), but it still sends shivers to check for a such a specific case through a changeable string. I would at least prefer checking for a specific code assigned to 'User not exists' case.

[Adwich]

You could also check the use of AmplifyMessageMap.js that is transforming
the error into those messages too.

2018-05-22 5:05 GMT+09:00 vahdet [e-mail]:

Well, I am also gonna give a try to that if (err === 'User does not
exist'), but it still sends shivers to check for a such a specific case
through a changeable string. I would at least prefer checking for a
specific code assigned to 'User not exists' case.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aws/aws-amplify/issues/786#issuecomment-390766396,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APo99J1O-FSfmUcnus6NHLcNLsTxdudWks5t0x4MgaJpZM4TxjMC
.

[Jasminou]

@Adwich AmplifyMessageMap.js doesn't contain all the errors

[ken0x0a]

About "AmplifyMessageMap.js",

https://github.com/aws-amplify/amplify-js/blob/master/packages/aws-amplify-react-native/src/AmplifyMessageMap.js#L37

I think this line should be
return I18n.get(msg, msg);

or

    [
        'Invalid phone number format',
        /invalid.*phone/i,
        'Invalid phone number format. Please use a phone number format of [phone]'
    ]
// and
    const msg = entry.length > 2? entry[2] : entry[0];

are unnecessary code.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ericclemmons]

I agree there should be clearer error codes (e.g. error.code) to key off with Auth calls. This is being factored into some internal work taking place.

One restriction is on the service side with what we have available:

https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_SignUp.html#API_SignUp_Errors

The other is that any improvement upon that by the library will be somewhat brittle and based on error.message values.

One approach we're evaluating is, rather than errors, but providing an "Auth state" (think state machines) that's consistent with how we manage Auth flows in <AmplifyAuthenticator>.

For now, there's not immediate action we can take besides keying off of typeof error, error.code, and error.message: it's what we use from the service calls as well.