How to Sign out of getstream.io feed client - getstream-io

I need to know how to sign out of get-stream feed client. or change the token.
here is my configuration
Client.config = .init(apiKey: "key",appId: "aped",token: str)

Use the latest version of the Stream Feeds SDK v.2.2.0 or higher.
// Setup a shared Stream Client.
Client.config = .init(apiKey: "<#ApiKey#>", appId: "<#AppId#>")
// Setup a Stream user, when your user was logged in.
Client.shared.setupUser(token: token) { _ in
// Do all your requests from here. Reload feeds and etc.
}
You can find more examples on wiki pages here:
https://github.com/GetStream/stream-swift/wiki

Related

Is there anyway to get the "watermark" value in the bot builder?

I have a webchat for a user connected to the bot through directline.
I want a second user to join to the same conversation, but I want the second user to be able to read the full conversation.
Right now when the second user connects to the conversation it doesn't see anything of the first user conversation because he doesn't join with a watermark value.
I have this code on bot builder v4 right now:
const options = {
method: 'GET',
uri: 'https://myuri/addRow?conversationId='+stepContext.context.activity.conversation.id,
};
await req-promise(options);
I would like to send something like this:
const options = {
method: 'GET',
uri: 'https://myuri/addRow?conversationId='+stepContext.context.activity.conversation.id+'watermark='+watermark,
};
await req-promise(options);
Is there anyway to get that watermark value?
Thanks
Per this GitHub issue.
The cache of messages in the Direct Line connector service is intended to be used as a connection reliability mechanism, not as an actual message history store.
If you require more granular control over conversation history, you will need implement an a transcript store server side. And, you can use the SendConversationHistoryAsync api to send chunks of history messages to the conversation.
We do not currently have a complete example demonstrating this, but it is in the works.
I would recommend using a transcript logger to store and manage your own conversation history instead of trying to pull the messages from the cache. Also, if you try to use the watermark, you'll run into permission issues since one conversation doesn't have the ability to see another conversation's data.
Hope this helps!

Node.js Azure sdk - getting the Virtual Machine state

I've started to look into the azure sdk for node.js (link below) and interestingly enough I've hit a wall in what I'd image would be one of the most common tasks one would want to achieve using Azure's REST endpoints which is checking the status of a virtual machine.
I can easily get a list of all machine, or one in particular but the response from this services don't include the current status of the VM (running,stopped etc.)
There's absolutely no info out there regarding this particular scenario in the docos or the web other than a blog post (https://github.com/Azure/azure-xplat-cli/issues/2565) which is actually in regards of a different library.
Please not that I'm using the azure-arm-compute library which is part of the Node.js azure sdk.
Any help would be very much appreciated
github repo: https://github.com/Azure/azure-sdk-for-node
To get Virtual Machine statuses, please use function get(resourceGroupName, vmName, optionsopt, optionalCallbackopt), and pass the vaule {expand: 'instanceView'} as the options parameter.
var msRestAzure = require('ms-rest-azure');
var computeManagementClient = require('azure-arm-compute');
// Interactive Login
// It provides a url and code that needs to be copied and pasted in a browser and authenticated over there. If successful,
// the user will get a DeviceTokenCredentials object.
msRestAzure.interactiveLogin(function(err, credentials) {
var client = new computeManagementClient(credentials, 'ed0caab7***');
client.virtualMachines.get('<resourceGroupName>', '<vmName>', {expand: 'instanceView'}, function(err, result, request, response) {
if (err) console.log(err);
console.log(result.instanceView);
});
});

Getting customized message from GCM using Web push notifications

I'm using Web push notifications with Chrome, and they work great. But now I want to deliver a custom message in my notifications. I can have my Service Worker call out to my site to get content, as is done at https://simple-push-demo.appspot.com/—which is fine if I want every recipient to see the same message.
Is there any way to get either the recipient’s registration_id or the message_id that GCM returns? If I could get either of these and include them in the callback to the service, I could customize the response.
Also, any info on when we might be able to include a payload in the call to GCM?
The registration_id and message_id fields aren't exposed, but if the user is previously authenticated to your app, any fetch() to the server from your Service Worker will include credentials (and session information) which you can use to identify them.
If that doesn't work for your case, you can store user/session information in IndexedDB.
Payloads are coming soon—likely Chrome 50 or 51—based on the Web Push protocol. It's a bit of extra overhead and work to configure the (required) encryption.
It's possible, but I wouldn't do it since it's specific to GCM, while other browsers use other services.
You can either create a unique ID for each user (like we're doing in Mercurius) and store it in IndexedDB, or you can use the entire endpoint URL as an ID.
Here's the snippet to get the registration_id:
self.registration.pushManager.getSubscription()
.then(function(subscription) {
if (subscription) {
var endpoint = subscription.endpoint;
var endpointParts = endpoint.split('/');
var gcmRegistrationID = endpointParts[endpointParts.length - 1];
console.log(gcmRegistrationID);
}
});
P.S.: It returns a promise, so make sure your service worker waits for the promise to be resolved.

Can A Mobile Application use TrueVault to store JSON data without a "middleman" server?

I have been reading the documentation at https://docs.truevault.com/ but I am a little confused. I read this on the true vault site:
If you plan on using any of the server-side libraries, please ensure
any hosting environment you use is HIPAA compliant.
I took this to mean that TrueValut could support a standalone (client side only) mobile application architecture. Where the TrueVault API was the only server side interaction.
However my understanding of the documentation is that:
An API_KEY is required to register a new user.
Any API_KEY provides full access to all data vaults and JSON documents stored in TrueVault.
If both of these assumptions are correct that would mean it would be impossible to register new users directly from the client side app, forcing me to use a costly and resource intensive HIPPA compliment web server. The only way to get around this would be top hard code the API_KEY into the app, an obvious no go if that API_KEY can access all of my TrueVault data.
For my use case I have the following requirements for TrueVault for me to be able to consider using it (I would imagine these requirements are the same for anyone looking to develop a client side only healthcare application):
A user can sign up via the API directly from my client side app without requiring any sensitive keys or root auth data.
A user can authenticate using only the data they provided to sign up (username/email/password). My app is multi platform I cant ask them to remember their API keys to log in.
A user can Read/Write/Update/Delete data linked to their profile. They can not access any data from another user using their credentials.
Is TrueVault able to deliver these three basic requirements?
If the answer to this is "No" I would recommend you update this text on your website as there are not going to me any viable HIPPA compliment applications that can be supported by TrueVault without an independent server side interface.
I'm currently using AWS Lambda as a solution. Lambda is HIPPA compliant, more info here. Lambda is also a low cost solution.
Here is an example of the code I'm running on Lambda using Node.js.
var request = require('request-promise');
var _ = require('lodash');
function encodeBase64(str) {
return (new Buffer(str)).toString('base64');
}
var baseUrl = 'https://api.truevault.com/v1/';
var headers = {
'Content-Type': 'application/x-www-form-urlencoded;charset=utf-8'
};
var req = request.defaults({
baseUrl: baseUrl,
headers: _.extend({
Authorization: 'Basic ' + encodeBase64('your api key:')
}, headers),
transform: function(body) {
return JSON.parse(body);
}
});
exports.handler = function(event, context) {
req.post('users', {
form: {
username: event.email,
password: event.password,
attributes: encodeBase64(JSON.stringify({
name: event.name
}))
}
}).then(function() {
context.succeed({user: user});
}).catch(context.fail);
}
In general, you are correct - if you include zero server-side processing between user and TrueVault, then the API keys will be public. At least, I don't know of any way to avoid this.
That being said, it is incorrect to jump to "any API_KEY provides full access to all data vaults and JSON documents stored in TrueVault." - that's not the case if setup properly.
TrueVault API keys are able to be narrowed in scope quite a lot. Limiting a key to only Write permission on {Vault#1}, a second key to only Read permission on {Vault#2}, a third key to allow uploading Blogs in {Vault#1&#3}, quite a few variations, a forth for deleting information from {Vault#2}, and on as needed. You can also limit permissions specifically to content "owned" by the API key (e.g. user-specific keys) Full documentation here.
There are also limited scope keys (set expiry time, usage count, limit to any of the prior permission scopes). Docs here.
TrueVault also offers user logins separate from API keys which may be better suited if your user are using login credentials. Docs here.
I'm still rather figuring out TrueVault myself (at time of writing at least) so be sure to research and review more for your needs. I'm still torn if the limited scoping is "good enough" for my needs - I'm leaning towards using AWS Lambda (or similar) to be a HIPAA compliant middle man, if only to better hide my access token generation and hide that my data is going to TrueVault and add some "serverless-server-side" data validation of sorts.

How to find (and delete) message-less Twilio media?

If a Twilio message has been deleted, is there a way to locate any media associated with it (i.e. orphaned media)? Twilio docs explicitly state that deleting a message doesn't delete the media associated with it; if the message is gone but the media wasn't deleted first, is the media just publicly available forever?
If it's relevant, I'm using the nodejs package provided by Twilio (http://twilio.github.io/twilio-node/). Overall, I'm writing an app that deletes all messages and media by looping through all messages, and then all media, using the API. If there's a better way to do that (which thus makes my question moot), please let me know.
I can't find the reference now, but I believe I read somewhere that if a message is deleted, there is no longer a reference to the media instance and you're out of luck. I'm not sure if that's true.
At any rate, if I understand your question, I've had some success in the past using the Media portion of the API to list the media resources for a given message, and loop-delete the media instances first. Twilio's example of getting that list:
var accountSid = 'ACda6f132a3c49700934481addd5ce1659';
var authToken = "{{ auth_token }}";
var client = require('twilio')(accountSid, authToken);
client.messages('MM800f449d0399ed014aae2bcc0cc2f2ec').media.list(function(err, data) {
data.medias.forEach(function(media) {
console.log(media.ContentType);
});
});
You could then go back and loop-delete messages and not risk orphaning media instances.

Resources