Integrated Authentication

Loading...

En provenance du cours de Johns Hopkins University

Ruby on Rails Web Services and Integration with MongoDB

287 notes

Johns Hopkins University

Ruby on Rails Web Services and Integration with MongoDB

287 notes

Cours 3 sur 6 dans Specialization Ruby on Rails Web Development

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.

À partir de la leçon

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).

Integrated Authentication11:38

OAuth Integration7:43

Rencontrer les enseignants

Kiran Chittargi
Adjunct Professor, Graduate Computer Science
Whiting School of Engineering

[MUSIC]

Hello and welcome back.

In this lecture we will integrate sign-in and

authentication to our current example so far.

We'll also look at an OAUTH2 provider in Rails called Doorkeeper,

and we'll integrate Doorkeeper with our project.

We'll also do some database configuration, and

then of course we'll do all this hands on with the demo.

But before I do this, I want to show you the problem that we have today, which is,

if I go to the browser and try to edit the movie, it'll happily come up because

there is nothing blocking it, nothing that is checking the authentication.

So let me show you what I mean.

So if you look at the URL I have localhost3000/movie/12345/edit.

Now, I do have a movie by the name of 12345 ID, so

if I do that, the application happily takes me in and there it is,

I'm getting an editing movie, I can go and change the title of the movie and

hit the update movie, show back, I can do all kinds of things.

But the problem is I had logged out.

So, obviously, I logged out before doing this demo, so, yeah,

that's just a prerequisite.

You need to log out from the previous example if you're still logged in.

But, once I click on this and come in, it's taking me happily inside.

So, we need to stop this, and

that's what we'll integrate the authentication to begin with.

So what we'll do is we'll add these before actions, add these two,

to the page controller and

have all the HTML based controller extend the page controller, right?

So the following before actions will require authentication and

route the user to the login page for any non read only views.

So authenticate user, and then also user signed in question mark.

We check to see if the user is already signed in.

Okay, so I've made the changes to my page controller, and now let's go and

try in our browser and see what happens.

Now I'm going to go and try the exact same URL, I will put the movie ID and

try to edit the movie.

And last time it took us directly inside, right?

But notice how it is redirecting us to user/signin.

So again I had logged out, so basically when I tried to go to localhost3000/users,

edit one, two, three, four, five, it basically says authenticate user or

user signed question mark, remember that code?

So now it basically said hey, you're not logged in, authenticate yourself.

So let's go and log in ourself and see what happens.

So I'm going to login, and if I do login,

it should take me into the editing movie screen,

because we'd already signed up in the previous examples, right?

In the previous steps.

So there it is.

So now when you try to get to an edit, it'll stop you and make sure you sign in.

So we have the webpages blocked off by device.

Now let's go and do the same thing for API.

So I'm going to turn on before action, authenticate user, and

same thing with user signed in for the API based control.

So now let's go and try from our raised console and

we should hit the same problem, right?

We should be able to do a get, but we should not be able to do a post or

a put, so let's give that a try.

Okay, so let's go and look at our /API resources.

First I'm going to verify if access is still available to non-writable methods,

which is basically a get.

So I'll go and see if I can get movies, right?

So, 200 okay, which is good.

Let's just go and do the usual response.response, and

also will parse the response.

Parse the response, we get the movie, so everything looks good.

Now I can also get a specific resource, /movie/12345, and that also looks good.

So let's go and look at the response, 200 okay.

Let's also go and parse the response, that also looks good, right.

So get is not a problem, even though we've gone and

protected the API, but let's go and see what happens when I try to do a post.

So, here is localhost movies.

It's HTTP party post, 3000 API movies,

12346, and I'm trying to send in Rocky26.

So, even before it makes it to the database, we get you need to sign in or

sign up before continuing.

So, we do get a message right there.

So we can actually look at response, so

as you can see it's 401 not authorized or unauthorized.

So basically right now you can only do a read, but

you will not be able to post or make any kind of changes.

Now the other important thing to remember is we did get a 401 which is great, but

there was no redirect, there was no kind of forwarding that happened by default.

This is because the device has a configuration

of content type that will get redirected and the rest will get denied.

So at this point, we have device protecting both our HTML pages and

all API actions.

And one way to get around this is to supply our credentials to the web

services, which can be very tedious process, so this is where OAuth2, or

our OAuth framework would really be easy to get the request going in with tokens.

And that's exactly what we'll do next with Doorkeeper.

Okay, now that you've got device working and protecting our page,

let's look into Doorkeeper.

Now, Doorkeeper is an OAuth2 provider for Rails, and it's built on top of

Rails engine, that makes it nice and easy to integrate with a Rails application.

And also, you know, so far it supports all the protocol flows.

If you look up the OAuth2 specs, there is half a dozen different flows,

like authorization code flow, and there is implicit grant, refresh token,

access token, scope, and there's client credentials, and so on.

So you can look up the OAuth2 spec,

obviously it's beyond the scope of this course, but

Doorkeeper does a pretty good job at supporting all of these different flows.

So there's a couple of gems that you need to add to our gem file, three actually.

And once you add this gem, just stop the server.

Let's do a bundle one more time to get all these gems installed.

Well the next thing we need to do,

is we need to install Doorkeeper into the application by our Rails g command.

This will add a few lines to the application, and

also it adds a single line to the routes file, very important,

which produces the following URI in config/routes.rb use_doorkeeper.

The next important step for us is to do the database configuration.

We need to configure the ORM and prepare the database.

And in this case we are changing from active record to Mongoid,

hence this line is commented and we have the ORM set to Mongoid.

Also if you recall from some of the Mongoid discussion,

since we are using Mongoid, we just need to install the indexes.

There is no need for an active record migration here.

Next let's take a look at the Doorkeeper device integration,

very important piece of code.

So, let's jump through the editor to see where exactly this has to be done and what

is going on with these three lines of code here, or basically this block of code.

So this is our Doorkeeper.rv which is under config initializer, and

the block we are interested in is this, resource_owner_authenticator.

If you look at the comment on the top, it says this block will be called

to check whether the resource owner is authenticated or not, all right?

So this block of the code will get called when Doorkeeper

needs to locate the user associated with the current session, right.

Now, we know that device is being used to manage all the users, right.

Now, we also know that device keeps the user ID in a session

variable called warden_user.user.key, right here.

And we also know that user ID is within a nested array when there is a current user.

That's why we have this piece of code.

And we are using Mongoid, so we know that the ID,

the user_id's map to the user.id property in Mongoid, so that is also important.

Now there is also an or here, and that's primarily because

we know that Doorkeeper wants to issue an alternate command if there is no current

user, and it basically does a find and find by user ID.

And either of those find or find by would throw an exception in cases where

there is no current user, so we basically implement the search as aware.

So User.where ID, user ID.first, or

redirect to new user session url.

So basically, it's really this piece of code is checking to see whether

the resource owner is authenticator or not, meaning do we have a session, or

do we go and find the user?

So bottom line, this is how the Doorkeeper will get the current user

identity, the current user's identity from the device, or

whatever else you are using for your account management.

So that's basically how it's done.

Okay, so let's go and give this a try.

So I have restarted my server, and I have logged out.

And as you can see, when I go to my 3000 default page,

it's asking me to login or sign up, so that's good.

Now I want to go to this URL.

It's a local host :3000 OAuth/authorize/123.

Now this is the OAuth2 URI that requires an authenticated user session,

meaning for us to get inside, it has to be an authenticated user session.

So what happens when we go to this URI?

So notice how it's redirecting me back to the login page.

So really what happened was the URI kicked in the resource_owner_authenticator,

the one we just saw, that was configured in the previous example, and

this will take you back to the login page, because the redirect happened and

the user was not found, right?

So there was obviously a built in redirect that we had done

that brought you back to this page.

So let me go in and login.

So, that's my email and password.

Okay, I'm successfully logged in.

So now if I attempt to go back to the same URI, so

I get signed in successfully, authorization code is 123.

There it is, I was successfully able to authorize.

If I was already logged in, it'll automatically take me inside.

Okay, so just to summarize, we've got device and Doorkeeper all

integrated with our movie service, and now we move on to our final piece,

which is registering our application with OAuth and completing the whole demo.

So we'll move on next where we will take the movie editor application and

register this with our movie service.

Thank you.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2018 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play