use a JWT instead of a unique token) and we have a few corner cases to handle (e.g. There are a few other possible designs (e.g.
retrieve the subscriber id associated with subscription_token from the subscription_tokens table.retrieve subscription_token from the query parameters.Once they click on the link, a browser tab will open up and a GET request will be fired to our GET /subscriptions/confirm endpoint. send an email to the new subscriber containing a link structured as.store subscription_token in our database against their id in a subscription_tokens table.generate a (unique) subscription_token.add their details to our database in the subscribers table, with status equal to pending_confirmation.We will try to keep it as simple as we can - our version will not perform a redirect on confirmation, we will just return a 200 OK to the browser.Įvery time a user wants to subscribe to our newsletter they fire a POST /subscriptions request. From that point onwards, they will receive all newsletter issues in their inbox. Once they click on it something happens and they are then redirected to a success page ( "You are now a subscriber of our newsletter! Yay!"). They will receive an email with a confirmation link. Let's look at our confirmation flow from a user perspective. This works nicely for us - we shield our users from abuse and we get to confirm that the email addresses they provided actually exist before trying to send them a newsletter issue. This is why it has become common practice to send confirmation emails: after entering your details in the newsletter HTML form you will receive an email in your inbox asking you to confirm that you do indeed want to subscribe to that newsletter. If you are dealing with European citizens, it is a legal requirement to get explicit consent from the user. This is why a request to POST /subscriptions is not enough to say "This person wants to receive my newsletter content!".
professional emails) are outright public.Ī malicious user could start subscribing an email address to all sort of newsletters across the internet, flooding the victim's inbox with junk.Ī shady newsletter owner, instead, could start scraping email addresses from the web and adding them to its newsletter email list.
There is one more thing we are concerned about though, which we cannot postpone: subscriber consent.Īn email address is not a password - if you have been on the Internet long enough there is a high chance your email is not so difficult to come by.Ĭertain types of email addresses (e.g. If performing thorough validation was our only concern, I'd concur: we should wait for the next issue to go out instead of adding more complexity to our POST /subscriptions endpoint. Your spider-senses should be going off now - do we actually need to know at this stage of the subscriber lifetime? Can't we just wait for the next newsletter issue to find out if they receive our emails or not? We have no idea and there is only one way to find out: sending out an actual confirmation email. We now have emails that are syntactically valid but we are still uncertain about their existence: does anybody actually use those email addresses? Are they reachable? In the previous chapter we introduced validation for the email addresses of new subscribers - they must comply with the email format. You can find the snapshot of the codebase at the beginning of this chapter on GitHub.
How To Reuse The Same reqwest::Client In actix-web.How To Write A REST Client Using reqwest.
We'll deal with both the happy and the unhappy path (server errors and timeouts). how to test it using HTTP mocking via wiremock.how to write a REST API client using reqwests.We need to send a confirmation email to the new subscribers of our newsletter. Subscribe to the newsletter to be notified when a new episode is published. This article is a sample from Zero To Production In Rust, a book on backend development in Rust. A learning journal How To Write A REST Client In Rust