Start at the Beginning

It’s time to go log in to the system to do the thing. You had gotten an email about some “secure” message visible only on the website, but you don’t trust links in emails but on logging in to the web site you can’t find the secure messages area. You’ve been expecting this message, because it’s about some ongoing thing you’re dealing with — health care, a loan, a job application; it doesn’t matter — and their website is terrible anyway so it’s no surprise you can’t find the thing you need.

Resigned, you copy the link from the email and verify it goes to the correct place, and paste it into your browser. You were already logged in, but this link apparently takes you through some system that assumes you weren’t logged in and forces you to log in again. You do that, but afterwards you’re taken back to the normal post-login landing page for this website.

Frustrated, and with the tab for this site still open, you click the link in the email directly, now that you know you can trust it. The same thing happens. You begrudgingly click on the “chat with a support agent” icon in the corner, steeling yourself for the admonishment that you’re obviously not very tech savvy because you can’t figure out their incompetently-implemented website.

Whatever the excuse, when a website visitor needs to authenticate to view a particular URL, they should be taken back to that URL after authenticating. If that URL is non-existent, they should receive an error message stating so. Sending links in emails is a bad practice, but if you’re going to, make sure your links work.

I’ve recorded the above-described process happening to me in the past few years more times than I can count on one hand’s fingers, and I default now to base 12 counting. It’s frustrating beyond measure, but when it happens on websites I have little choice in interacting with, it’s demoralizing.

In my research for this series, I did attempt to debug this problem with two websites I am forced to use – one government website for business taxes, one large health-care website. In one case the best I could determine was they stored the original URL in a cookie, but the authentication process happened on a different domain and they used incorrect domain headers and my browser’s console was complaining about Cross-Origin Resource Sharing violations. For the other one, I found nothing — perhaps it was stored in some server-side session store, perhaps they did nothing with it.

Session stores, server- or client-side, are a bad place to store transient, request-based information such as where to redirect someone to after they authenticate. Requests happen transactionally, in isolation to each other, and they are only relevant for the particular tab/window in which they happen. Adding the original destination to the url as a query parameter is a common method to keep it that way.

Of course, these incorrect implementations can also be helped by better navigation and notification affordances in the website design themselves, but that’s another topic.