Best practice for users on pages in wrong conditions

Question

Our webapp has different technical pages, that are used as parts of some flows, for example:

• “Your session has ended” page where the user gets redirected when their session ends with timeout;
• “You are being authenticated” page, where the user lands right after returning from the authentication provider, while we do our job validating the session, etc;
• GDPR consent page, where the user end up after first login, or after the text of the consent changes;
• and others like that;

Essentially, those are pages that have their own permalinks (we’re trying to make sure that every page refresh keeps you where you were) and are a part of some conditional navigation - sometimes, when the conditions are right, the users get to visit those pages.

Now sometimes the users are sneaky or creative (as users are) and either bookmark one of those pages, or just type those URLs in and get to visit those pages out of appropriate conditions and get confused about what they see there: “Why does it say my session has ended? I clearly still have my session running!”.

At the moment we have some logic that checks if the conditions are right for each page and redirects the users back to dashboard before they even get to see it, so problem solved - if they stumble on some page they aren’t supposed to be on, we just lead them to safety automatically, all good.

---

My question is: what’s best practice for situations like that?

• Should we use status pages (like redirect to 404 as if it does not exist? or 424 even?) like we would when the page isn't found, or they have insufficient access rights?

• Should we just account for those events and silently redirect users back to safety? It feels like this way they have no way of learning what they did wrong. But maybe they shouldn't learn?

• Should we just render those pages and let them be confused?

Are there any guidelines about that?

Answer 1

I think the core problem here is that — to use REST terms — you've confused resources with their current states.

As much as possible, a URL should identify a resource — some entity, or a view of that entity, that in some sense continues to exist, and can be repeatedly GET-queried for the current state of that resource.

Let me reframe your scenarios to be about resources rather than states:

“Your session has ended” page

This should be a “your account” or “your session” page; it should display whether the user has an active session, and offer to log out or log in as appropriate.

“You are being authenticated” page

This can be a state presented by the session page. If you need URL parameters, prefer to carry them through redirects (that is, URLs that upon GET return 3xx, not 2xx) — not non-redirect pages the user can easily view and bookmark.

In case the user bookmarks the redirect, or you absolutely have to show a page — don't worry about that too much since it's momentary (unlike e.g. the “session ended” page case). If such a page is loaded when it doesn't apply, you should either display an error and offer them a link to where you think they would like to go (if you want to discourage keeping and sharing that URL), or just redirect.

GDPR consent page, where the user end up after first login, or after the text of the consent changes;

This is a great example of how you can simultaneously put things on a consistent foundation and give users a better experience: let the users see the consent page even if they've consented so that they can see what they consented to. “Whether they've consented, and if so to what version” is the state of this resource, which you can display above/below the legal text.

---

we’re trying to make sure that every page refresh keeps you where you were

As a user, I applaud your care. Just remember that “where” is “what resource”, not “what state”.