I am trying to build a bot for MS Teams in order to use the Graph API do to things like removing participants from a conversation.
I followed this Microsoft sample bot but got stuck on the deployment stage which requires Azure's cloud service. Is there a better way for deploying the bot and maybe a way for debugging it? In similar samples, the instructions are vague and confusing.
This is a very broad question, so the best I can do is give you direction, rather than specific answers. In that case, the following should be helpful:
In terms of samples, the one you've linked is very specific, and might be confusing to understand - I would suggest starting with more generic "bot" samples to get a better understanding. It's worth noting that bots for Teams use the standard Microsoft "Bot Framework", so not -all- samples are applicable for Teams, but have a look here: https://github.com/microsoft/BotBuilder-Samples/tree/main/samples
It looks from your profile that you code in python, so note that the link above includes Python samples too.
With regards runtime, bots for Teams do need to be registered with the central Microsoft Bot Framework service, which is indeed linked to Azure. However, it's not at all required to host your bot in Azure - the bot is basically just a web REST endpoint, listening for messages - it can be hosted on any web-address (httpS) endpoint. In that case, you would look in Azure for a "Bot Channels Registration", which is just the registration part, without hosting. A "Web Bot" in Azure, for example, is a combination of the registration as well as a hosting model in Azure.
As I said, it's a broad question, but hopefully the above gives some useful starting points.
Related
Sorry for a fuzzy newbie question but I didn't find a similar yet - maybe I'm just asking wrong..
I'm working on an open source Python application which reads and processes emails from given mailboxes using IMAP and SMTP (from various (self hosted) email providers, so a MS/Google specific implementation is not an option for me).
Currently I'm extending that application to support OAuth2 after Microsoft announced they will no longer support standard IMAP/SMTP authorization.
I found lot's of HowTos, tutorials and examples and managed to read/write mails using OAuth2 with GMail-servers now but I hope I just missed the recommended scenario for open source applications.
Currently I've set up a Google "Project" using tutorials I found in order to get ClientID and ClientSecret. Google told me it would cost me $15k to $75k to get my application verified, while Microsoft wants me to create an Azure/Identity Platform account and want's my telephone and credit card number in advance in order to bill me after 12 months.
Question: What am I supposed to provide with my application regarding OAuth2? I don't want to publish my ClientID/Secret do I? Does every user have to go through those registration procedures in order to access its mails using a command line script?
How to other open source mail-applications solve this issue? At least Thunderbird can authenticate with GMail (see https://www.supertechcrew.com/thunderbird-oauth2-gmail/) do they provide ClientID and -secret with the application?
Here is an old thread discussing the issue: https://groups.google.com/g/tb-planning/c/RRSPwp36bi0?pli=1
Disclaimer 2: I know this question sounds very obvious but I really didn't find a hint yet :)
SharePoint Online can be accessed either using SharePoint's own native REST API, or, using Microsoft Graph API. I have briefly explored both of the APIs and see differences in terms of the capability, for example, SharePoint API has function type method calls (GetByTitle()), whereas the Graph API seems to support identity based access, or, 'site path'. My opinion is that SharePoint makes it easy to access resources through the use of 'function' in URL, however, i am not sure if it is RESTful. It would be helpful to have your views on this aspect.
Given the two options (SharePoint & Graph) which is the recommended way forward, considering below criteria's:
Future proof - in terms of enhancement, support from Microsoft
Performance
Functionality coverage - considering current version of Graph API
Also, I couldn't find any Microsoft recommendations on this, if there is one kindly share the link.
Thanks.
I recommend Microsoft Graph API. I know it is a proxy to actual Sharepoint, OneNote, Planner, and etc API, but the way they are improving graph api day by day makes me think it is going to last for a good time. Let's say if you are writing an app that wants to connect with many Microsoft apps endpoints, having one class that handles all the graph api requests is enough instead of looking for specific apps endpoints.
Performance: I have been using Microsoft graph api for most of SharePoint related work and it works good and fast. I use Graph explorer to check out the graph if it actually works before implementing it in the app.
Functionality Coverage: Obviously graph is a proxy of a real api so it won't cover all the processes you need to do in SharePoint. For example, I had to create a Sharepoint Group which I could not find a way via graph api. But I assume as more people vote on those requests, the graph api is bringing those new possible proxy endpoints too. But again if your app is only working with Sharepoint then I believe I would stick to SharePoint API. In favor of Graph API, they also have something called delta query and subscription notification to see changes in the files and documents.
I was under the impression that the Graph API was meant to centralize things, make one endpoint to connect to all Sharepoint services via API. With that in mind, I wonder if we shouldn't be asking which is the better option but rather we should be asking when the so-called native option will be end of lifed. Graph is more future proof in the sense that this is the direction MS is taking. I can't speak to performance personally. As far as functionality, I can't imagine that Graph is functionally worse than previous iterations of SP. It might be functionally different. But it should expand API functionality.
https://developer.microsoft.com/en-us/office/blogs/end-of-support-for-basic-authentication-access-to-exchange-online-apis-for-office-365-customers/
Our organization is finding this announcement somewhat problematic! We use an IMAP library extensively to read various service based email accounts in o365. Any guidance on how to address this would be greatly appreciated.
Note, we have many console apps written in .NET (4.8) that run on a server based fired by many scheduled tasks. I understand we'd need to somehow register our "application" (I'm assuming that can be a generic one for our company), but we cannot involve any "user" interaction. These are utility apps. Glancing at the existing sample code for OAuth, they all seem to involve popping up a browser window to get someone to interact with "asking permission" which is exactly what we need to avoid.
We've used IMAP all this time to simply read and parse service based email accounts. I'm not sure I understand why IMAP over a secure connection is "less secure" than a more complex solution. Why take the option away?
On the other hand, the Microsoft Graph API looks significantly more complicated and appears to be OAuth based which, again, seems to involve quite a bit of authentication complexity.
Most REST APIs we've interacted w/ in other .NET console apps use a simple set of API "keys." Why not offer that at least?
As I say, we're looking for a way to write some process that run programmatically to automate a number of operations related to certain mailboxes. IMAP has worked like a charm so far, so we're looking for direct guidance on what to migrate to.
We understand your concerns. While a secure IMAP connection protects the data that's being transported, Basic Authentication exposes your Exchange Online accounts to attack techniques like phishing or brute forcing.
The primary objective of this change is to protect our customers from these threats. In addition, Modern Auth enables admin visibility into app access and enables fine-grained control of these apps.
To answer your question on implementation guidance, there is an existing approach in Graph to achieve exactly what you're looking to do. It's called "OAuth 2.0 client credentials flow". You can read more at https://learn.microsoft.com/en-us/graph/auth-v2-service
(Disclosure - I'm a Senior PM at Microsoft)
Let me make this clear from the beginning: I'm a complete noob regarding oauth2 and not a dev (just monkey interested in tech stuff) so the question might be silly. If so please don't hesitate to smash the monkey as he truly deserved it...
Since I wanted to get a better understanding of how oauth2 is working I wanted to setup slack within emacs. This is not my first project with oauth2. I managed to get offlineimap working with gmail using oauth2. However, google did one step automatically with which I'm struggeling right now for slack.
My question is all about the redirect url. Google did setup this for me pointing to my localhost. Now slack doesn't do the job for me and since my localhost isn't reachable form the outside (of my home network) I need to setup a way to securely get to my localhost.
How does google set this up?
I came across ngork which looks to me like a solution to my problem. Again, I've never heard / used it before. I think I would be able to get that stuff up and running but I would like to know:
Is this a safe and secure solution? To what should I pay attention?
"Is this a safe and secure solution?" is a very broad question and you can surely find a lot of discussion and opinions on this forum on how safe VPN tunnels for HTTP are in general and ngrok is in particular.
So the answer is: it depends on what your requirements are. Any other answer will be opinionated or will have to make assumptions about your requirements, which you have not specified.
Having said that:
If you want to use it for local development (incl. Oauth) ngrok
appears to be safe enough to be recommend by the Slack team for
local development (see tutorial).
If you want to use it for a production environment and/or in a
company network I would recommend to verify with the responsible IT
security officer before using it. However, it is a professional and
well-known product used by many companies, so you should have a fair
chance that it gets approved.
I have not used Google Oauth, but in my experience with other Oauth services its pretty standard that its calling you via a redirect URL.
I am new to QuickBooks and all my searching has been leading to conflicting answers. I really need to know this to move forward.
We have an on-premise application (legacy MFC app if that matters). Some of our customers use QuickBooks Online and we can send information up to it. In the past we have used QBXML which I believe is not supported for online anymore.
Everything I read at intuit.com talks about web applications. I think I have to have OAuth security and I do not see how intuit is supporting that from a non-browser based application.
I cannot believe that intuit would not have an answer for this situation so I must be confused.
So, can I send data to QuickBooks Online from a desktop application?
If yes, which API/SDK should I be using?
If I need OAuth how exactly do I implement this?
Does any of this require an independent security review?
I think I just need a little help getting pointed in the right direction.
Thanks
Unfortunately I think you have the most difficult scenario in the QB ecosystem.
I've used the DevDefined OAuth library with some success:
https://github.com/bittercoder/DevDefined.OAuth
You can get this to work on the desktop if you have a localhost server that the browser can redirect to on the OAuth callback.
Anything that talks to QBO needs to use the QBO API v3 now.
For a custom app that talks to QBO, you would need to set up your app # Intuit to run in development mode, so it wouldn't have to go through their security review, etc. But that limits the number of connections you can have (I think it's 10). So it might not work in your case. Also, if you're distributing your app to "normal" customers it may not be the best user experience, and probably isn't practical, to set it up so OAuth will work on the desktop.
You might just have to bite the bullet and create an intermediate web service on something like Azure or Heroku, then go through the whole process of getting Intuit to bless your app for production.