In principle, there’s still a minor security hole, which is that an admin could delete himself by issuing a DELETE request directly. One might argue that such an admin is only getting what he deserves, but it would be nice to prevent such an occurrence, and doing so is left as an exercise (Section 9.6).

           As you might suspect by now, the application code uses a before filter, this time to restrict access to the destroy action to admins. The resulting admin_user before filter appears in Listing 9.48.

At this point, all the tests should be passing, and the Users resource—with its controller, model, and views—is functionally complete.