[Libwebsockets] RFC: lightweight sessions

Andy Green andy at warmcat.com
Mon May 23 17:37:16 CEST 2016



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

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




More information about the Libwebsockets mailing list