<div dir="ltr">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).</div><br><div class="gmail_quote"><div dir="ltr">On Tue, 24 May 2016 at 11:11 Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 05/23/2016 11:37 PM, Andy Green wrote:<br>
><br>
><br>
> On May 23, 2016 9:14:57 PM GMT+08:00, Colin Adams<br>
> <<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a>> wrote:<br>
>> This sounds like something that I was going to have to write myself<br>
>> for my application (a game server). I can't think offhand of any<br>
>> further improvements, but I might find something when I try it<br>
>> out. My C skills are 17 years rusty (apart from fragments involved<br>
>> in writing language bindings), but I'm sure I can polish them up if<br>
>> I find any enhancements needed. Is this in master now?<br>
><br>
> No, it's very much a WIP.<br>
><br>
> But today it's working for admin login / logout, the cookies,<br>
> persistent session db, rewriting r/o copies of the state into js vars<br>
> (so the example login page js can change to a logout form<br>
> appropriately), and all customization in the lwsws JSON and login<br>
> html (there are hidden form elements that control the next url<br>
> depending on how the login / logout went).<br>
><br>
> I'll tidy it up and add some docs tomorrow, and check if it broke<br>
> anything else, but you can see it's only usable for development<br>
> today.<br>
<br>
I pushed what there is of it... for now it's enabled in cmake with<br>
LWS_WITH_LWSWS.<br>
<br>
See<br>
<br>
<a href="https://github.com/warmcat/libwebsockets/blob/master/README.generic-sessions.md" rel="noreferrer" target="_blank">https://github.com/warmcat/libwebsockets/blob/master/README.generic-sessions.md</a><br>
<br>
You can add the mounts mentioned in there and the protocol import part<br>
to the existing lwsws example config.<br>
<br>
The admin account and password in the protocol config part is admin /<br>
jipdocesExunt<br>
<br>
If you navigate to <a href="http://localhost:7681/lwsgs" rel="noreferrer" target="_blank">http://localhost:7681/lwsgs</a> you should see a login<br>
form that you can login with those credentials, which will take you to a<br>
URL in /lwsgs/needadmin/... that cannot otherwise be served.<br>
<br>
If you go back and refresh the login page, it now knows your session is<br>
authenticated and this time shows your login name together with a logout<br>
button... this is done in JS clientside with the tiny rewrite of<br>
"$lwsgs_user" in the included lwsgs.js.<br>
<br>
The active sessions are stored in sqlite3 on the server side and the<br>
expiry, controlled from the config file, should be respected.<br>
<br>
The actual users will also go in a table in sqlite3, but admin's<br>
credentials are set in the config outside of that.  Those users and<br>
registration aren't done yet.<br>
<br>
> I'm mainly wondering what people want from the persistent user state,<br>
> in my case once authenticated, the next url is an html page opening a<br>
> ws link that will also get the logged-in session cookie.  My<br>
> application is static html + js that dynamically configures itself<br>
> around the returned (user-context aware) JSON from the ws link.<br>
><br>
> Put another way the application's custom ws protocol handler code is<br>
> the guy who actually defines what different users see... that pattern<br>
> removes the need for any other server-side interpreter and just<br>
> manifests itself as delivering an authenticated username into custom<br>
> ws protocol code you would have to write anyway.  Other<br>
> presentation-related code that needs to be aware of authentication<br>
> state (eg, show login form, or "logged in as xxx" + logout button)<br>
> moves out of what would have been server scripts and into js that got<br>
> some rewriting pixie dust.  But I am curious if that pattern is<br>
> enough to solve other peoples' session-related tasks, perhaps with a<br>
> little thought.<br>
<br>
Still curious about opinions on this (maybe it's not explained clearly<br>
enough yet).<br>
<br>
-Andy<br>
<br>
> -Andy<br>
><br>
>> On Mon, 23 May 2016 at 12:44 Andy Green <<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>> wrote:<br>
>><br>
>>> Hi -<br>
>>><br>
>>> I am partway through making a plugin called "generic-sessions",<br>
>> intended<br>
>>> to provide lightweight persistent http sessions without a<br>
>>> server-side interpreter.<br>
>>><br>
>>> The overall ideas are:<br>
>>><br>
>>> - random 20-byte session id managed in a cookie<br>
>>><br>
>>> - all information related to the session held at the server,<br>
>> nothing<br>
>>> managed clientside<br>
>>><br>
>>> - sqlite3 used at the server to manage active sessions and users<br>
>>><br>
>>> - defaults to creating anonymous sessions with no user<br>
>>> associated<br>
>>><br>
>>> - admin account (with user-selectable username) is defined in<br>
>> config<br>
>>> with a SHA-1 of the password; rest of the accounts are in<br>
>>> sqlite3<br>
>>><br>
>>> - login, logout, register account + email verification built-in<br>
>> with<br>
>>> examples<br>
>>><br>
>>> - in a mount, some file suffixes (ie, .js) can be associated with<br>
>>> a protocol for the purposes of rewriting symbolnames.  These are<br>
>> read-only<br>
>>> copies of logged-in server state.<br>
>>><br>
>>> - When your page fetches .js or other rewritten files from that<br>
>> mount,<br>
>>> "$lwsgs_user" and so on are rewritten on the fly using chunked<br>
>> transfer<br>
>>> encoding<br>
>>><br>
>>> - Eliminates server-side scripting with a few rewritten symbols<br>
>>> and javascript on client side<br>
>>><br>
>>> - 32-bit bitfield for authentication sectoring, mounts can<br>
>>> provide<br>
>> a<br>
>>> mask on the loggin-in session's associated server-side bitfield<br>
>>> that must be set for access.<br>
>>><br>
>>> - No code (just config) required for, eg, private URL namespace<br>
>> that<br>
>>> requires login to access.<br>
>>><br>
>>> Login, logout, cookies, rewriting are already done, I am curious<br>
>> about<br>
>>> any comments or suggestions to make it more useful (especially<br>
>>> if<br>
>> anyone<br>
>>> is motivated to contribute).<br>
>>><br>
>>> -Andy _______________________________________________<br>
>>> Libwebsockets mailing list <a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a><br>
>>> <a href="http://libwebsockets.org/mailman/listinfo/libwebsockets" rel="noreferrer" target="_blank">http://libwebsockets.org/mailman/listinfo/libwebsockets</a><br>
>>><br>
><br>
> _______________________________________________ Libwebsockets mailing<br>
> list <a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a><br>
> <a href="http://libwebsockets.org/mailman/listinfo/libwebsockets" rel="noreferrer" target="_blank">http://libwebsockets.org/mailman/listinfo/libwebsockets</a><br>
><br>
</blockquote></div>