[Libwebsockets] RFC: lightweight sessions

Andy Green andy at warmcat.com
Tue May 24 12:25:58 CEST 2016



On 05/24/2016 06:15 PM, Colin Adams wrote:
> 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 wrong).

It will be... you can see the schema here

https://github.com/warmcat/libwebsockets/blob/master/plugins/protocol_generic_sessions.c#L522

but the register / email part is not wired up yet.

Currently I am imagining this "generic-sessions" plugin only deals with 
authentication of a username.  That includes registration, email 
confirmation, "forgot password", eventually admin maintenance pages, 
managing the sesion database and so on, but NO other information except 
the client has a cookie authenticated for a given username (or no 
username if not logged in).

So the api to this in your ws protocol handler would only be "what's my 
username".  If it gives you a username, you know it has been 
authenticated.  You can also segregate access to mounts by if you're 
logged in, or logged in as admin, but that's it.

Storing stuff that your protocol handler deals in for that user, eg, 
using the username as the db key, is completely a separate issue private 
to your protocol handler.  It would, eg, use its own sqlite3 database 
for it if that's what he wanted to do.

-Andy


> On Tue, 24 May 2016 at 11:11 Andy Green <andy at warmcat.com
> <mailto: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 <mailto: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
>     LWS_WITH_LWSWS.
>
>     See
>
>     https://github.com/warmcat/libwebsockets/blob/master/README.generic-sessions.md
>
>     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 /
>     jipdocesExunt
>
>     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
>
>      > -Andy
>      >
>      >> On Mon, 23 May 2016 at 12:44 Andy Green <andy at warmcat.com
>     <mailto: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
>      >>> and javascript on client side
>      >>>
>      >>> - 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
>     <mailto:Libwebsockets at ml.libwebsockets.org>
>      >>> http://libwebsockets.org/mailman/listinfo/libwebsockets
>      >>>
>      >
>      > _______________________________________________ Libwebsockets mailing
>      > list Libwebsockets at ml.libwebsockets.org
>     <mailto:Libwebsockets at ml.libwebsockets.org>
>      > http://libwebsockets.org/mailman/listinfo/libwebsockets
>      >
>



More information about the Libwebsockets mailing list