[Libwebsockets] RFC: lightweight sessions

Colin Adams colinpauladams at gmail.com
Tue May 24 17:52:59 CEST 2016


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:

lwsws[10660]: failed to get sid from wsi


On Tue, 24 May 2016 at 16:26 Colin Adams <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> 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> wrote:
>>
>>>
>>>
>>> On May 24, 2016 11:10:32 PM GMT+08:00, Colin Adams <
>>> 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> 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/fb62ee0d/attachment-0001.html>


More information about the Libwebsockets mailing list