<div dir="ltr">I did:<div>git pull</div><div>cd build</div><div>make</div><div>sudo make install</div><div><br></div><div>and got: </div><div>CMake Error at cmake_install.cmake:427 (file):</div><div>file INSTALL cannot find "/home/colin/libwebsockets/plugins/lwsgs.js".</div><div><br></div><div>I had previously done:</div><div><br></div><div><span style="color:rgb(51,51,51);font-family:'helvetica neue',helvetica,'segoe ui',arial,freesans,sans-serif,'apple color emoji','segoe ui emoji','segoe ui symbol';font-size:16px;line-height:25.6px">cmake -D LWS_WITHOUT_DAEMONIZE=OFF -D LWS_WITH_PLUGINS=ON -DLWS_WITH_LWSWS=1 ..</span><br></div><div><br></div><div>so is there anything else I should have done?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 24 May 2016 at 11:26 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/24/2016 06:15 PM, Colin Adams wrote:<br>
> My opinion is that I personally will not need anything beyond what you<br>
> have already described (but I am assuming that the email address that<br>
> the user used for registration is available in the DB. And maybe that<br>
> assumption is wrong).<br>
<br>
It will be... you can see the schema here<br>
<br>
<a href="https://github.com/warmcat/libwebsockets/blob/master/plugins/protocol_generic_sessions.c#L522" rel="noreferrer" target="_blank">https://github.com/warmcat/libwebsockets/blob/master/plugins/protocol_generic_sessions.c#L522</a><br>
<br>
but the register / email part is not wired up yet.<br>
<br>
Currently I am imagining this "generic-sessions" plugin only deals with<br>
authentication of a username.  That includes registration, email<br>
confirmation, "forgot password", eventually admin maintenance pages,<br>
managing the sesion database and so on, but NO other information except<br>
the client has a cookie authenticated for a given username (or no<br>
username if not logged in).<br>
<br>
So the api to this in your ws protocol handler would only be "what's my<br>
username".  If it gives you a username, you know it has been<br>
authenticated.  You can also segregate access to mounts by if you're<br>
logged in, or logged in as admin, but that's it.<br>
<br>
Storing stuff that your protocol handler deals in for that user, eg,<br>
using the username as the db key, is completely a separate issue private<br>
to your protocol handler.  It would, eg, use its own sqlite3 database<br>
for it if that's what he wanted to do.<br>
<br>
-Andy<br>
<br>
<br>
> On Tue, 24 May 2016 at 11:11 Andy Green <<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a><br>
> <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>>> wrote:<br>
><br>
><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> <mailto:<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><br>
>     <mailto:<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>
>     <mailto:<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>
>     <mailto:<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>
</blockquote></div>