In this course, we will explore MongoDB, a very popular NoSQL database and Web Services concepts and integrate them both with Ruby on Rails. MongoDB is a used to handle documents with a pre-defined schema which will give the developers an ability to store, process and use data using it’s rich API. The modules will go in-depth from installation to CRUD operations, aggregation, indexing, GridFS and various other topics where we continuously integrate MongoDB with RailsRuby. We will be covering the interface to MongoDB using the Mongo Ruby API and the Mongoid ORM framework (the MongoDB access counterpart to RDBMS/ActiveRecord within Rails). The last portion of the course will focus on Web Services with emphasis on REST, its architectural style and integration of Web Services with Rails. Core concepts of Web Services like request/response, filters, data representation (XML/JSON), web linking and best practices will covered in depth. This course is ideal for students and professionals who have some programming experience and a working knowledge of databases.
OAuth2
Loading...
Del curso dictado por Johns Hopkins University
Ruby on Rails Web Services and Integration with MongoDB
291 calificaciones
Johns Hopkins University
291 calificaciones
Curso 3 de 6 en SpecializationRuby on Rails Web Development
De la lección
Web Services
In this module, we’re going to explore Web Services with a focus on caching and security. We will start off by looking at REST fundamentals, RMM (Richardson Maturity Model) and URI best practices. We will wrap up the topic by covering Client and Server Caching along with Web Service Security (OAuth 2).
Conoce a los instructores
Kiran ChittargiAdjunct Professor, Graduate Computer Science
Whiting School of Engineering
[MUSIC]
Hello and welcome back to our final lesson, Security.
We'll kick off this lecture with what is OAuth 2.
Why do we use OAuth and we'll look at a data flow.
Basically, we have a little example and we'll walk through the example of
how the data actually flows before we jump into a working demo.
So what is OAuth 2?
Well OAuth itself stands for Open Authorization.
So it's an open standard protocol that provides simple and
secure authorization for different types of applications.
So basically the whole idea behind OAuth 2, and you will see this,
is to allow providers to give access to users without any exchange of credentials.
So, you don't have to,
when you go to a website, you don't have to create an account.
Because every time you go to a different website you'll have to create an account,
fill up a form, click on okay.
But, instead, if you have an account with, say, Facebook or GitHub or Twitter,
Instagram, LinkedIn, all these support OAuth, where when you go to this
main page, main web application, you don't have to create an account.
Instead, you will get a little login form for
any of these common applications and then you can login and get access.
So it's a really nice, easy,
quick way of using multiple applications with very minimal credentials exchange.
And we'll talk a little more about this.
So here is another good definition rather.
An authorization framework that enables applications to obtain limited
access to user accounts on an HTTP service say Facebook, GitHub, Twitter.
So the important thing is limited access.
You can control as a user how much access you want to give to this application
that is requesting information, right?
So what is the problem with password approach?
Well, the users have to share their credentials so what do I mean by that so
let's take an example of say so there is a website called say printingservice.com its
just a made up website.
Now, they have this feature where they can print pictures for a very inexpensive cost
and they have all this different different flavors, different sizes, and all that.
And they ship you the pictures for free.
You want to obviously take advantage of this.
Now, you want to print all of the pictures you have in a Facebook album, but
what are the options you have?
One, you can download all the pictures from Facebook to you local machine and
then upload all the pictures to this new website.
A lot of work.
And the second option would be, say the website will say this printing service
will say hey, why don't you give me the login and password to Facebook, and
I'll take care of it.
Which is okay, so you give the login and password, but
the problem is it's not secure.
You're giving of your login and password.
And, secondly, what if you go and change the password in Facebook couple days later
and you come back to the site a week from now.
And then this site will have a problem connecting to Facebook because you changed
the password and if you're doing this multiple sites, and you're trying
to use multiple applications like Facebook, and LinkedIn, and Instagram.
So you can see the problem with so many sites and so
many passwords, it becomes a big maintenance problem.
And not to forget the big security problem we have.
So this is a big problem, and this is how, the OAuth2 will help you solve this
problem because you will be connecting real time with one of these services.
And they will take care of getting the token and all of that we'll talk about,
but you will get away from the sharing of credentials problem.
So how do you solve the problem?
That's where OAuth comes into the picture.
So OAuth approach is to secure without any password.
So there's no exchange of log in or
passwords that you actually give away to any application, as such.
There is a concept of what we call tokens, and token is being used between
the application like the printing service in my example with Facebook are,
whichever service you decide to use.
And we'll talk a lot more about that in the upcoming example.
And again, bottom line,
it allows providers to give access to users without any exchange of credential.
So, you will be able to go to multiple sites without actually, and this is
something you can see and today, when you go to website, the multiple website.
When you go to glassdoor.com or
other websites where you're trying to find some information, and
then it'll ask you to either log in with the website's credentials, or you can use,
say, Facebook's credentials or LinkedIn or any other service.
So, that does save you from actually creating an account and
simply getting inside with one of those sites.
Okay, so that's the OAuth to an action with our little movie service example.
So, in our little demo we have three players,
we have a movie editor application, Mr. Ideas who is the user and a movie service.
So the Movie Service is the one we've been playing with.
It has a list of movies, and in reality will have a list of actors,
directors, producers, all kinds of information about a movie.
MovieEditor Application is this cool application where you can load a movie,
edit, and do all kinds of things on a movie.
And Mr. Ideas is a user who has an account with the movie service, and
has a whole bunch of movies in his profile and other settings.
And basically, he wants to log into the editor application, and
he wants the editor application to represent him and
fetch all the movies on his behalf from the movie service.
So when the user is on this editor application he has all his profile his
settings in all the movies that he needs so
he can take a movie and make some changes on the service.
It's an integrated editor application where all this information from here
is put there.
So, to get all this going, the first thing that the consumer,
the service consumer which is the movie editor application has to do, is to
register with the movie service provider, are the OAuth service in this case.
So, there's a registration URL that needs to be called
by the movie client or this consumer.
Now, this is a simple form where you go in and fill in some basic
information like the name of the movie and also the redirect URI.
Now, we'll talk about the redirect URI a little more later on in the demo, but
basically the redirect URI is where the service provider will send back
an authorization code.
Now the authorization code is basically an URL for
the movie editor application in this example.
So when you click on submit what happens is you get an app ID or client ID,
a secret which is a password, and the callback URL, that we talked about.
Okay, so now with the basic registration all done, so now Mr. Ideas will
log in to the MovieEditor application and say, hey, I want to work on my movie.
Can you go and please get all my movies?
So at this point, the MovieEditor Web Application will say,
okay, do you have an account with us?
Do you want to log in?
Or do you want to use Movie Service Login?
The integrated OAuth service basically here.
And this is, think of this as a button or a link.
So when you click on this, what happens is now the movie service will
send the app ID that we got, or the client ID that we got in the previous step.
And it will send the redirect URI and
also the scope, which is like in this example here.
I want to create a movie and could be other edit option, delete option.
Other things could potentially be here as well.
Now, at this pont, the movie service will ask the user, hey,
we have a request from this movie service application.
The movie editor application.
Would you like to authorize this request or deny the request?
Also as part of this pop up or this message box,
which I don't have the entire thing here, but basically to say do you want to
authorize application to create movies, delete movies, post movies.
It will give you the list of stuff, it's a Facebook or a linkden or any of
those it will say do you want to share pictures, or do you want to share tweets.
So, it will give you a profile of the combinations that the user had or
rather, the application has basically asked.
So, in this example, it's Create Movies, or Edit Movies, or Delete Movies.
SImilarly, it could be sharing pictures, or tweets, or any number of combinations.
Based on that, the user can take an action as to authorize or deny the request.
So, once the user says, yep, I authorize this request,
what happens is, the movie service will now send back a code.
Now very important, this code is temporary and it's one time use only, so
it has a very short life meaning you have to the editor application or
the consumer application will have to go back with the code.
And then get a token back.
And again it's a one time use only.
So what happens next is the editor application will take that code,
using the app ID, and
the secret ID will quick, will go back to the movie service application.
And then, in return, if everything checks out and if everything is valid,
the then movie service will basically come back and give an access token.
This is the token very important that'll replace your credentials, your login and
password.
So any kind of action that was authorized like editing a movie, deleting a movie,
updating a movie, all those actions from the MovieEditor Web Application will
have to be done by attaching or sending the access token in every single request.
Now here is the same example in a little more technical here compared to
the previous chart.
So as you can see, and this is pretty much our demo and
we will go through every single step here.
So here, step A that we talked about the prerequisite step where the admin would
actually registered the application with the app name and the callback URL.
And then the service, the OAuth service,
will come back with AppRegistration information like provider name URL,
call back URL, app id and secret which you kind of store this information.
So when the user comes in, step 1, hey, can I access the movies for me,
can you get the movies for me so that I want to make some edits?
And the movie editor application will say, sure,
I'll build a authorization URL I will do this in the example using an OAuth 2 gem.
And it'll build a URL and will redirect to the provider site like Facebook or
in our example the Movie Service.
And it'll also give them information like, hey, where is the call back?
How do you, once the authorization is done,
where does this application need to come back?
What is the scope?
Whether it's editing or create movies in this example response type.
And this information will be sent across.
And then the authorization and the log in will happen between the user and
the service, whether it shall get Facebook or Movie Service in this example.
Now once all that is done, and authorization is done, the movie service,
based on this information of redirect and call back and scope and all that.
It will go back to the movie editor application here saying,
oh I got all the authorization, you're good to go.
Here is the callback question mark
code equal to some number one two three in this little example.
Using that code step seven you will go and get a token and
that token is very important because any edits or any postings or whatever
operation that you want to support from this application directly to the service.
You will be doing that http call,
that web service call, and you'll be sending access token equal to.
That's the only way that a service will know actually what's going on,
based on this access token.
So there's no more login and password.
It's all driven by this access token.
So it's secure, and the transaction is all done using this token.
So in summary, OAuth 2.0 is an authorization framework that
enables applications to obtain limited access to user accounts.
An HTTP service has Facebook and LinkedIn and Instagram and all that.
It's basically the next evolution of the OAuth protocol.
It was first originally introduced in 2006.
So now that we know basics of OAuth and we also have a nice scenario set up,
we will actually jump into this example and look at some hands on code and run or
build this application block by block.
So that we will reach the end result of using OAuth 2 and
putting all these three different pieces together.
Thank you.
Explora nuestro catálogo
Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.
Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.
© 2019 Coursera Inc. Todos los derechos reservados.
