For the authenticated user to be populated you must inform AdonisJS to check for it. This saves the roundtrip to populate the user in cases where it isn't needed.

To populate the user, you have two options

1. authenticate - Requires an authenticated user. If an authenticated user is not found, an exception is thrown.

2. check - Will check to see if a user is authenticated, and populate that user if so. The request goes on as usual if an authenticated user is not found.

In terms of middleware, you have three options

1. auth - Will call authenticate and redirect the user to the login page by default if an authenticated user is not found.

2. guest - Will call check and redirect the user, I believe to the home page, by default if an authenticated user is found.

3. silent_auth - Will call check and progress with the request as usual.

So, you're most likely getting "the page isn't redirecting properly" because your authenticate on the login page is attempting to redirect the user to the login page, resulting in an infinite redirect loop.

You most likely will want to replace your authenticate on the login page with the guest middleware and that should fix the redirect loop. Then, for internal pages, you can either use authenticate if the user must be authenticated to access the page, check if the user may or may not be authenticated to access the page, or one of the corresponding middleware.

Hi Arron!

Great question, I now wish I would've injected this into the lesson; I think I'll make a note to do that.

The Referrer-Policy mentioned is a response header. So, in the controller rendering this page you'd add it using the HttpContext's response, like below. This is a step recommended by OWASP.

async reset({ params, inertia, response }: HttpContext) {
  const { isValid, user } = await VerifyPasswordResetToken.handle({ 
    encryptedHash: params.hash 
  })

  response.header('Referrer-Policy', 'no-referrer') // 👈

  return inertia.render('auth/forgot_password/reset', {
    hash: params.hash,
    email: user?.email,
    isValid,
  })
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Hi memsbdm!

The mailer at plotmycourse.app is indeed still up and running, you might need to check your spam for it's email. However, I can confirm I'm having the same issue. I'm not immediately sure why this would be happening, it looks like it isn't properly returning an Inertia response from the validation handling.

I'll be able to dig into it further after work and will let you know if I find anything!

Hey Tresor!

Password Reset

The differences between using signed URLs and a database-stored token for password resets mostly come down to weighing the pros and cons, and how important those are for your site's use case.

Signed URLs are reliable and quick to implement. However, since they aren't stored in the database, we need a way to attach them to a user, like adding the user's email or ID to the signed URL. Additionally, once generated, we have no way to invalidate the token until its expiry time is reached. This means we can't expire a token after it's been used. This will suffice for most basic apps and is a fine option if you're just starting out with a small user base.

Database-stored tokens have a bit more overhead to implement, and we need to manage the tokens ourselves. However, since the token is stored in the database we don't need to expose any of our users' information via the URL. Additionally, we have the ability to update the database record at any time, so it can easily be expired once used. This is a great option if protecting your users info, even from their own inbox, is a top priority. It's also a must-use if you need to invalidate a token after use (for example, say you need to use an expiry longer than you'd feel comfortable leaving lingering).

The third option here is to use both, generate a token then sign that token into the URL. This would be the most secure option. It takes away the cons of just using a Signed URL and adds an extra obfuscation layer to the database-stored token. Might be seen as a bit overkill depending on the app though.

So, none of the above are bad options unless the type of site you're building or its audience dictates a higher level of security. I actually plan on updating Adocasts password reset flow to use database-stored tokens here in the future. I almost did it with a redesign I'm working on, but opted to save it till after.

Deferred Mail Sending

If we actually dig into sendLater and poppinss/defer, both are in-memory queues using fastq under the hood to actually do the queuing. So, I'd argue there's no real difference between the two unless one has a specific feature you're looking for.

The downside to an in-memory queue is that if your server crashes or reboots (like when you deploy) then anything in that queue has been lost. If you don't send many emails and don't deploy all that often then the likelihood of a lost email is pretty slim.

If you send emails frequently or deploy frequently then your chances of a lost email increase. You might also be sending mission-critical emails that must reach their destination (think appointment confirmation or order receipt emails). That's where an alternative like BullMQ can help because it'll hold the queued item until it's processed, even if the app reboots. You can also swap sendLater's in-memory queue with BullMQ as well. So, you can start with in-memory and upgrade the queue system very easily down the road without having to rewrite your sendLater code.

I'm still using an in-memory queue for Adocasts emails, but I don't deploy all that often and Stripe takes care of our purchase-based emails.

Hope this helps!!