I have a Teams application (Tab). I am an ISV provider, and provide a multi-tenant application that is installed by customers via Teams App Store in their organizations.
How do I save settings for my application organization-wide for the customers? For example, CustomerA has installed the app and then CustomerB. I want some storage that would be unique for CustomerA and CustomerB and the app, and located in customer's environment. The settings I want to save are not per-user, but per-organization (tenant).
Somewhat similar to "App Data" folder you have in Windows Desktop for example.
Does such a storage exist? Does API for this storage exist?
A tab app is a simply a web application that you render inside of Teams. As a result, what the app does, and where and how it does it, is totally up to you. This includes any data storage you choose to have behind the scenes. For example, your tab could be built in PHP and use MySQL, or built in ASP.Net and use SQL Azure or CosmosDB. It's totally up to you, but you need to implement it yourself, as an ISV.
The important piece to differentiate clients, however, is being aware of the TenantId for each user, so you can look up which client's settings you need from the database. The most simple way to do this is simply the tid property on the Teams tab context. You can read more about that here. Unfortunately, because it's just accessed via Javascript, it's not entirely secure - for a more secure mechanism, you should be creating an Azure Application, and generating jwt tokens that you can authenticate against in your backend. It's a much more complex topic, but hopefully this answer at least gives the background you need. For more info on the security aspects (validating the token etc.), please see this question: How to restrict access to Azure Function to only allow requests from a custom Microsoft Teams App?.
Related
I am working with Google Firestore in native mode and CRUD'ing data within it using the "cloud.google.com/go/firestore" api in Go. Access to the data is wide open as long as you know the project id and using the Firestore API on a server. I don't want to try the rules until I figure out how to secure the data from server attacks that. Again, all the API requires is the project id to access the data so I need to lock that down firstly before I move any further. Rules are only for mobile/web clients from what I read and Server side clients completely bypass the rules. Please help. I do not want to use the Firebase API because attackers can still use the Firestore api to access the data.
It's unclear from the limited information in your question but, your Firestore database is not open to anyone with the Project ID.
The service is only accessible to any thing (human|machine) that has valid credentials. Either humans with e.g. Gmail accounts or Service Account key holders.
In either case, only identities that you've explicitly added to the project will be able to access its resources and then only those with the appropriate IAM roles|permissions.
Google provides an elegant facility called Application Default Credentials (ADCs) that simplifies authenticating clients.
I suspect that your code is using ADCs to authenticate you to the project|service.
Access to the data is wide open as long as you know the project id and using the Firestore API on a server.
If that is a concern, consider disallowing all access in the Firebase security rules for your Firestore database.
Also have a look at my answer here to understand why sharing your project ID is not a security concern, and in fact is necessary if you want to allow direct access from client-side devices: Is it safe to expose Firebase apiKey to the public?. If you don't want to allow direct client-side access, closing down the security rules (as they are by default, unless you choose test mode when creating the database) is the way to go.
I am integrating my SAAS application to Microsoft Teams. Right now integrated as Tab in teams. I am using my own API endpoint to authenticate and authorize the user. I have got some specific information about the user I am getting from API. How can I store it in Team context? Right now I used local storage in the web app. In Teams web app it seems working but I don't think it is working in Desktop app. Is there some API available in teams which helps to maintain the user state with Tabs? similar to userstate in Bots? Please help.
I would think local storage would be troublesome across devices anyway, perhaps consider server-side storage instead.
Google APIs can have usage limits, both on a per-user and a per-application basis. For example, the GMail API free tier is limited to a billion daily quota units across all users of your application.
This works for well-designed server-side applications, which can centrally ensure they obey these usage limits. However, I’m not sure how this is supposed to work for client-side apps. As Google’s documentation says,
Installed apps are distributed to individual devices, and it is assumed that these apps cannot keep secrets.
These apps are still supposed to use a client_secret and credentials, but these are assumed to not be confidential despite the name. However, just saying they aren’t secret doesn’t prevent abuse; a user of the app can take the credentials file and use it for a different purpose, perhaps one that uses the APIs more. What can an application developer do to prevent people doing this from burning through all the available quota?
Edit for clarification:
The use case that prompted this is a purely desktop app that doesn’t connect to any service except GMail (see https://github.com/mbrt/gmailctl/issues/48). If it weren’t for a global quota for all users of the app, there would be no reason to worry about individual users at all; they don’t connect to any service except GMail itself.
You could write a server app (a Cloud Function would work) which holds the secrets. Clients call your endpoint with some form of identifier and you return an Access Token. If your users have a browser, they can auth each time; if not you would need to request a Refresh Token which you store and use that to generate an AT.
I am working on a product for Windows 8 that needs to perform some low-level tasks, display some UI, and communicate with an external server. I definitely need a Windows service to accomplish the low-level tasks. At the same time, I would like to use the cool features of Windows App Store apps, like push notifications, live tiles etc... for the UI. In this design, both my service and my app would communicate with my external server.
The flow would be something like: my Windows service sends some information to my server, which then sends a push notification to my App Store app.
I understand that deployment is not pretty in this scenario, but let's put that aside for now. My problem: How does the server know that the service and the app are on the same machine, and consequently linked together? i.e. When my Windows service sends information to the server, how does the server know where to send the push notification? I need is some sort of shared, unique, identifying information.
I have seen lots of discussion (usually frustrated in nature) about the lack of inter-process communication between App Store apps and desktop apps. In my case, I have two options:
Generate the exact same unique identifier in the service and in the app. This seems unlikely because apps don't seem to be able to access very much system-specific information. I'd love to be shown that I am wrong about this.
Generate a unique identifier in the server OR in the app and communicate it to the other component. Potential ways to do this:
Create the identifier in the app, save it to a file, and then access the file from the service.
Some sort of local socket solution (I've read this doesn't work, but have not tried)
Of course, option 2 seems likely to violate the Windows 8 app Certification Requirements, notably:
Windows Store apps must not communicate with local desktop
applications or services via local mechanisms, including via files and
registry keys.
Any advice would be most appreciated.
I'm not a lawyer, but if it says "via local mechanisms" then you could still possibly communicate via a cloud service as long as having both apps installed isn't necessary to have some features in the app or if you don't mean to publish the app in the store.
You could save some sort of a token in the documents folder or if your desktop app can run with appropriate permissions - it could access the local data folder of the Windows Store app to synchronize the token for use in communication with the web service.
Perhaps the user could just be asked to copy and paste a token between the two apps?
We are looking at a standard way of configuring the various "endpoints" of our application. Our application is a distributed system with Windows Desktop applications, Windows Server "services" and databases.
We currently configure each piece using XML files. This is getting a little out of hands as we work with larger customers who can have dozens of Servers running our application and hundreds of desktop clients.
Can anyone recommend a Microsoft technology or a third party that would allow us to centralize all that configuration information and manage it in a one place for all our applications? Any changes would be "pushed" to the endpoint(s) that are interested.
For example, if we were to change the login for one of our database, we would make that change on the database, then reflect that change in our centralized system. Following that last step, any service that needs to connect to the database would be notified of the change (and potentially receive the new data). How and what each endpoint does with that information is outside the scope of the system.
Our primary business is not "Centralized Configuration Services". We are a GIS company that provides solutions for various utilities worldwide.
I've done a couple of things to give myself this functionality over the years. I build enterprise applicatons that may be distributed across many servers. I don't want to bury config settings in each services config file or each web server's web.config file. For application specific stuff I usually create an application settings table in the app's database. The table only has two fields. SettingName and SettingValue. I then write a web or wcf service whose sole function it is to retrieve these settings. I write a function called GetSetting where you pass "SettingName" and it returns SettingValue or an empty string if your setting is not found. This way I can store all application settings for all components of the application in one spot. Maintenance and troubleshooting for this is really easy, I'm not hunting through scads of config files spread across a dozen web and app servers.
For larger scale apps I might create a separate AppSettings database where I add a new field to my table mentioned above. ApplicationName. My web or wcf service for this approach has the same method call (GetSetting) only at this scope I pass ApplicationName and SettingName and it returns SettingValue or an empty string.
Doing either of these things allows you to centralize all app settings for any size application or IT shop. It has worked really well for us.
You could use RSS together with BitTorrent to distribute changes. See Wikipedia. It is not MS specific however, but should provide the flexibility you need - a configuration server holding the configuration and providing the feeds needed to configure the clients and possibly servers.
Any VCS through a secure channel?
For example, git through ssh (both available in cygwin).
I think the first step is to have the secure channel (if you want the push ability, pulling might be different).
As for managing the "versions" in different "branches", what's better than a version control system?
As it goes for the Microsoft requirement, well the Microsoft sofwares in that exists in that area would suck pretty bad in your case (as in not the best tool for the job).