[Libwebsockets] RFC: lightweight sessions

Andy Green andy at warmcat.com
Tue May 24 16:38:01 CEST 2016



On 05/24/2016 09:06 PM, Colin Adams wrote:
> I did:
> git pull
> cd build
> make
> sudo make install
>
> and got:
> CMake Error at cmake_install.cmake:427 (file):
> file INSTALL cannot find "/home/colin/libwebsockets/plugins/lwsgs.js".
>
> I had previously done:
>
> cmake -D LWS_WITHOUT_DAEMONIZE=OFF -D LWS_WITH_PLUGINS=ON
> -DLWS_WITH_LWSWS=1 ..
>
> so is there anything else I should have done?

No it's my fault, I missed it from git add.  Please fetch (not pull) 
master again.

Because master doesn't have a history, you need to track it like this, 
assuming you have no local patches

$ git fetch https://github.com/warmcat/libwebsockets.git +master:m && 
git reset --hard m

-Andy

>
> On Tue, 24 May 2016 at 11:26 Andy Green <andy at warmcat.com
> <mailto:andy at warmcat.com>> wrote:
>
>
>
>     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>
>      > <mailto: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> <mailto: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>
>      >     <mailto: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>
>      >     <mailto: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>
>      >     <mailto:Libwebsockets at ml.libwebsockets.org
>     <mailto:Libwebsockets at ml.libwebsockets.org>>
>      >      > http://libwebsockets.org/mailman/listinfo/libwebsockets
>      >      >
>      >
>



More information about the Libwebsockets mailing list