API: ThingImages Resource and Authn Policy

Loading...

Del curso dictado por Johns Hopkins University

Capstone: Photo Tourist Web Application

17 calificaciones

Johns Hopkins University

Capstone: Photo Tourist Web Application

17 calificaciones

Curso 6 de 6 en SpecializationRuby on Rails Web Development

In this Capstone project for the Photo Tourist you will implement a Ruby on Rails web application that makes use of both a relational and NoSQL database for the backend and expose the data through services to the Internet using Web services and a responsive user interface operating in a browser from a desktop and mobile device. You will have a chance to revisit and apply what you have learned in our previous courses to build and deploy a fully functional web application to the cloud accessible to your co-workers, future employers, friends, and family. In developing the Photo Tourist web application, you will get to work with different data types and data access scenarios (e.g., fielded data display and update, image upload/download, text search, access controlled information) to provide your users the ability to show off their photos and information from trips they have taken and to seek out photos and information from trips taken by others. Using the application you develop, your users will be able to • Create an account • Upload and download photos to the site and make them accessible to others • Provide descriptions of trips and photos that others can read • Organize photos by location and trip, • Find photos based on location • Find photos based on text searches of descriptions • Locate the place where the photo was taken on a map

De la lección

Security and the Photo Tourist Domain Model

In this module, you will learn how to implement authenticated interfaces providing role-based authorization required to protect web resources. You will also practice these techniques while implementing the core resources for the Photo Tourist application. You will learn how to manage user accounts with the Devise Ruby gem and how to implement token-based authentication with the devise_token_auth Ruby gem and ng-token-auth AngularJS module. With this starting point -- the student is on a straightforward path to implementing external authentication (e.g., via Facebook, Twitter, Github) through OAuth2 (not part of the capstone). Additionally, how to implement end-to-end account registration from the UI, through the API, to Devise through the intermediate libraries and implement an authenticated session component in Angular and make that available through a Navbar based on a Bootstrap implementation. You will learn how to add role-based security to their resources with the aid of the Pundit Ruby gem to determine access not only on authentication -- but also on assigned roles for the anonymous and authenticated user. The content and code-along exercises provide opportunities to implement role-based access checks within the Web UI to help guide a user to making authorized choices appropriate for their assigned roles. And how to write optimized SQL queries to implement compound, custom resource payloads for efficient expression of related object information -- including mapping roles to resources accessed by specific users. ************* This is a very long module with very important material relative to security and the targeted application. It will likely be broken up into two (2) or more modules in the future. You should budget extra time for this and treat it as if it were two (2) modules for the amount of time spent. Yes -- that means the novice developer could spend upwards to forty-eight (48) hours going through the lectures, performing the optional code-alongs, and completing the mandatory assignment. *************. The mandatory assignment for this module will be posted shortly after the last lectures are posted and there is a Git commit available in Github for that lecture.

Server: Domain Model and Authn Policy4:16

Server: Image (Metadata) and Authn Policy15:19

Server: Things and Authn Policy5:32

DB: ThingImages Model15:00

DB: Custom SQL and Query Scopes8:28

API: ThingImages Resource and Authn Policy12:37

API: ThingImages Resource and Authn Specs7:59

Conoce a los instructores

Jim Stafford
Adjunct Professor, Graduate Computer Science
Computer Science, Whiting School of Engineering

[MUSIC]

In this lecture, as a part of implementing the ThingImage resource,

we will discuss Nested Resources and Nested Resource URIs.

Exposing the same controller action from multiple URI viewpoints.

What can we do when our parameters shift from the URI to the payload,

or from the payload to the URI.

We're going to leverage the query scopes put in place, and you'll see how those

custom compound responses are going to be very useful in the API.

And then of course, as we build our resource,

we're going to bake in the authentication policy.

Okay, to go further with ThingImage,

what we're going to do is use the resource scaffold generator.

And we're going to create a ThingImage controller with an index, create, update,

and destroy method.

And then this skip says, if anything already exists, skip it.

Don't ask me any questions.

And you'll notice that it skipped over the migration, the model class,

the model spec, and the factory.

And it went on to create the controller and the resource, and I'm not sure why but

it doesn't create the views, we'll have to do some of the stuff manually.

If we go into the routes file we notice that thing_images is at the root,

we want to remove it and move it into the API, except it's unique.

We're not going to refer to ThingImages globally,

we're going to refer to them scoped either below things or images,

and we'll start out referring to them under things.

All right, when we specify the resources below things,

what I'd like to do is only expose index, create, update, and destroy.

That's almost the same of what we've said here except we're not including show.

So I probably could have added except show, but I chose to do it this way.

And then, although it's through things that we're going to manage ThingImages,

like deleting them and editing them, it's going to be through images

that we're also going to be able to create them, and get them.

It'll make for a fairly consistent interface if we do it this way.

What ends up happening is the create method that gets mapped to a post,

that gets mapped to a create method in the thing_images controller

will also have that same method exposed under images.

So, we can link from things to images and images to things.

And we can get our links through our images and

we can get our links through our things.

However, depending on what perspective we come from,

we're going to want to see the information differently.

And then just to make sure that we've got some decent functionality in place,

I'm going to add this additional method, where we're going to get not only

what are we linked to, but we can also get what could we be linked to.

If you remember that one query scope of not linked,

this would be a URI that gets us to the result of that query scope.

So primary management of thing_images is under things,

selective methods of thing_images is below images.

And if we run rake routes and I've gotta scale it down a bit,

that if we're getting to thing_images through image, it's image_thing_image and

if we're getting through thing_images through things, it's things_thing_images.

As ugly as the shorthand naming is to say thing twice, it actually ends up being

more sane in the end because we have two ways of getting to it and

it's very clear when you see, we're coming from the image side of things or

we're coming from the thing side of things.

And these are helper methods that are only exposed inside of Rails and

probably the most that you'll ever see of them is in our specs.

But you'll notice that when we come into the thing_images,

when we come from the image side the image_id is in the URI.

And when we come from the thing side of the house, the thing_id is in the URI.

So if we're ever going to create a link through images,

then thing_id is in the payload and image_id is in the URI.

If we're ever going to create a thing_id from the thing side,

then thing ID is in the URI and image_id is in the payload.

If we go into the controller, I'm not quite sure why it didn't create the stubs

of those methods that I specified, but it's easy enough for us to create them.

So one of the things that we want to take care of is wrap_parameters.

If a thing image comes in the mail and it has an image_id, thing_id, or

priority, we want to copy that down under a thing_image element.

And while we're thinking of such things, let's go ahead and

create a thing_image_create_params helper method that's specific to create that will

require that we have a thing_image document and inside of it have

an image_id or thing_id depending on which URI you come in on.

So in the wash Rails hides whether we're getting image_id

from the body or the URI, and he just says in the params, here it is.

So if we can't find image_id at the root level,

which would mean it's in the URI, then require it to be in the payload.

Or if we can't find thing_id at the root level in the URI,

then require it in the payload.

And then, of course, permit priority image_id and

thing_id to come on in when we create our thing_image.

And then we want to have some before actions.

A get thing and a get thing image, and they would go as simple as that.

So we're going to assume with parameter key for the thing is going to be thing_id,

and the parameter key for the thing_image is going to be id.

So before the following actions, index, update, destroy, we're going to

be calling these methods and if they have trouble, they'll throw an exception and

the application controller can pick up on the recovery.

And then to finish out this private area, we have update parameters.

Notice I expanded the name.

Instead of calling it thing_image_params,

it's, well here are the parameters that are appropriate for a create, and

here are the parameters that are appropriate for an update.

Expressing image ID or thing ID is not appropriate for

an update, only changing the priority is appropriate.

And then of course where would we be without authenticated user.

We only require authentication from methods of create, update, and destroy.

Methods like index does not require authentication,

will allow anyone invoke the method, but as you'll see down the road

we'll actually add extra processing if they happen to be authenticated.

So there'll actually be two ways in which the method will act,

whether it's authenticated or not as we get further on in the module.

All right, so index is implemented through some query scopes, and

we just finished going through that, so that should look pretty straightforward.

Then we add image_things, coming from the image perspective, what things are linked

with this image and included with that data, please include the name as well.

And then to include some additional functionality,

what kinds of things are not yet linked to this image?

What things out there are not associated with this image?

And as I said earlier,

this is a URI that exposes the result of the not linked query scope.

So next, we'll define the create method.

It's got a bit to it.

The fact that we can have our parameters coming from two different URIs adds some

complexity here.

So bring in the create parameters, and if anything's missing,

it will throw in an exception and will be caught.

But in addition to that,

we need to throw in some URI properties, and we're taking care of that.

And then after we have done error checking that says have you expressed

the information we care about, we now need to worry about, is it valid information?

Like, what if you've expressed a thing_id that doesn't exist?

So what we would like to do is return an error message, a rendered bad request.

And express in it what your ID is and what we were looking for.

And we would like to do it in some kind of standard format.

So what I want to do is go ahead and

declare a helper method up in the application controller.

And you see where this record_not_found?

Well, let's break this thing down.

There's an aspect of this method about returning an error message.

Let's get rid of that.

And then, here is the aspect of it that it was a record not found.

So what we can do is factor out the payload formatting and

the returning of a status and

pass in the string that we want depicted as a full message and the HTTP status.

Okay, that looks kind of clean.

I was staring at that a while back I said, I'm going to need that.

And the next thing we need is to assign the creator ID, and

we'll get that from device.

And then we have the standard processing block that we commonly see

either coming from a scaffold or something that we would normally replace anyway.

So at this point, create thing_image, the link between a thing and

an image looks complete.

Now we add the update method.

It's kind of simple,

now that we have our own helper method that gives us update parameters.

And trusting that, we really don't need this extra slice,

because that's what whitelisting is doing for us.

So return no_content and thing_images.

And destroy looks pretty straight forward so far.

The controller looks like something that's not going to totally blow up on us when we

start writing our test.

Okay, so what we need to do now is create our views directory.

So app/views/thing_images.

And since I'm only going to return lists,

I really only need to create one view file.

I don't need to create a partial, so

this'll be a decent example of just an all-in-one.

So when I go to martial out my thing_images,

from the thing_image itself we're looking for the thing_image id,

the thing_id, the image_id, the priority, you know, all the standard stuff.

I went ahead and readded updated_at late in the game, and

then I want to add thing_name and image_caption.

But of course, these methods are going to blow up if the query hasn't populated

the result with those value.

So I can't ask if they're nil or anything like that, what I have to ask, hey,

does this thing_image respond to the method thing_name or

respond to the method image_caption?

If so, let's produce it.

In summary, we've built a nested resource, thing_images.

And we expose this resource via multiple URI viewpoints.

Below things and below images.

Things can have images, and images can have things.

And the ThingImages represent the properties of those relationships.

We took a look at how parameters could come from the URI or the payload.

URI properties are automatically required, and we're able to make our

payload parameters conditionally required, based upon the URI we recalled from.

Our API was built to work with custom compound objects.

We didn't separately go out and get ThingImages, images and things.

We used query scopes from the model tuned to the API's specific needs

in order to be able to get a compound response that very efficiently expressed

the relationship between a thing and an image.

For authentication policy we're going to require our users authenticate in order to

modify a thing_image.

You must log in if you're going to relate an image to a thing.

From an authentication perspective,

we are going to require that a user login in order to be able to create, update, and

delete relationships between a thing and an image.

But we will allow anonymous read access.

So users will be able to see the images for a thing that they have access to, or

the things for an image they have access to.

And there's no point in having a single instance of a thing_image,

we're always going to want to get the images for a thing and

the things for an image, or a list of all thing images within constraints.

What's next?

ThingImages Resource and Authn Specs.

Basically the same topic as this except we're going to test what

we just developed.

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.

© 2018 Coursera Inc. Todos los derechos reservados.

Descargar en la App Store

Consíguelo en Google Play