What is the correct method for setting a client to auto answer with the vLine API for WebRTC calls?
Looking at your comment, it looks like you have figured this out. But for completeness and for future reference I will go ahead and answer.
To auto answer a call, all you have to do is call MediaSession.start() when an incoming call comes in, instead of throwing a prompt to the user.
Here is an example snippet:
client.on('add:mediaSession', onAddMediaSession, self);
// Handle new media sessions
onAddMediaSession(event){
var mediaSession = event.target;
mediaSession.on('enterState:incoming', onIncoming, self);
},
// Handle new incoming calls and autoAccept
onIncoming(event){
var mediaSession = event.target;
// Auto Accept call instead of a prompt
mediaSession.start();
}
Note that you can do this in your code even if you are using the UI Widgets.
Related
i am new to JWT concepts while i am learning in this site
https://code.tutsplus.com/tutorials/jwt-authentication-in-angular--cms-32006
in the above link at this line :
var token = jwt.sign(user, JWT_Secret);
he has written the jwt.sign() with only two parameters but while i saw few other posts where they are sending 3 parameters
my doubt is that jwt.sign() is correct
2) how to create a secret_token
3) and how to send all the required parameters to send in the jwt.sign() method
please help me i hope you understood my problem ,friends please help me
If you read the JWT docs, the function can run in two modes: Synchronously (sync) and asynchronously (async). The function can automatically decide on which method to use depending on the number of parameters and type of parameters you provide the function, and the parameters you can supply are (in order):
The data/payload
Secret key/token
Options/configs (optional, can use callback here if you use default options)
Callback function (optional, will run in async mode if you provide this)
To illustrate this, read the code below:
// Synchronous
const syncToken = jwt.sign({payload: { x: 1, y: '2'}}, 'JWT_SECRET');
console.log(syncToken);
// Asynchronous
jwt.sign({payload: { x: 1, y: '2'}}, 'JWT_SECRET', (err, asyncToken) => {
if (err) throw err;
console.log(asyncToken);
});
As for the secret token, just make a hard coded one with no need to randomize, otherwise you wouldn't be able to consistently verify your tokens if at all possible. Or as an alternative, you can perform signing and verification asymmetrically by using algorithms such as RS256, or ES256 (using public and private key pair).
I hope this answer helps.
Reference:
https://github.com/auth0/node-jsonwebtoken
I'm trying to write an example app in wit.ai. I followed the quickstart app using node.js client that is shown at https://wit.ai/docs/quickstart.
The example shown there has only one custom action. But when I try to add a new story and a new action, I see that the context is being shared between the stories. This is causing wrong behaviour(a custom action from another story is being executed).
I cannot find any example with multiple custom actions and stories. Are there any node.js or python examples other than the ones from wit.ai websites?
You need to create a context for each session, and this is a quick example (from https://github.com/wit-ai/node-wit/blob/master/examples/messenger.js):
const findOrCreateSession = (fbid) => {
let sessionId;
// Let's see if we already have a session for the user fbid
Object.keys(sessions).forEach(k => {
if (sessions[k].fbid === fbid) {
// Yep, got it!
sessionId = k;
}
});
if (!sessionId) {
// No session found for user fbid, let's create a new one
sessionId = new Date().toISOString();
sessions[sessionId] = {
fbid: fbid,
context: { // New context per session id.
_fbid_: fbid
}
}; // set context, _fid_
}
return sessionId;
};
You can find a working example at https://github.com/hunkim/Wit-Facebook.
I suppose wit engine don't store context on their side.
You 'merge' function must merge entities in different ways, depending on your app logic.
But if you story is completed, you need to clear context for next stories.
I added a built-in function clear-context and call this function from wit as action.
Check out my example.
It's not an official api, but you can understand how wit http api works.
I have a single page app based on Aurelia and I'm trying to get it to work with an existing SignalR backend. I've downloaded the SignalR javascript client and integrated it with the Aurelia app manually (i.e. I'm not using a proxy file). I'm able to connect to the SignalR hub and see the arrvive messages in the console.... so far so good. Now, I'm trying to use the Aurelia Event Aggregator so that when a new hub message arrives an event is fired and any components of the app subscribed to that particular event will do some work. The issue is that the SignalR event callback doesn't seem to be able to access the Event Aggregator object. Here's the code to illustrate the issue:
//Import statements omitted for brevity
#inject (EventAggregator)
export class MyService{
constructor(eventAggregator) {
this.ea = eventAggregator;
this.connection = $.hubConnection("http://localhost:8080/signalr", { useDefaultPath: false });
this.hub = this.connection.createHubProxy("myHub");
//Register a callback function to fire when a new hub message arrives
this.hub.on("sendMessage", this.processHubMessage);
//No issues so far - all this constructor code works fine
}
processHubMessage(message) {
// This doesn't work - this.ea is undefined in the scope of this function
this.ea.publish('deviceStatusUpdate', message);
}
}
The event aggregator object referenced within the callback function is not defined - I assume because it's not being called within the scope of the class. Is there a way to resolve this? How do I give the callback function access to the class properties (this.ea in my example).
Try using
this.hub.on("sendMessage", (message) => this.processHubMessage(message));
It's failing on you due to how this isn't what you're expecting it to be. By using a fat arrow function, this is what you expect it to be. This is a really frustrating part of JavaScript, but fat arrows provide a simple workaround for it.
I think you are missing the 'start' for your Proxy, also you may need to alias your view model to pass to the HubProxy.
This works for me:
constructor(eventAggregator){
this.eventAggregator = eventAggregator;
var signalrAddress = 'https://pathToYouServer';
var hubName = 'yourHubsName';
var connection = $.hubConnection(signalrAddress);
var eventHubProxy = connection.createHubProxy(hubName);
var vm = this;
eventHubProxy.on('yourBroadcastMessage', function(data) {
vm.eventAggregator.publish(data);
});
connection.start();
}
I am wanting to use a CredentialPicker to prompt for a username and password. When I configure an instance of this class, I can set CredentialPickerOptions.PreviousCredential to a value previously obtained by CredentialPickerResults.Credential. I believe this causes the dialog to prepopulate the credentials.
However, persisting this value appears to be non-trivial; it's an IBuffer, whose members don't appear to contain the relevant credentials. Programming Windows 8 Apps with HTML, CSS, and JavaScript, page 657, implies that this should be possible:
An IBuffer containing the credential as an opaque byte array. This is what you can
save in your own persistent state if needs be and passed back to the picker at a later time; we’ll
see how shortly.
Unfortunately, the we'll see how shortly appears to only refer to the fact that the value can be passed back from memory into PreviousCredential; I didn't find any mention of how it's persisted.
Also, I want to persist the credentials using the recommended approach, which I believe is to use PasswordVault, however, this appears to only allow me to save the credentials as username and password strings rather than an IBuffer.
Thanks for taking the time to ask, and I certainly agree that I could've been more clear in that part of the book. Admittedly, I spent less time on Chapter 14 than I would have liked, but I'll try to remedy that in the next edition. Feedback like yours is extremely valuable in knowing where I need to make improvements, so I appreciate it.
Anyway, writing a buffer to a file is something that was mentioned back in Chapter 8 (and could've been mentioned again here...page 325, though it doesn't mention IBuffer explicitly). It's a straightforward job using the Windows.Storage.FileIO class as shown below (promise!).
First, a clarification. You have two ways to save the entered credentials. If you want to save the plain-text credentials, then absolutely use the Credential Locker. The benefit here is that those credentials can roam automatically with the user if that roaming passwords is enabled in PC Settings (it is by default). Otherwise, you can save the opaque CredentialPickerResults.credential property directly to a file. It's already encrypted and scrambled, so you don't need to use the credential locker in that case.
Now for saving/loading the credential property, which is an IBuffer. For this you use FileIO.writeBufferAsync to save and FileIO.readBufferAsync to reload.
I modified the Credential Picker sample, scenario 3 to demonstrate this. To save the credential property, I added this code at the end of the completed handler for pickAsync:
//results.credential will be null if the user cancels
if (results.credential != null) {
//Having retrieved a credential, write the opaque buffer to a file
var option = Windows.Storage.CreationCollisionOption.replaceExisting;
Windows.Storage.ApplicationData.current.localFolder.createFileAsync("credbuffer.dat", option).then(function (file) {
return Windows.Storage.FileIO.writeBufferAsync(file, results.credential);
}).done(function () {
//No results for this operation
console.log("credbuffer.dat written.");
}, function (e) {
console.log("Could not create credbuffer.dat file.");
});
}
Then I created a new function to load that credential, if possible. This is called on the Launch button click instead of launchCredPicker:
//In the page ready method:
document.getElementById("button1").addEventListener("click", readPrevCredentialAndLaunch, false);
//Added
function readPrevCredentialAndLaunch() {
Windows.Storage.ApplicationData.current.localFolder.getFileAsync("credbuffer.dat").then(function (file) {
return Windows.Storage.FileIO.readBufferAsync(file);
}).done(function (buffer) {
console.log("Read from credbuffer.dat");
launchCredPicker(buffer);
}, function (e) {
console.log("Could not reopen credbuffer.dat; launching default");
launchCredPicker(null);
});
}
//Modified to take a buffer
function launchCredPicker(prevCredBuffer) {
try {
var options = new Windows.Security.Credentials.UI.CredentialPickerOptions();
//Other options omitted
if (prevCredBuffer != null) {
options.previousCredential = prevCredBuffer;
}
//...
That's it. I put the modified JS sample on http://www.kraigbrockschmidt.com/src/CredentialPickerJS_modified.zip.
.Kraig
Author, Programming Windows 8 Apps in HTML, CSS, and JavaScript (free ebook)
When javascript is run in the browser there is no need to try and hide function code because it is downloaded and viewable in source.
When run on the server the situation changes. There are use cases such as api where you want to provide users with functions to call without allowing them to view the code that which is run.
On our specific case we want to execute user submitted javascript inside node. We are able to sandbox node.js api however we would like to add our own api to this sandbox without users being able to toString the function to view the code which is run.
Does anyone have a pattern or know of a way of preventing users from outputting a functions code?
Update:
Here is a full solution (i believe) based on the accepted answer below. Please note that although this is demonstrated using client side code. You would not use this client side as someone can see the contents of your hidden function by simply reading the downloaded code (although it may provide some basic slow down to inspect the code if you have used a minify).
This is meant for server side use where you want to allow users to run api code within a sandbox env but not allow them to view what the api's do. The sandbox in this code is only to demonstrate the point. It is not an actual sandbox implementation.
// function which hides another function by returning an anonymous
// function which calls the hidden function (ie. places the hidden
// function in a closure to enable access when the wraped function is passed to the sandbox)
function wrapFunc(funcToHide) {
var shownFunc = function() {
funcToHide();
};
return shownFunc;
}
// function whose contents you want to hide
function secretFunc() {
alert('hello');
}
// api object (will be passed to the sandbox to enable access to
// the hidden function)
var apiFunc = wrapFunc(secretFunc);
var api = {};
api.apiFunc = apiFunc;
// sandbox (not an actual sandbox implementation - just for demo)
(function(api) {
console.log(api);
alert(api.apiFunc.toString());
api.apiFunc();
})(api);
If you wrap a callback in a function, you can use another function in that scope which is actually hidden from the callback scope, thus:
function hideCall(funcToHide) {
var hiddenFunc = funcToHide;
var shownFunc = function() {
hiddenFunc();
};
return shownFunc;
}
Then run thusly
var shtumCallBack = hideCall(secretSquirrelFunc);
userCode.tryUnwindingThis(shtumCallBack);
The userCode scope will not be able to access secretSquirrelFunc except to call it, because the scope it would need is that of the hideCall function which is not available.