Using RequestStore with asynchronous I/O in Rails apps

Brian Morearty — Mon, 22 Nov 2021 19:37:29 +0000

Did you know it’s possible to write Rails apps using non-blocking, asynchronous I/O, the way Node apps work? Your app handles each web request in a fiber. Whenever that fiber fires off a blocking operation like a network call, it can yield the current fiber and allow another fiber to use the CPU. In fact it’s more convenient than Node because your methods are colorless—there are no issues with synchronous methods calling async methods.

Writing a Rails app with fibers has two advantages over threads:

No worrying about race conditions. This is a big deal.
More scalable. Fibers use much less memory than threads. You can create hundreds of thousands of fibers without problems.

You can use the Async gem and the Falcon web server to take advantage of this capability. And starting in Ruby 3.0, async I/O is even more automatic because inside the Ruby runtime, all socket operations will automatically yield the current fiber by default. It’s fully transparent to the developer. Your I/O calls appear to be blocking so they are easy to understand, consistent with Ruby’s “programmer happiness” philosophy.

Problem

As people start using this technique more and more, some problems will come up. One I’ve noticed is the inability to use the request_store gem. This is a gem that helps you make per-request “global” storage that doesn’t accidentally leak from one request to the next. For example you could use it to store information about the current user without having to pass it down to every method but without worrying that it will leak into the next request. Globals aren’t exactly the best thing ever, but sometimes they’re practical and you do what you gotta do.

request_store was written to handle web servers that handle each request in its own thread so it stores the per-request data in thread-local storage in Thread.current[:request_store]. But the problem is, despite its name, Thread.current is actually fiber-local, not thread-local. So your request handler could store the current user info in the request store, then fire off a new fiber to make an I/O call concurrently, and that fiber won’t have access to the request store.

Solution

To fix this I wrote a new request_store-fibers gem that detects whenever a new fiber is created by hooking into Fiber.new. Before the fiber is executed, I copy the current request_store data into a variable. Then as soon as the fiber is resumed the very first time, I copy that data into the fiber's request_store.

Presto! Thanks to Ruby’s ability to hook into core APIs, now you can use request_store with a Rails app that has fibers.

request_store-fibers is actually a thin layer on top of another more generic gem I wrote, fiber_hook, which does all the magic. It lets you hook into fiber creation and do anything you want right after any fiber is created and before it executes.

Better Deno Security: Ask for Permission at Runtime

Brian Morearty — Thu, 28 May 2020 13:46:00 +0000

Deno, the new kid on the block in server-side TypeScript and JavaScript, is secure by default. You kind of can’t miss it. They’ve been hammering that point all over their documentation and conference talks just to make sure you know. It’s on their homepage too, repeated in the first three sentences.

I'm glad they chose secure by default. But I'm not crazy about the samples they use to demonstrate security. The samples promote the idea that you should specify in advance what an app’s permissions are going to be. This reminds me of the old Android model, where you had to grant all permissions to an app when installing it. Eventually Android fixed it to be like the better model that iOS and browsers use: let the program request the necessary permissions at runtime so the user can respond to the request in context.

Let's look at sample code from the Deno v1 announcement:

import { serve } from "https://deno.land/std@0.50.0/http/server.ts";

for await (const req of serve({ port: 8000 })) {
  req.respond({ body: "Hello World\n" });
}

I’ve copied this sample to a GitHub repo so you can run it directly:

$ deno run https://raw.githubusercontent.com/BMorearty/deno-permissions-samples/master/serve-original.ts

and you’ll see that it fails, as it should, because it doesn’t have network permission. The v1 page explains this: "The above example will fail unless the --allow-net command-line flag is provided."

Fix by running with --allow-net.

$ deno run --allow-net https://raw.githubusercontent.com/BMorearty/deno-permissions-samples/master/serve-original.ts

(You won’t see any output because it’s silently waiting on a port.)

Sounds nice and secure. But when a user downloads a script and runs it, or runs it directly off the Internet as in the examples above, they don’t have advance knowledge of why the program needs network permission—or worse, file permission. So they’ll blindly grant it all the permissions it says it needs before they even run it.

This is similar to what used to be required when installing an Android app. When I had an Android phone I found it vexing. Sometimes I wanted an app but didn’t want to grant it access to, for example my contacts. The slight improvement with Deno is that at least with Deno, permissions aren’t all-or-nothing, chosen by the developer.

A better option: ask for permission at runtime

Thankfully, Deno already provides a better security model than this. It’s just not heavily promoted. The program can ask for permission at the point of need, rather than requiring the user to grant it up front on the command line.

// serve-request.ts
import { serve } from "https://deno.land/std@0.50.0/http/server.ts";

const netPermission = await Deno.permissions.request({ name: "net" });
if (netPermission.state === "granted") {
  for await (const req of serve({ port: 8000 })) {
    req.respond({ body: "Hello World\n" });
  }
} else {
  console.log("Can’t serve pages without net permission.");
}

At the time of this writing, Deno.permissions is not yet part of the stable API so you need to run this with --unstable:

deno run --unstable https://raw.githubusercontent.com/BMorearty/deno-permissions-samples/master/serve-request.ts

Here’s how this looks when granting permission (I typed g and hit Enter):

And here’s how it looks when denying:

The "Deno requests" line is part of Deno itself, not controlled by the app. As you can see from the code above, the “Can’t serve pages without net permission” line is the app’s custom response. An app can respond any way it likes to the user’s choice not to grant permission.

Don’t worry about Deno asking for permissions that are already granted. If the user runs the app with --allow-net, the Deno.permissions.request call won’t redundantly ask for permission. It will just return { "state": "granted" } immediately.

The same is true if an app requests the same permission multiple times at runtime. If it’s already been granted or denied once during runtime, the response is remembered in all subsequent permission requests.

// request-twice.ts
const netPermission1 = await Deno.permissions.request({ name: "net" });
console.log(
  `The first permission request returned ${JSON.stringify(netPermission1)}`,
);
const netPermission2 = await Deno.permissions.request({ name: "net" });
console.log(
  `The second permission request returned ${JSON.stringify(netPermission2)}`,
);

Run:

$ deno run --unstable https://raw.githubusercontent.com/BMorearty/deno-permissions-samples/master/request-twice.ts

As you can see, it only asks for permissions once:

Give context when asking for permission

The iOS Human Interface Guidelines on permissions state:

Explain why your app needs the information. Provide custom text (known as a purpose string or usage description string) for display in the system's permission request alert, and include an example. Keep the text short and specific, use sentence case, and be polite so people don't feel pressured. There’s no need to include your app name—the system already identifies your app.

This is good advice for Deno apps as well. If you give the user context about why you need permission, they’re more likely to grant it:

// serve-context.ts
import { serve } from "https://deno.land/std@0.50.0/http/server.ts";

let netPermission = await Deno.permissions.query({ name: "net" });
if (netPermission.state === "prompt") {
  console.log("Net permission needed to serve web pages.");
  netPermission = await Deno.permissions.request({ name: "net" });
}
if (netPermission.state === "granted") {
  for await (const req of serve({ port: 8000 })) {
    req.respond({ body: "Hello World\n" });
  }
} else {
  console.log("Can’t serve pages without net permission.");
}

This version prints the reason for the request right before making the request. The gives the user enough context to understand why Deno is requesting permission.

But what’s this call to Deno.permissions.query? Now that we’re displaying some context before the permission prompt is shown, it’s necessary to first check if the app already has permission. Otherwise you’ll display the permission context for no reason.

Deno.permissions.query can return three possible states:

{ "state": "granted" } means you already have permission.
{ "state": "denied" } means you have already been denied permission. There’s no point in requesting it because it will return "denied" immediately without showing a prompt.
{ "state": "prompt" } means if you call request, a prompt will be shown to the user.

Let’s run it:

deno run --unstable https://raw.githubusercontent.com/BMorearty/deno-permissions-samples/master/serve-context.ts

And you’ll see the prompt:

If you run with --allow-net, you can see that it doesn’t display the context because the call to Deno.permissions.query indicated that the call to Deno.permissions.request would return success.

In my opinion this is the best way to deal with permissions in your code.

Wish list: store permissions persistently for installed scripts

Deno has a deno install command that lets you add a Deno script to your machine:

$ deno install --unstable https://raw.githubusercontent.com/BMorearty/deno-permissions-samples/master/serve-context.ts

This downloads, compiles, and caches the script and its dependencies. It also creates an executable script. On a Mac it’s stored in ~/.deno/bin/serve-context (you can add ~/.deno/bin to your PATH) and looks like this:

#!/bin/sh
# generated by deno install
deno "run" "--unstable" "https://raw.githubusercontent.com/BMorearty/deno-permissions-samples/master/serve-context.ts" "$@"

Notice that parameters you pass to deno install, such as --unstable, get passed on to deno run. You could deno install --allow-net https://my/script and it would store the --allow-net permission in the executable.

Again, it’s not ideal to require your users to decide up front what all the permissions are. But Deno doesn’t store the permissions persistently. After installing serve-context without --allow-net, every time I run it, it asks for net permission.

I’d love to see an improvement to Deno that allows it to locally cache the user’s answers to permission questions per app. This is what browsers do when a domain requests permission, such as camera or geolocation. Of course you’d also need a way to revoke or grant permissions after the fact.

Wish list: let the script pass the reason into the `request` call

In the serve-context example we had to:

Call Deno.permissions.query to see if a permission has been granted.
If not:
1. Display a reason that the script needs the permission
2. Request it with Deno.permissions.request.

It’d be a lot simpler if you could do all this in a single call to Deno.permissions.request. I think Deno should let the script pass in a short reason string to the permission request. If the script doesn’t already have permission, the reason would be displayed before the user is asked to grant permission. If the script already has permission, the reason won’t be displayed.

If Deno supported this, the steps would be shortened to just:

Request permission with Deno.permissions.request.

Here is what the code would look like (not runnable because reason is not currently a valid key to pass in to request):

// serve-reason.ts
import { serve } from "https://deno.land/std@0.50.0/http/server.ts";

const netPermission = await Deno.permissions.request(
  { name: "net", reason: "Net permission needed to serve web pages." },
);
if (netPermission.state === "granted") {
  for await (const req of serve({ port: 8000 })) {
    req.respond({ body: "Hello World\n" });
  }
} else {
  console.log("Can’t serve pages without net permission.");
}

References

Deno permissions documentation. The list of permission types is in the PermissionDescriptor type, but as of this writing, Deno doesn't seem to have docs for this type.
Current list of PermissionDescriptor values, currently in unstable.ts.
You can follow me on Twitter.

DEV Community: Brian Morearty