[Libwebsockets] RFC: lightweight sessions

Andy Green andy at warmcat.com
Tue May 24 12:11:10 CEST 2016



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> 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> 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
>>> http://libwebsockets.org/mailman/listinfo/libwebsockets
>>>
>
> _______________________________________________ Libwebsockets mailing
> list Libwebsockets at ml.libwebsockets.org
> http://libwebsockets.org/mailman/listinfo/libwebsockets
>



More information about the Libwebsockets mailing list