Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

StrongLooping a Blog — Part Two: RESTful Implementation

DZone's Guide to

StrongLooping a Blog — Part Two: RESTful Implementation

In part one, I covered using loopback methods and models I used to create a blog. In Part Two, I’m going to cover how I can lock down RESTful APIs.

· Web Dev Zone
Free Resource

Add user login and MFA to your next project in minutes. Create a free Okta developer account, drop in one of our SDKs to your application and get back to building.

Welcome to the next blog entry in my series describing building a real (kind of) application with StrongLoop. In the last entry, I talked about the application I was creating (a simple blog), built the model, and demonstrated how to work with the model on the server-side. I completely skipped over using the REST APIs to focus on a simple content-driven dynamic site.

This is in preparation for working on an admin for the blog in a later post. This post will be a bit short as this is a topic I covered in depth a few months ago (Working with StrongLoop (Part Four) – Locking down the API), but I wanted to discuss the topic again to call out a few things I missed last time. I suggest reading that earlier post to give some additional context to what I’m describing below.

So, first off—out of the box your models are completely CRUDable (create/read/update/delete) via the REST API. This is handy, but of course you want to lock down these APIs so folks don’t pepper your site with SEO spam.

As I discussed in my earlier post, locking down your API is as simple as using slc loopback:acl. Here is an example:

shot1

In the end, the CLI simply updates the model’s JSON definition file. In general, the lock down process is:

  • Block everything!
  • Allow anon folks to read
  • Allow auth users to write

Here is how this looks in JSON:

"acls": [
   {
      "accessType": "*",
      "principalType": "ROLE",
      "principalId": "$everyone",
      "permission": "DENY"
    },
    {
      "accessType": "READ",
      "principalType": "ROLE",
      "principalId": "$everyone",
      "permission": "ALLOW"
    },
    {
      "accessType": "WRITE",
      "principalType": "ROLE",
      "principalId": "$authenticated",
      "permission": "ALLOW"
    }

Of course, this assumes a security model where every logged in user is an admin. More complex apps will probably have different roles associated with users. So in a blog, you may have users who can write content, but only some who can publish content so that the entry is publicly readable. For now, I’m sticking with the simple system of allowing logged in users full power.

I did this for both entry and category. Remember, these are the primary model types for my blog.

I then created a new model called appuser. Again, I discussed this in the previous entry, but while Loopback has a core User object, it is strongly suggested you extend this type into your own for your application. One thing I didn’t demonstrate in the previous post was how this was done in the Composer app. It is a simple matter of making a new type and changing Base model to User.

shot1

Next, I needed to test this. Again, I mentioned in the other post about how you can use the web-based Explorer to log in, but it occurs to me that I didn’t actually show how that is done. Login is just another REST method! If you select your user type, you can scroll down to a login method. You then need to enter a JSON object containing your credentials.

sl login

After you log in, make note of the response. The ID contains a token:

Explorer-token

(Image taken from StrongLoop docs: Introduction to User model authentication)

You take that and then paste it into the token field on top of the explorer.

shot2

This ensures your later calls via the explorer are authenticated. To be sure, I tested posting a new entry before being logged in:

shot3

Then, I confirmed I could create after logging in:

shot4

I bet your curious about the server-side API. Is it impacted by ACLs? Nope. I guess that’s expected, but I was curious. Basically, your Node.js code executes like a root user.

The updated version of the code can be found here: https://github.com/cfjedimaster/StrongLoopDemos/tree/master/blog2.

Launch your application faster with Okta’s user management API. Register today for the free forever developer edition!

Topics:
strongloop ,node.js ,web dev

Published at DZone with permission of Raymond Camden, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}