Connect to Password Protected Zoom Calls with Twilio Voice - node.js

Earlier I used to connect to Zoom calls as follows:
this.twilioClient.calls.create({
record: true,
recordingStatusCallback: process.env.POST_RECORDING_WEBHOOK,
url: process.env.TWILIO_HELLO_TWIML,
recordingStatusCallbackEvent: ['initiated', 'ringing', 'answered', 'completed'],
from: process.env.TWILIO_PHONE_NUMBER,
statusCallback: process.env.TWILIO_STATUS_WEBHOOK,
statusCallbackMethod: 'POST',
to: phoneNumber,
sendDigits: 'www' + <call_sid>+ #ww#',
});
However, now, if a call also has a meeting password as well, for example:
Meeting ID: 9_digit_number
Password: Some_alphanumeric_string
How should I modify my function for that?

Twilio developer evangelist here.
According to the Zoom documentation:
If the meeting requires a password, a phone-specific numeric password will be generated. You can find this password in the invitation listed below the dial-in numbers and meeting ID.
So you can use your code, you just need to find the phone-specific password.

Related

Docusign. Not able to sign a doc with createRecipientView method url

I'm trying to create an envelope. My flow is next:
Obtaining OAuth token
Creating envelope based on existing template
Using createRecipientView method to get redirect url for the first signer(Later I'm taking the existing envelope id and creating redirect url for the second signer)
The problem:
It works as I expect if only signer's email address belongs to my docusign developer account. In other words if it is in the list of my docusign dev account users. Otherwise, with any random email address, I'm being redirected to the document page but I'm only able to view it and close, there's no start->sign->finish button(I'm not able to sign a doc).
One thing I've noticed is the wrong recipientId which is equal to zeros and dashes(normally it has a set of numbers and letters). I find it at a signing page -> other actions -> Session Information. It's hapenning when I'm being redirected as a user with any email(one that does not belong to docusign account). BUT, every signer receives an email notification with the same link to the document and If I go from that link, I can sign a document no matter what email address it is.
Session information with the wrong recipientId
My code:
const client = new docusign.ApiClient()
client.setBasePath('https://demo.docusign.net/restapi')
client.setOAuthBasePath('account-d.docusign.com')
const tokenResponse = await client.requestJWTUserToken(userId, integrationKey, ['impersonation', 'signature'], privateKey, 600)
client.addDefaultHeader('Authorization', `Bearer ` + tokenResponse.body.access_token)
const envelopesApi = await new docusign.EnvelopesApi(client)
const envelope = await envelopesApi.createEnvelope(accountId, {
envelopeDefinition: {
templateId: templateId,
status: 'sent',
emailSubject: `Signing template ID: ${templateId}`,
templateRoles: [
{ roleName: args.firstRole, name: args.firstSignerName, email: args.firstSignerEmail },
{ roleName: args.secondRole, name: args.secondSignerName, email: args.secondSignerEmail },
],
}
})
const recipientView = await envelopesApi.createRecipientView(accountId, envelope.envelopeId, {
recipientViewRequest: {
returnUrl: my local host,
email: args.firstSignerEmail,
userName: args.firstSignerName,
authenticationMethod: 'none',
},
})
return recipientView
Please, let me know If you know what I'm doing wrong.
I read docusign docs and thought I'm missing some permission, but so far can't figure out what's the problem
I could be wrong but based on your description, you haven't set up a clientUserId parameter for your recipients. Recipient Views are created for embedded signers wherein you embed the signing session into your own application. As embedded recipients are a special class of recipients associated only with the sender's account, this could explain why your recipient view works for users already part of your account but does not work for anyone else.

How can I specify which Google Wallet pass is for a specific user?

I'm currently working on building some loyalty cards via Google wallet api.
Creating and distributing passes is not a problem, but I'm not so sure on how to specify one card to one user.
I understand you are able to set the MultipleDevicesAndHoldersAllowedStatus property to one user. I also understand that you are supposed to set a unique userId which can be the user's email_address, but this does not necessary mean that only this user with this email_address is able to get the pass.
How can I make sure that a user with user1#mail.com is only able to install a specific pass?
I created a sample pass object with my personal email address as the userId; however, I was able to use the save link created by
const claims = {
iss: credentials.client_email,
aud: "google",
origins: ["www.example.com"],
typ: "savetowallet",
payload: {
loyaltyObjects: [
{
id: objectId,
},
],
},
};
const token = jwt.sign(claims, credentials.private_key, {
algorithm: "RS256",
});
const saveUrl = `https://pay.google.com/gp/v/save/${token}`;
to save it to a device that was not logged in w/ my personal email.
Is there a way for the pass (or maybe the save url?) to check again for the proper gmail address before letting the user download the pass to their wallet?
(I had to use android-pay since i don't have enough reputation to tag it with google-wallet-api)

How to create a user and send an invitation in node.js api

In an app where users aren't signed up by themselves but are instead created (name, email input) by existing users and sent an invitation email with link to password reset. Do I create a user and generate a random placeholder password like this:
const newUser = {
name: input.name,
email: input.email,
password: generateAndHashRandomPassword()
}
await User.create(newUser)
await sendEmail(newUser.email)
Or is there a best practice / standard / simpler other method to achieve this functionality?
The password reset also changed the isActive property on user model to true from default before password change being false

Send Shipping Address details with Stripe Custom Checkout

I have a stripe checkout that's using the now unsupported "data-shipping-address="true"" parameter. This works as expected when using the simple stripe checkout with the following code:
<script
src="https://checkout.stripe.com/checkout.js"
class="stripe-button"
data-key="<?php echo $stripe['publishable_key']; ?>"
data-amount="1000"
data-currency="gbp"
data-allow-remember-me="true"
data-shipping-address="true"
data-billing-address="true"
data-label="Proceed to payment details"
data-image=""
data-description="TrillShirts">
</script>
but if I call it in a .js file I can't get it to post the data taken from the Shipping Details. Here's the code I have:
var handler = StripeCheckout.configure({
key: 'pk_test_JfqHIgPSCG2oWOsJ54PWS0Nl',
image: 'https://stripe.com/img/documentation/checkout/marketplace.png',
locale: 'auto',
billingAddress: 'true',
shippingAddress: 'true',
token: function(token) {
console.log(token.id);
console.log(token.email);
// here I try to find the shippingAddress using cosole.log
console.log(token.shippingAddressLine1);
console.log(token.stripeShippingAddressLine1);
// When I eventually have the shipping address, I will insert it in the same way as below
$(".stripeToken").val(token.id);
$(".stripeEmail").val(token.email);
$(".stripe").submit();
}
});
document.getElementById('pay').addEventListener('click', function(e) {
// Open Checkout with further options:
handler.open({
name: 'TrillShirts',
description: 'Childcatcher Tee',
currency: 'gbp',
amount: 2000
});
});
});
Both of the following return undefined in the console, so I can't figure out the format that the Shipping Details come back in.
console.log(token.shippingAddressLine1);
console.log(token.stripeShippingAddressLine1);
Once I know the format and have a successful console log I can use jQuery to insert the data into the form before submit.
Can anyone help?
With Custom Checkout, when shippingAddress is enabled, the shipping details are passed to your token callback function as second argument of the function. This is the args parameter shown in the token callback reference in this doc.
So in your case you would need to modify the signature of your token callback function from function(token) {...} to function(token, args) {...} and then you should be able to get the info from args.
Here is an example: https://jsfiddle.net/rghpes57/3/
in this example the second console.log is the one you want to look at to see how the object looks like.

OAuth2 Login Which Token gives User Details such as email, username

after a successfull login microsoft provides these token object
which token contains the user details and how to get it
{ token_type: 'Bearer',
scope: 'https://outlook.office.com/Calendars.Read',
expires_in: 3600,
ext_expires_in: 0,
access_token: 'EwAYA+l3BAAUWm1xSeJRIJK6txKjBez4GzapzqMAAYFVBgaTrs3ZosM0HnTxd3nZSpyA9h212p05Es5F4O/qr0XX7jhQ3jfJf0Ww
Ffl54ct01Np+4u+ldfxSPswK+6J6PamfZffkWDO72BRyd054NG5lM7cY8qQvuzSn3a9TUD1fw6P+jEO6B4pa7AgS9RfSAtTIXKyo98+r/Hog+uhjntHSc
X8waNI9MLaBpT36YerwbHnaQirB7zPvL9Fi0ghf0dPtbDfypYNO3STiP9rho8iwx3DwKRN0bgpq/7RV5+6NURqRCnAUJ7QOK7PUuDjx06EF+/BuagmNZw
tCgfcEKWb5ckfLI6BRw/adNKSy0olWNX7rWFUQ0Hiq7gVcpakDZgAACLL1KiAs58qo6AGeGvuV7Ur6tNDXPlpQlkqthOFYsdRvv+F2ycohaM86eYh++Xj
gdB4rQM/eI7/BFsVZ+bBJFY9BaIdPhkZC8VJNgmkXRtOqYI8PE35x1bcDSRXOfv9wO0PPmUn3eq3ptze9WnMaLR2oq0JLxl9/N9CUU2Vlvc8SX4mU7wZ5
8QDtXHNOElBtkVl98gvd4dmsUSQLmfKErAEanpPdWFKu4i1LFiMUG2rA5yaP3UuTjOxnjynSk7ltGblsTG85YQFR4yCBJYIIFe5PRyFJv1ey4dZvFuVmS
VqBTw9W9I78la5n+fKyAZAWvZJB54gJrSfgtnS/j2nMoRvvwtozVjoKVhF1J4ye/6MUVareo1jp+4G+MxBpltzgxGsDIoajcS/yUD2QxVNKY0pLYdaTIP
FBALCeXCOEqET8ulb36YdSjFWH4eIxsY0u1TjRN+mIezOpxywqz13FmqT9gZctM1Am87O+5RSuU/M5VEzeVkyGgIC9P9JRiTCT2o7hcWSb5lv+Hvs5ojF
1mgZIIDwqmBxBFwyiB/QFaJIaFTwSk7aKolUy5Jp4C7yeib60CYtKMddyWTpw+cFeZHZhkWVFqV5GR3RVVHXMjfATSUdmbdO9qnJsIPqCPF1MJrII5ZId
EEGPi1xyye0pqjSJ6RoC',
refresh_token: 'MCYeZJGPBGuzpTTCZtD5rd*!ka96mfkBTiNfQOS1h41TA8PZ2*81snoU!FBIja8jW5bDRSngAyRiquz1SOLqJDSJz1SikdLA9gj
0knhfgMblCgcHq4uTCOavwMLFBKR1mCOYOQcRoVrul6rHl1IKVFD61dGXRWqqvvieS4fMN*8EfLzDJW6i09wjDFacV!q*qdU0IEG61yUk9RcrYQUx11CI
dLTWGhuo476TuzA!5IJIHLPY661r0Y8*KgIR0!ugRqtmZari5jqbBt252lABJKYtOxQrYHA23dz5ukIOpAu4oJMkIgu2xMAxpZSUS6rylNAnKYV42RWAs
g!7Rzo2LVye1Kj6Pqa*7rz9urHpIa8zTeLRE8gWs!q2x2j1MtMNOMGdBWG8KN!AVl6P2T9Nq69rBvIC3dFtHqqmCJbxgkIVq1w153RNWv3V9QLT4H2U6J
w$$',
id_token: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjFMVE16YWtpaGlSbGFfOHoyQkVKVlhlV01xbyJ9.eyJ2ZXIiOiIyLjAiLCJ
pc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vOTE4ODA0MGQtNmM2Ny00YzViLWIxMTItMzZhMzA0YjY2ZGFkL3YyLjAiLCJzdWIi
OiJBQUFBQUFBQUFBQUFBQUFBQUFBQUFQMXEtSzhiVXRjaGhJdzE1aTdjU2VVIiwiYXVkIjoiOWUwN2U3N2ItMzdlYi00MGQ0LTg3NTctNTYzMTY3OTU0M
Dg0IiwiZXhwIjoxNDg3NjYyOTQ5LCJpYXQiOjE0ODc1NzYyNDksInRpZCI6IjkxODgwNDBkLTZjNjctNGM1Yi1iMTEyLTM2YTMwNGI2NmRhZCJ9.d6ApS
kc0v74n4gTyy4v8Vo1aMokKnMuAaFpy71jHawvTNbFMeU_Fq0jtbjKYuzujIZV9jIGBjSlADcgIg2mQHhqvKWAPzoEUbxhnin4GN0XM9_XMCjQG6yBkhB
tJ8nk6mmqhfr-OvHGoFXOgLeFbkf0i8TJYuMmtnzUeDQQnOtihFQCJvy4agh2aiKG5IZaOR87I2DQ1is-6m3hFexKLLKwxDMjRmIHAaAm8uXrxGLGABJm
EJCybmF2jorhzmZ_qbmBVJXSy1DESgYf5CW9owwKnJA2taQQ3Hd472qHQ0Xay9XXSJMn94HwiK07DWQXIjP3F0nhND1o2R_61Rgju6g',
expires_at: 2017-02-20T08:42:30.061Z }
decoding id_token
it gives
{ ver: '2.0',
iss: 'https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0',
sub: 'AAAAAAAAAAAAAAAAAAAAAP1q-K8bUtchhIw15i7cSeU',
aud: '9e07e77b-37eb-40d4-8757-563167954084',
exp: 1487664645,
iat: 1487577945,
tid: '9188040d-6c67-4c5b-b112-36a304b66dad' }
but it doesn't provide user details
or i have take some id and and call microsoft api's to get data
The Id Token is the only token that will give you information about the user.
It contains at least the user unique ID: the sub claim.
The ID Token may contain additional information such as its addresses, phones, emails and so on but it depends on the Identity Provider policy.
In general and as per the OpenID Connect specification section 5.4, information can be retrieve using the following scopes.
profile: gives the username, gender, birthdate...
email: the emails
address: the addresses
phone: phone numbers
I do not know the Microsoft policy regarding these scopes. It is possible that, even if they are included in you authorization request, the additional information is not set in the ID Token

Resources