[Libwebsockets] RFC: lightweight sessions

Andy Green andy at warmcat.com
Tue May 24 17:12:36 CEST 2016



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