WhatsApp just announced a new web application see here.
For some reason, the interface requires the phone to be connected all the time. Is it for performance reasons (not to create additional load on their current servers)? Is there any other constraint that cause that?
The official explanation:
Your session on WhatsApp Web is an extension of WhatsApp on your
phone. WhatsApp Web connects to your phone to sync messages, thus you
can see all messages on both devices. Thus, the first requirement to
being able to use WhatsApp Web is an active WhatsApp account on your
smartphone.
Source: https://www.whatsapp.com/faq/en/web/28080002
As you may know your Whatsapp history is only being stored in a database on the phone itself. To see that history in your web browser, it needs to get it from the phone. Whatsapp could have redesigned it, so that everything is stored in the cloud (as many competing messaging apps do). But that seems to be against their philosophy. They keep it tighly coupled to a (one) phone. As you may know you cannot install Whatsapp on multiple phones using the same account. The web interface is just a remote for Whatsapp running on your phone.
And even though I don't know for sure, I think it's more secure too. It wouldn't surprise me if the data that's sent between the web app and the phone is encrypted in a way that even Whatsapp themselves cannot decrypt. Maybe the QR code is generated client-side (in the browser) and by scanning it using the app there is no need to exchange the keys through Whatsapp's servers. That way they don't ever get the encryption keys and will not be able to inspect the data that gets routed through their servers.
Note: Of course Whatsapp could at any time change their implementation of both the app or the web app and enable eavesdropping.
Related
I am working on MS Teams development. I installed the MS Teams toolkit in VS Code, set up my subscription with Azure and sideloading is active in my tenant.
When I run the app, it tries to install ngrok. This step fails as my organization does not allow running ngrok or other words tunnelling from our company laptop. We can run this on a VM to go around this but VM is not always available.
I am looking for a resolution for below scenarios:
Is there a way to debug MS Teams application without ngrok?
If we need a https URL, is it possible to configure a web app to facilitate that?
I tried removing install ngrok step from: /.vscode/tasks.json, but there are subsequent steps it the file dependent on that
I've done quite a bit of research on this question myself as I'd been getting a lot of pushback from our IT department regarding the security threats that come with using a tunneling service like ngrok. It eventually led me to this video posted on the MS forums from a Microsoft engineer who explains it clearly.
What it comes down to is that the Teams client (browser/desktop) approaches webservices (configured in the manifest file) differently depending on the type of interaction. If you're testing configurable tabs, task modules or configuration pages, then you can easily route the app to those sites running on your localhost through the manifest. The Teams client will approach them directly. Problems start to arise when you want to debug what happens when you use a bot or message extension, outgoing webhook or MS Graph change notifications (just quoting the video here, there might be other scenarios).
Basically, what happens is that the Teams client goes through a Microsoft-hosted service first, called Microsoft Teams Services, which will then approach your bot framework cloud service (typically an Azure Bot resource). This then forwards any incoming messages to whatever endpoint you have configured. What happens in these separate stages isn't completely clear to me, but what I do know is that whatever is typed by the user in the Teams client is translated to a JSON structure that can be interpreted by your server-side bot code (for C# apps, this is typically your CloudAdapter-derived class working with your TeamsBot-derived class). These messages are then routed to the relevant TeamsBot class method based on properties in the JSON.
Now the issue that ngrok solves is that, when the Teams client goes onto the public internet to reach the MS Teams Services server and then the Azure Bot resource, it then needs a public address to route the traffic to. It doesn't know about your local network anymore. As ngrok sets up a TCP tunnel between their server and your local PC, it is able to route traffic coming to their server to your PC. The Azure Bot now has a public address to send the messages to.
To my knowledge, there is no way to circumvent this as long as Teams client inner workings always make it go outside of your local network. For chat scenarios, the Bot Framework Emulator might offer a solution for unit testing. As far as I can see it performs the translation of chat input to the JSON message model of the Bot Framework and routes it to a local address for your chatbot to process it. Unfortunately, this doesn't work for chat message extension type messages.
As for the question whether ngrok can be avoided, I think the answer is definitely yes but you would need an alternative. There's several alternatives around that you might be able to host yourself if you have the technical know-how. Depending on your IT department, being in control of the public-internet-facing server might be a more viable solution for them. Another option is to host ngrok on a VM or cloud machine with less access to your internal network's resources than your PC/laptop has and test the code there.
TL;DR: If the the feature you're testing is approached directly by the Teams client, you can enter localhost in the manifest and debug it. If you're testing a feature that the teams client approaches through Microsoft Teams Services and the Bot Framework, you need to find a way to expose your code to the public internet. You can use ngrok or host your own alternative depending on requirements.
use mkcert to generate a certificate for ex. localhost.test
add losthost.test to your host file
use https://localhost.test for debugging
I am working on adding support for our cloud storage solution to MS Teams but there is no central server you can send http messages to and get meaningful relies back from. I have no experience with creating Teams apps so I was hoping someone with Teams apps experience could tell me if this is even possible. At this point I only need my app to work on Windows and OS X.
This is how I would like my Teams App to work:
Each member of the team already has our cloud storage app running locally on their machine which provides access to the files.
Within MS Teams the user adds a file reference to a message via a message extension that would result in a link unfurl creating a card that contains an 'Open' button. The URL in the card would be one generated by our locally running cloud storage app. Other members of the team could then open this file by clicking the 'Open' button. The action of the open button would be to send the URL to our cloud storage app that would then open the local copy of the file on that team members machine.
Is it possible to do something like this within a Teams app? The communication between the Teams app and our cloud storage app would be done over our own protocol.
If it weren't for the fact that all bot communication must be done over https rather than http the local cloud storage app could act as the server.
All the communication in Teams with 3P apps needs to happen over https public endpoint. You could use ngrok to tunnel to local.
We want to use a technical user in a mobile application (iOS). This user needs to access MS Graph API.
I currently find no method to acquire a token from mobile without any UI interaction.
Is there any way we can achieve this is a clean way?
In the case of devices and operating systems (e.i. IoT) that do not provide a web browser, you can use the device code flow, which lets the user use another device (computer or mobile phone) to sign-in interactively. Here's more info on using device code flow with msal.
Using a mobile device, which is a public client, has many ways of acquiring a token (including silently, assuming a token is already in the cache), most of which involve a UI. Public clients are run on devices or desktop machines and are not trusted to safely keep application secrets. Here's more information on public client applications for msal .NET, which supports Xamarin iOS.
We are planning a Slack app but we need local storage, we do not want to store any data of user/channel at our server, we want to save it permanently or temporary on local machine of user or in Slack server.
Is there anyway to do it?
Thanks
Here are my thoughts on the topic:
Local storage solution
You would need to implement a "local" helper-app that every user needs to install. Keep in mind that Slack works on many different platforms. So you would either need to limit your app to certain platforms (e.g browser only), or develop a "helper-app" for all platforms that Slack is currently supporting (e.g. Browser, Windows desktop, Apple desktop, iPhone, Android).
You would still need to host your Slack app on a server. Slack requires you to provide a fixed URL to connect to your Slack app, e.g. to invoke a slash command or after pressing a button. Your app would then need to manage the connection with the local helper-app to access the local data storage.
So, I guess it would be technically possible, but would require a lot of effort. And since you will need to host your app on a server anyways, it might be more feasible to also put your user data there.
Storing data on the Slack server
It is possible to store user data on the slack server through the user profile. There one can add custom key/value pairs through users.profile.get and users.profile.set
However, this will not work for slack team related data, like the individual Slack token that is received during the app installation process and needed by the Slack app to use those API methods. So your app needs to at least store the app token centrally together with the slack app itself.
I have to set up push cloud notification server. I decided to use: http://pypi.python.org/pypi/pyapns/
The question that i have is how to test the server if i don't have an app which will be connected to the server? Is there any sample apps or services that would display the push notification? I just want to send payload using some sort of script and see if sending is successful or not. How people debug such things? Aren't there any kind of virtual env for such tasks?
I do have certificates and ID's of the app, but not the app it self, since the other people are making it. I do not use MAC, or have iOS device. I did read docs from apple.
So eventually i got the right .pem certificate and token of phone with the app-under-dev, phone had to registered as testing one for that app. I just pushed messages and waited for answer unit i got it. Apple do not provide any "easy to use" testing grounds, logs or messages for debugging. Best you can do is to separate pushing service and getting token as much as possible and when you got your hands on app do the raw testing.