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.
Related
I'm making a Slack app (basic webhook for our CI to send Slack updates) to replace one that broke/disappeared when a colleague who created the Slack app left the company. But I realized, won't the app I'm making need to be replaced again when I one day leave the company (since it seems Slack apps are tied to the creator's account)?
So is there a way that I can setup this Slack app independent of my account so that it wouldn't be deleted with my work Slack account?
The best practice to do so is by creating a Service Account.
(Service accounts are a special type of non-human privileged account used to execute applications and run automated services, virtual machine instances, and other processes.)
Use this 'Service Account' for creating new apps and add people working on these apps as 'Collaborators'.
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.
I've been following Microsoft's Teams C# tutorials found here, and have been successful for the most part. However, I cannot seem to get my app to work when I host the messaging endpoint myself rather than via their Azure service, which is not an option for me ultimately as the pricing is outrageous for what we need it to do.
I'm hosting the endpoint myself by publishing the sample project and ensuring it's externally available via HTTPS. I can access a custom tab within Teams, so I know that it's online, it's just the messaging endpoint that seems to fail with an "unable to reach app" error when I try and use the messaging extension via a chat window.
When debugging using dev tools, I get 502 error: Bot returned unsuccessful status code Forbidden, error code 1008. Every potential solution I've seen for similar issues hasn't worked for me thus far, though I still feel like it's something incredibly obvious. Are there special steps that need taking when hosting the endpoint yourself? The docs do a very lousy job of explaining the process, probably because Microsoft want you to pay to host the app on Azure.
This is usually caused by the app id / app key not being registered or used correctly in your app, so it's not authenticating to the bot framework service properly. Where/how you do that depends a bit on what sample code / project template you started with, but it's usually somewhere in a .config file (or previously in a .bot file).
The information that you need will be in:
App Id: The Bot Settings page in Azure
App Key: from the Bot settings page, where you got the AppId above, it links to the App registration itself - within there you'll find the section on keys, and you can create a new key (if you've lost the original one)
I know it's generally an error when AppID validation fails. The bot app requests Azure AD to verify the identity.Could your web server access to Azure AD? If you deny to access to outbound with firewall, you should allow Azure IP range.
Turns out it was purely a network issue, that as of yet we still haven't actually figured out. But we tried hosting the app elsewhere and it was fine. That's my recommendation if anyone else has the same problem!
I'm making a Slack App and just implemented OAuth to take advantage of Slack's Web API. I am using the single Access Token for my particular team that I am testing on.
Should I want to distribute this app on the Slack App Directory, will I have to store the Access Token for every single team? How should I go about securely storing these? Will the Heroku database suffice?
Yes, your app needs to store the access token for each Slack team that installs it. And your app will need to access those tokens in order to enable access to that team's Slack (e.g. post a message). Most people will use a local database (e.g. MySQL) on the server to store the access tokens of each team.
No idea how secure the Heroku database is. However, since Heroku is a commercial service I would assume it can provide sufficient security for your app.
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.