With the traditional OAuth API, I can specify the ?hd=<domain> parameter to limit logins to specific G Suite domains. I'm unable to find a way to do this with the googleyolo auto sign-in API.
Is this supported or am I just not able to use the API at this time?
I'm the product manager at Google for this library. This is a good feature request and we have it on the roadmap but no timeline yet. I'll update this answer when it's available, but we've got a ton of great feedback and requests from developers around this library so it might be some time to work through the backlog.
Related
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)
Can I use the REST API to filter out users who have not signed in during the last three months?
(I have admin access if that is needed).
Someone correct me if I'm wrong, but from what I know it's not available out of the box. You would probably need to implement a REST plugin module which would get this data from database (or find an existing plugin that does this - I haven't).
There's a page on Atlassian's Confluence that gives you SQLs to get the last login timestamp for a user (and it seems quite up-to-date): https://confluence.atlassian.com/display/JIRAKB/Retrieve+last+login+dates+for+users+from+the+database
Please note that you would have to think about security when developing such a plugin. I have not really considered this, but there might be reasons to include permission restrictions for such a REST resource.
EDIT: I might have found an API (not REST) that exposes login information without the need to query the database (untested): https://developer.atlassian.com/static/javadoc/jira/reference/com/atlassian/jira/bc/security/login/LoginInfo.html
Unfortunately, the JIRA REST API doesn't provide this resource. The latest supported methods can be found on the JIRA REST API Reference Page.
These methods can be tested on your current installation using the JIRA REST API Browser.
The links above contain all of the info you need on the REST API. If you're still interested in using REST, you can always create your own method for retrieving the user list.
Of course, you could use other methods, like SQL, for example. There are a number of plugins available here.
I wondered if anyone is aware of anyway that I may modify the communication settings of multiple Twitter accounts. Basically I have a number of accounts which all currently receive info at twitter emails etc and I'd like to manage these communication settings in an automated fashion but this doesn't seem to be possible.
I wondered if there is any way to do this in an automated fashion?
I'm using LinqToTwitter http://linqtotwitter.codeplex.com/ project to talk to the Twitter API in C#, although I don't necessarily have to use this.
I'm currently starting to think of using Selenium to do this.
Does anyone have any thoughts.
Many thanks,
Andy
There are some application settings you can manage through the API. In LINQ to Twitter they're mostly available by querying on the Application entity. However, there aren't any email preference setting options that the Twitter API offers.
My experience is that these settings options tend to change over time, mostly additive. So, whatever you come up with, you'll probably need to revisit your implementation occasionally to adapt to these changes.
I'm trying to create a redistributable web application that will integrate with Google Analytics through the Google Reporting API. Customer will install the application on their server.
I'm following this tutorial (I'm using PHP, but I believe this is not of importance for my question)
https://developers.google.com/analytics/resources/tutorials/hello-analytics-api
This works fine. No issues there.
However I can't figure out one missing element:
The tutorial starts with sending me to the Google APIs console where I have to create and configure a new API project and create and configure a client ID.
That's a lot of work that requires fairly technical knowledge (redirect url, selecting correct API, error-prone copy-and-pasting, etc.)
So my questions:
Is there an API so I can programmatically set this up for my user?
If that's not possible, is there a more user-friendly way to obtain Analytics reporting that is future-proof? (I noticed they are currently deprecating a few older APIs)
Unfortunately that's AFAIK not possible.
You could go one of the following ways:
Move client_id and client_secret to some configuration file and help your customer with deployment.
Show a one-time setup wizard for your app and guide your customer step-by-step. There you can at least provide him with the right callback URLs.
Regard your application as "installed application" and instrument curl or something similar for sending the requests.