[Libwebsockets] RFC: lightweight sessions

Colin Adams colinpauladams at gmail.com
Tue May 24 15:06:54 CEST 2016


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?


On Tue, 24 May 2016 at 11:26 Andy Green <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>> 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
> >      >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20160524/fe80ded1/attachment-0001.html>


More information about the Libwebsockets mailing list