An interesting proposal

[Jeremie Miller]

There's been some strong direction lately in IRC and IRL discussions towards moving the login authentication process into lockerd core, letting it validate the http requests before serving them up by having the u/p or other auth info stored locally.  I think it's due time to do this and is an opportunity to really address another pain we've all been feeling lately with dashboardv3: the signed-out experience.

Once lockerd can serve up content before authentication, it could do this for more than just a default login screen, it could do this generically for any app.  Just as when visiting /Me/myapp/ it serves back by default index.html, it could still serve something for an app also when in the signed-out state but default to public.html instead.  This may seem simple like a simple addition (it is!), but it solves a whole host of gnarly code-organization issues that have been frustrating, like trying to share the same styles and resources for both a signed-in and signed-out view of an app.  I think dashboardv3 is just the first to encounter these pains as well, and this is a pattern that any app reaching sufficient complexity will feel when the author wants to have and maintain some public content.

This model of having every app conveniently packaged with both it's auth'd and public views means that it'd work identically on localhost as it would in a hosted environment, with the bonus of a hosted env being able to map a well known hostname to any app's public view.  http://mylovely.com/ could be served up directly from the public.html and lockerd can respond to some well-known /public/login or /public/register ajax calls to enable the person to sign-in or up directly from mylovely.com… boom, awesome :) 

This is a pretty simple solution for static public stuff, but further down the road it's also an interesting pattern that could evolve into dynamic or server-generated public content per locker too.

Jer