API: Account Signup Failures and Error Payloads

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 devise account sign-up errors and

the error payloads that come back so we can ready for our UI development.

With sign-up complete, it's time to start the error path.

If we take a look at their missing information and if we come up here and

bring in, do a copy, and paste that in, the alarm bell should go off.

Like, hey,

creating an account that sure seems like it's going to be a reuseable thing.

So why don't we instead of copying that and putting it there, why don't we

go over to spec/support/api_helper and create a sign-up.

Let's also check the status, but we're getting ready to do an error path,

so we should allow them to supply an optional parameter.

Okay, so if it's a failure case we want them to be able to tell that.

Okay?

So they're going to ask for registration.

We'll do a post.

We'll post the registration materials.

We'll expect a specific status response back.

Now I can go up here.

Change that to signup user_props.

It's going to default to okay.

Let me rerun my successfully creates account test.

That passes so it looks like this implementation is good to reuse.

Okay, but it's going to be missing information.

So, why don't we pass in instead of just user props,

let's pass in user prompts minus email.

And then let's supply a status code that's not non-positive.

Okay, that's a good start.

We're going to take a look at the payload.

So our test passed because we're only looking for the failure to occur, and

then we get a document back that tells us the status of our request.

In the data is what it heard and the fact that we didn't supply it an email,

and in the errors is the fact that we have some email issues going on.

I kind of like this structure because think of it.

If we can give this back to the UI and say in this field, that can't be blank,

or in general, in this form, emails can't be blank.

So I'm going to follow this kind of format,

this kind of approach as we design out our other interfaces.

Without going hog-wild, let's go in and put in a verification block and say that,

okay, I am going to assert that what came back was an error in the document.

That in the data they've told me that my email is not supplied, basically nil.

That there's going to be some errors supplied, and the errors are going to

tell me something about the email field, but I don't know what.

Mia's writing the test, I don't know what it's going to say.

And then in the full messages, it's going to say something.

I don't know exactly what it's going to say, but

it's going to say something about email.

So, if I rerun that.

[SOUND], that needed to be a regular expression.

Let me change the quotes to a regular expression.

And while I'm at it, let me not assert that they have a capital e but

it could be a lowercase e.

So now I'm saying that somewhere in the strings there will be the word email.

Okay, that's looking good.

We now have invalid registration as well as valid registration.

And we have the startings of some helper methods, sign-up.

That should be quite helpful when we come to this non-unique information.

So based on everything we've covered, successful sign-up with user prompts,

and unsuccessful sign-up with a missing email and

an error message, you should be able to complete this last one.

To be able to just turn this into a block out of the pending state, and

verify that if someone supplies an email that's already been registered to

an account that they'll receive an error.

And that error should have some kind of indication that it's

about the email address.

So in summary, we took a look at account sign-up errors and the error reporting.

And specifically the error payload,

because we're going to have to communicate with this when we develop the UI.

We notice that devise returns back the errors in sign-up in nice field format.

You're missing a field, this one's an error, things like that,

as well as full request messages, like your email is wrong, your name is missing.

So on the UI, we have a choice of displaying things per field or

at the overall form level.

And then I left you with a practice to do.

You should be able to complete the non-unique information example group.

And look in your get repository if you have an issue.

What's next?

Authenticated Access Control.

Wait, the build server discovered an error with our device setup, and

we need to go fix that before we move on too much further.

Like all normal developments, we can't plan our errors.

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.

© 2019 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play