API: Account Signup

Loading...

From the course by Johns Hopkins University

Capstone: Photo Tourist Web Application

18 ratings

Johns Hopkins University

Capstone: Photo Tourist Web Application

18 ratings

Course 6 of 6 in the Specialization Ruby 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

From the lesson

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.

Module 4 Introduction5:55

BTA Interview9:29

Token-based Authentication8:54

Server: Devise Token Auth Setup8:15

API: Authentication Requirements4:20

API: Account Signup5:35

API: Account Signup Failures and Error Payloads5:40

Server: Devise Setup Errors Discovered/Fixed7:23

API: Authenticated Access Control4:40

API: Authenticate6:41

API: Authenticated Access8:23

API: DRY Token Authentication Specs5:12

Meet the Instructors

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

[MUSIC]

In this lecture, we will discuss user registration and

how we're going to create a user account through the API.

We'll also talk about devise strong parameters and what we need to do to

whitelist any custom parameters we have in our registrations and

we'll build our first real factory, something besides and foo and a bar.

We'll build a factory that represents the properties of the user.

A good place to start with any test is obviously taking care of our

database clean up.

So we're going to include context, db_cleanup and we're going to go ahead and

clean up after each test.

And I'm going to go ahead and use transactions not because I have to,

because yeah, I can.

All we're using is the relational database at this point and

let's focus in on the sign up.

In order to sign up, I'm going to need some user properties and I'll store that

into the user props variable and I'll create a let clause with the user props.

So, let's take a look at signing up successfully.

What I'll need to do is post to the user_registration_path,

a set of registration parameters like user_props for

that and then response for that should come back okay.

And since it's early, I'm starting out by putting some debug.

We could execute this now.

However, they refer to a factory that doesn't quite exist yet, user.

So in order to run this, we really need to create that factory first.

So I'll just go ahead and start it, manually.

And when we sign up, we're going to need name, email, and password.

And we're going to generate a value, a unique value, each time.

So we're going to be executing a block and

inside of here, I'll go ahead and

create some fake names emails.

Those are probably all the passwords you don't want to use.

We have our sample user.

Let's go ahead and run this, and see what we're missing.

Hey, everything looks good.

We submitted a document with name, email and

password and we created an account.

Account number one, it's authentication type is email.

It's going to do a uid across all of its providers.

It's going to use email and you'll notice name is nil, that's not quite right.

We can fix that, although not horrible.

And then specifically, here's our email and when we were created.

So, we happen to notice through inspection that name wasn't echoed back.

So, we don't want to be inspecting things all the time.

We want to actually have our test tell us that.

To speed things up, let me go ahead and

bring in a block of inspectors that looks at that payload.

We expect the status to be successful.

We expect to have a data payload and data information.

And now when we rerun, it fails, because our name wasn't supplied.

So, why is that?

Through your familiarity with rails,

you should be familiar with something called strong parameters and wait listing.

Well, we're talking to the devise infrastructure and

the devise infrastructure out of the box comes by allowing certain things through.

Email, obviously, and password were allowed through.

So, what we need to do is head over to the application controller

and add a white list entry for our name.

So we're going to say, hey,

devise sanitizer permit during sign up that we pass in name.

And of course, that goes nowhere until we wire it in.

And say, if you're the devise_controller, then what we'd like for

you to do is run this method which will configure your white listing.

Now if we rerun the test, everything passes and

we don't have to look at anything.

Sign-up, looks like it's working.

We can get an account.

Our account registration primarily takes email and password.

That's all white listed by devise.

Name was added in as a custom parameter out of the box by Devise Token off, but

still required for it to be white listed for

it to be accepted at registration time.

We could add more parameters like phone number, points of contact,

things like that.

We'll just stick with some of the basics and then we took a look at whitelisting.

Anything beyond email and

password needs to be explicitly allowed through a configuration command,

then we build a factory that represented a user, something more than just a food.

We had name, email and password.

What's next?

Account Sign-Up Failures and Error Payloads.

Let's look at some of the failure scenarios and

understand the error payloads coming back from devise,

so that when we move over to the UI, we know how to handle them.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.

© 2018 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play