Never have separate sign-in routes
<p>The former approach was used in the early web because pages were immutable back then, and it felt natural to have a separate page URL just because it had a form and not the other content.</p>
<p>To set up such redirects, you make pages without the authentication check and extract that check to some kind of guards that are called at the routing phase. They make sure the target pages are only shown if the user is authenticated.</p>
<h1>Problems of /sign-in route</h1>
<h2>1. A page without semantics</h2>
<p>A rule of thumb is to have a page with a URL if it is something people want to bookmark, revisit, and share. Who wants to share the <code>/sign-in</code> URL?</p>
<h2>2. Need to redirect back</h2>
<p>After the user was authenticated, they must be redirected to a page they wanted. This means that such a URL must be passed to the sign-in page in a form of <code>?back=/profile</code></p>
<p>This adds a lot of management and special cases with wrong or missing back URL.</p>
<p>And it just looks messy in the address bar.</p>
<h2>3. An entry in the browser history</h2>
<p>If a user had clicked a <code>/profile</code> link, was redirected to <code>/sign-in?…</code> and then back to <code>/profile</code>, these are three entries in the browser history.</p>
<p>If they click ‘back’, they expect to get to a page where they clicked the profile link. Instead they get back to <code>/sign-in?…</code> which redirects them again to <code>/profile</code> just because they are authenticated.</p>
<p>Users from the early 2000s are trained to double-click the ‘back’ button to escape those vicious sign-in redirects, but it is not a useful habit we want people to develop.</p>
<p><a href="https://medium.com/@alexey.inkin/never-have-separate-sign-in-routes-7c9a6dd4dc7c">Website</a></p>