We can get this test to pass by generating a remember token at the command line:

Next we fill in the resulting migration with the code from Listing 8.16. Note that, because we expect to retrieve users by remember token, we’ve added an index (Box 6.2) to the remember_token column.  

Next we update the development and test databases as usual:

At this point the User model specs should be passing:

Now we have to decide what to use as a remember token. There are many mostly equivalent possibilities—essentially, any large random string will do just fine. In principle, since the user passwords are securely encrypted, we could use each user’s password_hash attribute, but it seems like a terrible idea to unnecessarily expose our users’ passwords to potential attackers. We’ll err on the side of caution and make a custom remember token using the urlsafe_base64 method from the SecureRandom module in the Ruby standard library, which creates a Base64 string safe for use in URIs (and hence safe for use in cookies as well).3 As of this writing, SecureRandom.urlsafe_base64 returns a random string of length 16 composed of the characters A–Z, a–z, 0–9, ‘‘-’’, and ‘‘ ’’ (for a total of 64 possibilities). This means that the probability of two remember tokens being thesameis 1/6416 = 2−96 ≈ 10−29, which is negligible.

              We’ll create a remember token using a callback, a technique introduced in Section 6.2.5 in the context of email uniqueness. As in that section, we’ll use a before_ save callback, this time to create remember_token just before the user is saved.4 To test for this, we first save the test user and then check that the user’s remember_token attribute isn’t blank. This gives us sufficient flexibility to change the random string if we ever need to. The result appears in Listing 8.17