[Libwebsockets] RFC: lightweight sessions
colinpauladams at gmail.com
Tue May 24 12:15:14 CEST 2016
My opinion is that I personally will not need anything beyond what you have
already described (but I am assuming that the email address that the user
used for registration is available in the DB. And maybe that assumption is
On Tue, 24 May 2016 at 11:11 Andy Green <andy at warmcat.com> wrote:
> On 05/23/2016 11:37 PM, Andy Green wrote:
> > On May 23, 2016 9:14:57 PM GMT+08:00, Colin Adams
> > <colinpauladams at gmail.com> wrote:
> >> This sounds like something that I was going to have to write myself
> >> for my application (a game server). I can't think offhand of any
> >> further improvements, but I might find something when I try it
> >> out. My C skills are 17 years rusty (apart from fragments involved
> >> in writing language bindings), but I'm sure I can polish them up if
> >> I find any enhancements needed. Is this in master now?
> > No, it's very much a WIP.
> > But today it's working for admin login / logout, the cookies,
> > persistent session db, rewriting r/o copies of the state into js vars
> > (so the example login page js can change to a logout form
> > appropriately), and all customization in the lwsws JSON and login
> > html (there are hidden form elements that control the next url
> > depending on how the login / logout went).
> > I'll tidy it up and add some docs tomorrow, and check if it broke
> > anything else, but you can see it's only usable for development
> > today.
> I pushed what there is of it... for now it's enabled in cmake with
> You can add the mounts mentioned in there and the protocol import part
> to the existing lwsws example config.
> The admin account and password in the protocol config part is admin /
> If you navigate to http://localhost:7681/lwsgs you should see a login
> form that you can login with those credentials, which will take you to a
> URL in /lwsgs/needadmin/... that cannot otherwise be served.
> If you go back and refresh the login page, it now knows your session is
> authenticated and this time shows your login name together with a logout
> button... this is done in JS clientside with the tiny rewrite of
> "$lwsgs_user" in the included lwsgs.js.
> The active sessions are stored in sqlite3 on the server side and the
> expiry, controlled from the config file, should be respected.
> The actual users will also go in a table in sqlite3, but admin's
> credentials are set in the config outside of that. Those users and
> registration aren't done yet.
> > I'm mainly wondering what people want from the persistent user state,
> > in my case once authenticated, the next url is an html page opening a
> > ws link that will also get the logged-in session cookie. My
> > application is static html + js that dynamically configures itself
> > around the returned (user-context aware) JSON from the ws link.
> > Put another way the application's custom ws protocol handler code is
> > the guy who actually defines what different users see... that pattern
> > removes the need for any other server-side interpreter and just
> > manifests itself as delivering an authenticated username into custom
> > ws protocol code you would have to write anyway. Other
> > presentation-related code that needs to be aware of authentication
> > state (eg, show login form, or "logged in as xxx" + logout button)
> > moves out of what would have been server scripts and into js that got
> > some rewriting pixie dust. But I am curious if that pattern is
> > enough to solve other peoples' session-related tasks, perhaps with a
> > little thought.
> Still curious about opinions on this (maybe it's not explained clearly
> enough yet).
> > -Andy
> >> On Mon, 23 May 2016 at 12:44 Andy Green <andy at warmcat.com> wrote:
> >>> Hi -
> >>> I am partway through making a plugin called "generic-sessions",
> >> intended
> >>> to provide lightweight persistent http sessions without a
> >>> server-side interpreter.
> >>> The overall ideas are:
> >>> - random 20-byte session id managed in a cookie
> >>> - all information related to the session held at the server,
> >> nothing
> >>> managed clientside
> >>> - sqlite3 used at the server to manage active sessions and users
> >>> - defaults to creating anonymous sessions with no user
> >>> associated
> >>> - admin account (with user-selectable username) is defined in
> >> config
> >>> with a SHA-1 of the password; rest of the accounts are in
> >>> sqlite3
> >>> - login, logout, register account + email verification built-in
> >> with
> >>> examples
> >>> - in a mount, some file suffixes (ie, .js) can be associated with
> >>> a protocol for the purposes of rewriting symbolnames. These are
> >> read-only
> >>> copies of logged-in server state.
> >>> - When your page fetches .js or other rewritten files from that
> >> mount,
> >>> "$lwsgs_user" and so on are rewritten on the fly using chunked
> >> transfer
> >>> encoding
> >>> - Eliminates server-side scripting with a few rewritten symbols
> >>> - 32-bit bitfield for authentication sectoring, mounts can
> >>> provide
> >> a
> >>> mask on the loggin-in session's associated server-side bitfield
> >>> that must be set for access.
> >>> - No code (just config) required for, eg, private URL namespace
> >> that
> >>> requires login to access.
> >>> Login, logout, cookies, rewriting are already done, I am curious
> >> about
> >>> any comments or suggestions to make it more useful (especially
> >>> if
> >> anyone
> >>> is motivated to contribute).
> >>> -Andy _______________________________________________
> >>> Libwebsockets mailing list Libwebsockets at ml.libwebsockets.org
> >>> http://libwebsockets.org/mailman/listinfo/libwebsockets
> > _______________________________________________ Libwebsockets mailing
> > list Libwebsockets at ml.libwebsockets.org
> > http://libwebsockets.org/mailman/listinfo/libwebsockets
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libwebsockets