[Libwebsockets] RFC: lightweight sessions

Colin Adams colinpauladams at gmail.com
Tue May 24 17:10:32 CEST 2016


OK. I've got it installed.

But when running I get messages:

lwsws[10192]: Unable to open session db /var/www/sessions/lws.sqlite3:
unable to open database file

I don't know anything about sqlite3, but I'm guessing perhaps I need to
define a user name first? Or is there something missing from the readme (I
issued the two commands to create the directory and set the owner to
root.apache).

On Tue, 24 May 2016 at 15:38 Andy Green <andy at warmcat.com> wrote:

>
>
> 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
> >      >      >
> >      >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20160524/46b09dad/attachment-0001.html>


More information about the Libwebsockets mailing list