Why I am not verified? It echoes hub.challenge only but the state is not verified.
Does your callback echo the challenge and return a 2XX? it has too, or the subscription will never be confirmed...
Related
The requested resource /Services/serviceSSID/VerificationCheck was not found is the eroor showing in the console
my code is
otpLogin:async (req,res)=>{
console.log(req.body.otp);
try {
const isOTP = await client.verify.services(serviceSSID).verificationChecks.create({
to:`+91${req.body.phone}`,
code:req.body.otp
})
if(isOTP)console.log(isOTP);
return res.status(200).json({message:" mobile number verified"})
} catch (error) {
console.log(error.message)
return res.status(500).json({message:"something went wrong"})
}
}
Twilio developer evangelist here.
From the documentation:
Twilio deletes the verification SID once it’s:
expired (10 minutes)
approved
when the max attempts to check a code have been reached
If any of these occur, verification checks will return a 404 not found error like this:
Unable to create record: The requested resource /Services/VAXXXXXXXXXXXXX/VerificationCheck was not found
If you’d like to double check what happened with a given verification - please use the logs found in the Twilio Console under your Verification Service:
I've found that if you submit a form twice by clicking a submit button twice quickly, that the verification is successfully checked and then because it was a success deleted, then the second check fails with a 404 like this and that is the error result you see. To avoid this, you should stop users from being able to submit the form twice by disabling the submit button after the first attempt.
I can confirm that philnash 2nd statement is correct. However wouldn't it have been handled way better if instead we just get a response from client.verify.services(serviceSSID).verificationChecks that the 2nd (and so on checks) failed??
How to resend verification code while verifying/updating email/phone attribute in aws-amplify/ aws-cognito, I'm using this code, to verify email/phone:
const responce = await Auth.verifyCurrentUserAttributeSubmit("email", confirmationCode)
Is there a possibility to resend the code?
I am sure you already tried this but would calling this method again, asking for a new code, not work for you:
https://aws-amplify.github.io/amplify-js/api/classes/authclass.html#verifyuserattribute
I have figured out that to use OneLogin Protect with saml assertions, you need to call the SAML verify factor without the OTP provided, and read about a similar question here, but if I simply put this in a loop with a sleep, the User is bombarded with OTP calls, until they hit "Accept". If the user takes 10-20 seconds to pull their phone out, and I sleep for 20 seconds, that means that users who have their phone immediatly available and could response in 2-3 seconds, have to wait 20 seconds to cover the slower calls.
To adress this, I would like to check the saml assertion verify without sending a push notification, and just the state_token.
I have also noticed that if I were not to use SAML assertions, I could do this as described here: https://developers.onelogin.com/api-docs/1/multi-factor-authentication/overview but that requires me to give either Manage users or Manage All permissions to the API keys. As this is a Python cli utility to handle aws saml auth, and one way or another, we need to distribute those API keys to users, this seems like excessive privileges for a user to log into AWS.
Does anyone know how can I check the status of an OTP for OneLogin Protect with SAMl assertions, without creating a new OTP call every time I check the status?
Example code
ol_client = OneLoginClient(
'client_id',
'client_secret',
'us',
)
saml_resp = ol_client.get_saml_assertion(
'ol_username',
'ol_password',
'aws_app_id',
'subdomain'
)
call_result =ol_client.get_saml_assertion_verifying(
'onelogin_aws_app_id',
device.id,
saml_resp.mfa.state_token
)
if call_result is None:
verify_result = None
while verify_result is None:
sleep(1)
verify_result =ol_client.get_saml_assertion_verifying(
'aws_app_id',
device.id,
saml_resp.mfa.state_token
)
I've found an answer by now. Just forgot to update:
The API exposes a Message field in the verifyFactor endpoint. While it's pending for the user to act on it, it will contain the string pending.
rMfa, err = c.VerifyFactor(token, &pMfa)
for strings.Contains(rMfa.Message, "pending") && timeout > 0 {
time.Sleep(time.Duration(MFAInterval) * time.Second)
rMfa, err = c.VerifyFactor(token, &pMfa)
if err != nil {
s.Stop()
return nil, err
}
timeout -= MFAInterval
}
I resorted to check every second until the timeout expired. The full implementation can be seen here: https://github.com/allcloud-io/clisso/blob/master/onelogin/get.go#L133
I have a page where the user can type in a new email address and then this method attempts to add it to their account:
Meteor.methods({
add_new_email: function(address)
{
Accounts.addEmail(Meteor.userId(), address);
}
});
I'm using the accounts-password package in Meteor.
I'd like to give the user meaningful feedback after they try to add the new address, in particular if it failed why did it fail? I have looked at the docs but there doesn't seem to be any method to find out failure reason.
I know that I can count the user's email addresses before and after trying to add the new one, but that doesn't tell me if the address already belongs to another user, or if it's an existing address of the user's, or whatever is the failure reason.
Is there any way to find out the result of an API call like this?
You can read the information about what this method does here:
https://github.com/meteor/meteor/blob/master/packages/accounts-password/password_server.js#L847
As you can see, the method will fail only in one case:
The operation will fail if there is a different user with an email
only differing in case
Therefore if the method fails you can tell to the user that the email is already registered.
After experimenting some more, it seems that all I need to do is add a callback to my client when I call the method, and check there for an error. Any error is automatically returned to the callback.
Server:
Meteor.methods({
add_new_email: function(address)
{
Accounts.addEmail(Meteor.userId(), address);
}
});
Client:
Meteor.call('add_new_email', 'me#example.com', function(error){
if (error) console.log("got an error " + error.reason);
});
I had not realised that the error from the API would be passed up into my method. Meteor - it's always more clever than I expect!
Note also that you can use Meteor.Error in your methods to throw errors which will be passed up to client callbacks in exactly the same way, see the docs:
if (!Meteor.userId()) {
throw new Meteor.Error("not-authorized", "You must be signed in to write a new post");
}
I know I'm a bit late to the party but I ran into this problem today and found your post.
I needed to be able to tell on the server side whether it failed or not so what I did was put it in a try-catch like so:
let addSucceeded = false;
try{
Accounts.addEmail(user._id, newEmailAddress);
addSucceeded = true;
} catch(err) {}
console.log(addSucceeded);
Only if the Accounts.addEmail does not fail will addSucceeded be set to true. To make sure I don't run into the "fail because it replaced the same user's email address in a different case" scenario, I always toLowerCase() the email address when saving.
I have written an adapter with a few simple procedures. In some circumstances I need to signal the caller that something went wrong. I have tried a few approaches ..
Throwing an exception: the text of the exception gets back to the caller via the onFailure callback (great), but comes wrapped in the module name and line number of the exception. TMI.
Returning an object where isSuccessful = false: this works like a charm and it's delivered to the caller via the onFailure callback.
For example:
return {
isSuccessful: false,
errors: ["No servers available"]
};
This article from IBM however explicitly warns against doing just this, though doesn't describe an alternative - can you?
Have you looked at this blog post?
https://www.ibm.com/developerworks/community/blogs/worklight/entry/handling_backend_responses_in_adapters?lang=en
The blog post details:
For invokeProcedure (client to adapter):
What does an invocation response look like?
When will isSuccessful be true?
When will isSuccessful be false?
For invokeHttp (adapter to server):
What does a backend invocation response look like?
When will isSuccessful be true?
When will isSuccessful be false?
Based on the conditions you will provide in the response to the client, you can then return errors in more clarity.