[Libwebsockets] RFC: lightweight sessions

Andy Green andy at warmcat.com
Tue May 24 17:25:56 CEST 2016



On May 24, 2016 11:16:17 PM GMT+08:00, Colin Adams <colinpauladams at gmail.com> wrote:
>I'm just calling
>sudo /usr/local/bin/lwsws
>so it ought to be running as root

I missed this off the readme...

# chmod 770 /var/www/sessions

-Andy

>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
>> >> >      >      >
>> >> >      >
>> >> >
>> >>
>>
>>




More information about the Libwebsockets mailing list