<div dir="ltr">Confirmed that it acquired the apache id:<div><br></div><div><div>ps -U root -u apache u | grep lwsws</div><div>apache   10599  0.0  0.0  70032  6108 ?        Ss   16:25   0:00 /usr/local/bin/lwsws -D</div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 24 May 2016 at 16:16 Colin Adams <<a href="mailto:colinpauladams@gmail.com">colinpauladams@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm just calling<div>sudo /usr/local/bin/lwsws</div><div>so it ought to be running as root</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 24 May 2016 at 16:13 Andy Green <<a href="mailto:andy@warmcat.com" target="_blank">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 May 24, 2016 11:10:32 PM GMT+08:00, Colin Adams <<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a>> wrote:<br>
>OK. I've got it installed.<br>
><br>
>But when running I get messages:<br>
><br>
>lwsws[10192]: Unable to open session db /var/www/sessions/lws.sqlite3:<br>
>unable to open database file<br>
><br>
>I don't know anything about sqlite3, but I'm guessing perhaps I need to<br>
>define a user name first? Or is there something missing from the readme<br>
>(I<br>
>issued the two commands to create the directory and set the owner to<br>
>root.apache).<br>
<br>
Are you starting it as root?  Otherwise it doesn't have the rights to change to run under apache uid.<br>
<br>
-Andy<br>
<br>
>On Tue, 24 May 2016 at 15:38 Andy Green <<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>> wrote:<br>
><br>
>><br>
>><br>
>> On 05/24/2016 09:06 PM, Colin Adams wrote:<br>
>> > I did:<br>
>> > git pull<br>
>> > cd build<br>
>> > make<br>
>> > sudo make install<br>
>> ><br>
>> > and got:<br>
>> > CMake Error at cmake_install.cmake:427 (file):<br>
>> > file INSTALL cannot find<br>
>"/home/colin/libwebsockets/plugins/lwsgs.js".<br>
>> ><br>
>> > I had previously done:<br>
>> ><br>
>> > cmake -D LWS_WITHOUT_DAEMONIZE=OFF -D LWS_WITH_PLUGINS=ON<br>
>> > -DLWS_WITH_LWSWS=1 ..<br>
>> ><br>
>> > so is there anything else I should have done?<br>
>><br>
>> No it's my fault, I missed it from git add.  Please fetch (not pull)<br>
>> master again.<br>
>><br>
>> Because master doesn't have a history, you need to track it like<br>
>this,<br>
>> assuming you have no local patches<br>
>><br>
>> $ git fetch <a href="https://github.com/warmcat/libwebsockets.git" rel="noreferrer" target="_blank">https://github.com/warmcat/libwebsockets.git</a> +master:m &&<br>
>> git reset --hard m<br>
>><br>
>> -Andy<br>
>><br>
>> ><br>
>> > On Tue, 24 May 2016 at 11:26 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/24/2016 06:15 PM, Colin Adams wrote:<br>
>> >      > My opinion is that I personally will not need anything<br>
>beyond<br>
>> >     what you<br>
>> >      > have already described (but I am assuming that the email<br>
>address<br>
>> that<br>
>> >      > the user used for registration is available in the DB. And<br>
>maybe<br>
>> that<br>
>> >      > assumption is wrong).<br>
>> ><br>
>> >     It will be... you can see the schema here<br>
>> ><br>
>> ><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<br>
>deals<br>
>> with<br>
>> >     authentication of a username.  That includes registration,<br>
>email<br>
>> >     confirmation, "forgot password", eventually admin maintenance<br>
>pages,<br>
>> >     managing the sesion database and so on, but NO other<br>
>information<br>
>> except<br>
>> >     the client has a cookie authenticated for a given username (or<br>
>no<br>
>> >     username if not logged in).<br>
>> ><br>
>> >     So the api to this in your ws protocol handler would only be<br>
>"what's<br>
>> 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<br>
>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<br>
>user, eg,<br>
>> >     using the username as the db key, is completely a separate<br>
>issue<br>
>> private<br>
>> >     to your protocol handler.  It would, eg, use its own sqlite3<br>
>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>><br>
>> >      > <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a> <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><br>
>> >     <mailto:<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a>><br>
><mailto:<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a><br>
>> >     <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<br>
>to<br>
>> >     write myself<br>
>> >      >      >> for my application (a game server). I can't think<br>
>offhand<br>
>> >     of any<br>
>> >      >      >> further improvements, but I might find something<br>
>when I<br>
>> >     try it<br>
>> >      >      >> out. My C skills are 17 years rusty (apart from<br>
>fragments<br>
>> >     involved<br>
>> >      >      >> in writing language bindings), but I'm sure I can<br>
>polish<br>
>> >     them up if<br>
>> >      >      >> I find any enhancements needed. Is this in master<br>
>now?<br>
>> >      >      ><br>
>> >      >      > No, it's very much a WIP.<br>
>> >      >      ><br>
>> >      >      > But today it's working for admin login / logout, the<br>
>> cookies,<br>
>> >      >      > persistent session db, rewriting r/o copies of the<br>
>state<br>
>> >     into js vars<br>
>> >      >      > (so the example login page js can change to a logout<br>
>form<br>
>> >      >      > appropriately), and all customization in the lwsws<br>
>JSON<br>
>> >     and login<br>
>> >      >      > html (there are hidden form elements that control the<br>
>next<br>
>> url<br>
>> >      >      > depending on how the login / logout went).<br>
>> >      >      ><br>
>> >      >      > I'll tidy it up and add some docs tomorrow, and check<br>
>if<br>
>> >     it broke<br>
>> >      >      > anything else, but you can see it's only usable for<br>
>> >     development<br>
>> >      >      > today.<br>
>> >      ><br>
>> >      >     I pushed what there is of it... for now it's enabled in<br>
>cmake<br>
>> >     with<br>
>> >      >     LWS_WITH_LWSWS.<br>
>> >      ><br>
>> >      >     See<br>
>> >      ><br>
>> >      ><br>
>> ><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<br>
>protocol<br>
>> >     import part<br>
>> >      >     to the existing lwsws example config.<br>
>> >      ><br>
>> >      >     The admin account and password in the protocol config<br>
>part is<br>
>> >     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<br>
>should see<br>
>> >     a login<br>
>> >      >     form that you can login with those credentials, which<br>
>will<br>
>> >     take you to a<br>
>> >      >     URL in /lwsgs/needadmin/... that cannot otherwise be<br>
>served.<br>
>> >      ><br>
>> >      >     If you go back and refresh the login page, it now knows<br>
>your<br>
>> >     session is<br>
>> >      >     authenticated and this time shows your login name<br>
>together<br>
>> >     with a logout<br>
>> >      >     button... this is done in JS clientside with the tiny<br>
>rewrite<br>
>> of<br>
>> >      >     "$lwsgs_user" in the included lwsgs.js.<br>
>> >      ><br>
>> >      >     The active sessions are stored in sqlite3 on the server<br>
>side<br>
>> >     and the<br>
>> >      >     expiry, controlled from the config file, should be<br>
>respected.<br>
>> >      ><br>
>> >      >     The actual users will also go in a table in sqlite3, but<br>
>> admin's<br>
>> >      >     credentials are set in the config outside of that.<br>
>Those<br>
>> >     users and<br>
>> >      >     registration aren't done yet.<br>
>> >      ><br>
>> >      >      > I'm mainly wondering what people want from the<br>
>persistent<br>
>> >     user state,<br>
>> >      >      > in my case once authenticated, the next url is an<br>
>html<br>
>> >     page opening a<br>
>> >      >      > ws link that will also get the logged-in session<br>
>cookie.<br>
>> My<br>
>> >      >      > application is static html + js that dynamically<br>
>> >     configures itself<br>
>> >      >      > around the returned (user-context aware) JSON from<br>
>the ws<br>
>> >     link.<br>
>> >      >      ><br>
>> >      >      > Put another way the application's custom ws protocol<br>
>> >     handler code is<br>
>> >      >      > the guy who actually defines what different users<br>
>see...<br>
>> >     that pattern<br>
>> >      >      > removes the need for any other server-side<br>
>interpreter and<br>
>> >     just<br>
>> >      >      > manifests itself as delivering an authenticated<br>
>username<br>
>> >     into custom<br>
>> >      >      > ws protocol code you would have to write anyway.<br>
>Other<br>
>> >      >      > presentation-related code that needs to be aware of<br>
>> >     authentication<br>
>> >      >      > state (eg, show login form, or "logged in as xxx" +<br>
>logout<br>
>> >     button)<br>
>> >      >      > moves out of what would have been server scripts and<br>
>into<br>
>> >     js that got<br>
>> >      >      > some rewriting pixie dust.  But I am curious if that<br>
>> >     pattern is<br>
>> >      >      > enough to solve other peoples' session-related tasks,<br>
>> >     perhaps with a<br>
>> >      >      > little thought.<br>
>> >      ><br>
>> >      >     Still curious about opinions on this (maybe it's not<br>
>> >     explained clearly<br>
>> >      >     enough yet).<br>
>> >      ><br>
>> >      >     -Andy<br>
>> >      ><br>
>> >      >      > -Andy<br>
>> >      >      ><br>
>> >      >      >> On Mon, 23 May 2016 at 12:44 Andy Green<br>
><<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>><br>
>> >      >     <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a> <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>>>><br>
>wrote:<br>
>> >      >      >><br>
>> >      >      >>> Hi -<br>
>> >      >      >>><br>
>> >      >      >>> I am partway through making a plugin called<br>
>> >     "generic-sessions",<br>
>> >      >      >> intended<br>
>> >      >      >>> to provide lightweight persistent http sessions<br>
>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<br>
>the<br>
>> server,<br>
>> >      >      >> nothing<br>
>> >      >      >>> managed clientside<br>
>> >      >      >>><br>
>> >      >      >>> - sqlite3 used at the server to manage active<br>
>sessions<br>
>> >     and users<br>
>> >      >      >>><br>
>> >      >      >>> - defaults to creating anonymous sessions with no<br>
>user<br>
>> >      >      >>> associated<br>
>> >      >      >>><br>
>> >      >      >>> - admin account (with user-selectable username) is<br>
>> >     defined in<br>
>> >      >      >> config<br>
>> >      >      >>> with a SHA-1 of the password; rest of the accounts<br>
>are in<br>
>> >      >      >>> sqlite3<br>
>> >      >      >>><br>
>> >      >      >>> - login, logout, register account + email<br>
>verification<br>
>> >     built-in<br>
>> >      >      >> with<br>
>> >      >      >>> examples<br>
>> >      >      >>><br>
>> >      >      >>> - in a mount, some file suffixes (ie, .js) can be<br>
>> >     associated with<br>
>> >      >      >>> a protocol for the purposes of rewriting<br>
>symbolnames.<br>
>> >     These are<br>
>> >      >      >> read-only<br>
>> >      >      >>> copies of logged-in server state.<br>
>> >      >      >>><br>
>> >      >      >>> - When your page fetches .js or other rewritten<br>
>files<br>
>> >     from that<br>
>> >      >      >> mount,<br>
>> >      >      >>> "$lwsgs_user" and so on are rewritten on the fly<br>
>using<br>
>> >     chunked<br>
>> >      >      >> transfer<br>
>> >      >      >>> encoding<br>
>> >      >      >>><br>
>> >      >      >>> - Eliminates server-side scripting with a few<br>
>rewritten<br>
>> >     symbols<br>
>> >      >      >>> and javascript on client side<br>
>> >      >      >>><br>
>> >      >      >>> - 32-bit bitfield for authentication sectoring,<br>
>mounts<br>
>> can<br>
>> >      >      >>> provide<br>
>> >      >      >> a<br>
>> >      >      >>> mask on the loggin-in session's associated<br>
>server-side<br>
>> >     bitfield<br>
>> >      >      >>> that must be set for access.<br>
>> >      >      >>><br>
>> >      >      >>> - No code (just config) required for, eg, private<br>
>URL<br>
>> >     namespace<br>
>> >      >      >> that<br>
>> >      >      >>> requires login to access.<br>
>> >      >      >>><br>
>> >      >      >>> Login, logout, cookies, rewriting are already done,<br>
>I am<br>
>> >     curious<br>
>> >      >      >> about<br>
>> >      >      >>> any comments or suggestions to make it more useful<br>
>> >     (especially<br>
>> >      >      >>> if<br>
>> >      >      >> anyone<br>
>> >      >      >>> is motivated to contribute).<br>
>> >      >      >>><br>
>> >      >      >>> -Andy<br>
>_______________________________________________<br>
>> >      >      >>> Libwebsockets mailing list<br>
>> >     <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>
>> >      >     <mailto:<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>
>> >      >      >>><br>
><a href="http://libwebsockets.org/mailman/listinfo/libwebsockets" rel="noreferrer" target="_blank">http://libwebsockets.org/mailman/listinfo/libwebsockets</a><br>
>> >      >      >>><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>
>> >      >     <mailto:<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>
>> >      >      ><br>
><a href="http://libwebsockets.org/mailman/listinfo/libwebsockets" rel="noreferrer" target="_blank">http://libwebsockets.org/mailman/listinfo/libwebsockets</a><br>
>> >      >      ><br>
>> >      ><br>
>> ><br>
>><br>
<br>
</blockquote></div></blockquote></div>