[Libwebsockets] RFC: lightweight sessions

Andy Green andy at warmcat.com
Tue May 24 18:11:43 CEST 2016



On 05/24/2016 11:52 PM, Colin Adams wrote:
> OK. Getting nearer now.
>
> If I understand the readme correctly, to get a login page i need to
> point my browser to
>
> http://localhost:7681/lwsgs
>
> If I do that, I get a 404, and the log says:

The canned paths in the readme assume things installed in /usr/share, 
you'll need to slip a '/local' in them if that's where they were installed.

> lwsws[10660]: failed to get sid from wsi

That's ok since no chance to paint the client with a cookie the first time.

-Andy

>
> On Tue, 24 May 2016 at 16:26 Colin Adams <colinpauladams at gmail.com
> <mailto:colinpauladams at gmail.com>> wrote:
>
>     Confirmed that it acquired the apache id:
>
>     ps -U root -u apache u | grep lwsws
>     apache   10599  0.0  0.0  70032  6108 ?        Ss   16:25   0:00
>     /usr/local/bin/lwsws -D
>
>
>     On Tue, 24 May 2016 at 16:16 Colin Adams <colinpauladams at gmail.com
>     <mailto:colinpauladams at gmail.com>> wrote:
>
>         I'm just calling
>         sudo /usr/local/bin/lwsws
>         so it ought to be running as root
>
>         On Tue, 24 May 2016 at 16:13 Andy Green <andy at warmcat.com
>         <mailto:andy at warmcat.com>> wrote:
>
>
>
>             On May 24, 2016 11:10:32 PM GMT+08:00, Colin Adams
>             <colinpauladams at gmail.com <mailto:colinpauladams at gmail.com>>
>             wrote:
>              >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).
>
>             Are you starting it as root?  Otherwise it doesn't have the
>             rights to change to run under apache uid.
>
>             -Andy
>
>              >On Tue, 24 May 2016 at 15:38 Andy Green <andy at warmcat.com
>             <mailto: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>
>              >> > <mailto: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>>
>              >> >      > <mailto: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>>
>              ><mailto: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>>
>              >> >      >     <mailto: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>>
>              >> >      >     <mailto: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>>
>              >> >      >     <mailto: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