I am building a Teams application that will use Microsoft Graph to add and remove rows from a SharePoint list. I have taken a look at a number of examples provided in the Teams-Toolkit extension in VSCode including Graph Toolkit Contacts Exporter and Hello World Tab With Backend. The examples have left me confused about weather I can safely make Graph calls directly from the client side, since in both examples have done so?
Is it safe to make graph calls from the client side when using the TeamsSDK?
Does this expose a token in an unsafe browser?
Should I instead be making graph calls server side? e.g. using the on behalf of flow or is that only relevant if you are interfacing with API's where you have a single application level api key?
While it hasn't really been explicit, it certainly seems to me that the guidance has changed on this over time from Microsoft, and these days they're definitely steering people to making the calls server side instead, for exactly the reason you state - the token is quite privileged, and so should not be passed around to an unsafe browser.
To see more on this, here is a video from Microsoft: https://www.youtube.com/watch?v=kruUnaZgQaY, and the same content is available in written (blog) format here: https://devblogs.microsoft.com/microsoft365dev/lets-decode-single-sign-on-sso-in-microsoft-teams-tabs/ . Essentially, it refers to this blog post which essentially just says to do it all server side (get and immediately use the OBO). It means that you kind of need "double" code (you need to have code to make the call client side, which calls your own API, which then has calls to Graph), but it's safer and you're of course only doing this for specific things you need in Graph, not the -entire- Graph surface area.
Related
I'm currently studying computing and it tackles about API. I keep reading this term 'APIs provide an interface for communicating software' but i'm not really sure what is an interface to API? May i ask for your help to explain it?
Not sure if i get your question right, but let me have a try:
So basically a simple architecture of building for example an app is splitting it up in front- and backend. For example, in a ToDo-List app there is a server-side software which manages all data and we have a Mobile App which shows the data to the user. The backend is an "abstract" program. I mean with that that you can't click buttons or something else. So, when you want to create a task in your frontend app you have to tell the backend (for example written in Java or Python) that you want to make this. For this you can use an API.
This is basically an Call of an Website. The backend recognizes is and loads data out of an database, manages it and displays it for example in JSON Format. This format is send to the website.
Look here: https://jsonplaceholder.typicode.com/todos/1
The app now is able to automatically get this data and manages it.
Obviously real APIs are much more complex. For example you have to authenticate, you can hand over parameters and so on. You have POST, GET, DELETE Methods.
But this is simply the basic concept of an API.
Look here to know how to create an API (for example in Java): https://spring.io/guides/gs/rest-service/
Look here to know how for example an Mobile App consumes the API (in JavaScript): https://www.taniarascia.com/how-to-connect-to-an-api-with-javascript/
I hope i could help you :)
Best regards
Sebastian
One of my clients sent me a xAPI course which is created using Articulate Storyline 360 and published as Tin Can API for LMS. I am able to launch the course using method mentioned in below link:
Incorporating a Tin Can LRS into an LMS
So using the above method the launch URL looks like:
http://my.lms.com/TCActivityProvider/story.html
?endpoint=http://my.lms.com/lrs/endpoint/
&auth=Basic OjFjMGY4NTYxNzUwOGI4YWY0NjFkNzU5MWUxMzE1ZGQ1
&actor={"name": ["First Last"], "mbox": ["mailto:firstlast#mycompany.com"]}
&activity_id=61XkSYC1ht2_course_id
®istration=760e3480-ba55-4991-94b0-01820dbd23a2
Using the above URL which has an endpoint and credentials information, the course gets launched successfully and sents xAPI statements to LRS automatically.
But I don't want to send the parameters like auth, actor or endpoint in the URL for security reasons.
I googled for an alternative method and found the adlnet/xapi-launch and adlnet/xAPIWrapper library.
I explored the above two libraries but am confused about how it can be integrated into the LMS?
Does Articulate Storyline 360 support adlnet/xAPIWrapper?
The adlnet/xAPIWrapper is just a library that makes it easier to communicate with the LRS and requires you to determine how the endpoint and authentication credentials will be passed to the library. In other words it isn't necessarily intended to be used via LMS launch (it will work there, but doesn't have special handling for it). The xapi-launch specification you found as far as I know (at this time) has effectively zero adoption.
The other alternative would be to use cmi5 which is another specification that includes the concepts of packaging, import and launch for content that communicates via xAPI. It uses a different credential handshake process that is similar to both the launch guidelines you linked and the xapi-launch method. It uses query string parameters for the endpoint, but the LRS credentials are accessed via a separate, single use request. It has better adoption (though still early at this time), has been peer reviewed, is under the ADL umbrella, and is on more of a standards path. See https://xapi.com/cmi5/ for more about cmi5. I don't believe Articulate has yet implemented cmi5 in their products (at this time) as they are waiting for more indication for market desire, you should contact them about your interest in it if you feel it is a suitable option.
As stated. I am using ruby to perform my task. I am to create a webpage that takes in user input and makes calls using the API back and forth. However, I am yet to understand how to deal with these APIs...
When you consume the API you are essentially making use of the service. So you are sending data and are, potentially, getting something back.
When you write a rest client, you are essentially writing an entity which will consume the API. The rest client could also provide some functionality to ease the consumption of the API, for instance if your API requires a time stamp, the rest client could automatically provide the current time stamp, or else provide the user with a nice UI control to do so easily, rather than type something like this: 22-10-2002 12:10:11 GMT.
The client itself can take different forms. It could be a simple page on a web page, or a more complex desktop or mobile application.
I am trying to make a web app using ExpressJS and Coffeescript that pulls data from Amazon, LastFM, and Bing's web API's.
Users can request data such as the prices for a specific album from a specific band, upcoming concert times and locations for a band, etc... stuff like that.
My question is: should I make these API calls client-side using jQuery and getJSON or should they be server-side? I've done client-side requests; how would I even make an API call from the server side?
I just want to know what the best practice is, and also if someone could point me in the right direction for making server-side API requests, that would be very helpful.
Thanks!
There's are two key considerations for this question:
Do calls incur any data access? Are the results just going to be written to the screen?
How & where do you plan to handle errors? How do you handle throttling?
Item #2 is really important here because web services go down all of the time for a whole host of reasons. Your calls to Bing, Amazon & Last FM will fail probably 1% or 0.1% of the time (based on my experiences here).
To make requests users server-side JS you probably want to take a look at the Request package on NPM.
It's often good to abstract away your storage and dependent services to isolate changes and offer a consolidated and consistent web api for your application. But sometimes, if you have a good hypermedia web api (RESTful responses link to other resources), you could reference a resource link from another service in the response from your service (ex: SO request could reference gravatar image/resource of user). There's no one size fits all - it depends on whether you want to encapsulate the dependency or integrate with it.
It might be beneficial to make the web-api requests from your service exposed via expressjs as your own web-apis.
Making http web-api requests is easy from node. Here's another SO post covering that:
HTTP GET Request in Node.js Express
well, the way you describe it I think you may want to fetch data from amazon, lastfm and so on, process it with node, save it in your database and provide your own api.
you can use node's http.request() to fetch the data and build your own rest api with express.js
I am creating a web service which uses REST web services. The client side code is written in HTML/JavaScript. My dilemma is whether I
should use the REST resource directly using AJAX calls?
or
should I create Servlets/JSPs (where REST calls will be made and data will be sent to client(AJAX/JAVSCRIPT)).
I have seen many web apps which follow the 2nd procedure but seems to me that it's doing the same thing as 1st in an indirect way.
Is there any advantage of using 2nd procedure over first?
What is the standard way to use REST services by HTML/javaScript client?
Please let me know if I am even thinking in the right direction and if not please give your valuable insight.
You can use either approach but note that browsers will enforce the same-origin policy on scripts, so if the REST service lives on a different domain than the script you will need to use a servlet/script on the same domain as the script to proxy the call to the other domain. I suspect this is why you are seeing the second approach used.
A proxy/middle-man servlet may also be useful if not all of the response is needed; you could use the servlet to strip out information that is not needed by the JavaScript to reduce the amount of data sent to the browser.
Directly accessing the resource(s) via AJAX has the obvious benefit of less overhead and is IMHO the more elegant solution, however it is also important to note that not all browsers support PUT and DELETE requests natively.
To get around this, you'll likely want to support the common "_method" hack. This stackoverflow question mentions this approach.