Re: [hackers] [quark] Thoughts on CGI and authentication?
On 10/26/2020 8:41 AM, Laslo Hunhold wrote: Tell me one example where you need CGI which isn't a web forum? To give an example how you can solve something statically: A comment section could be built by having a static web server and also a very thin "handler" that is called when the form is submitted that adds the comment to a database and updates the static data on the fly. The advantage of this is that if someone manages to "crash" the comment-handler or kill the database process or something, the website is not affected. Funny, that's my current use case. All my CGI is through forms, so I'm currently running a separate server for the form handlers, regenerating the HTML and then redirecting to the recently updated page through a "303 See Other" code. My motivation behind integrating CGI into quark was leveraging the quality of its implementation to avoid the security pitfalls of badly-written HTTP servers out there. I would only have to worry about writing a simple script to handle the form data. Also, if CGI was integrated into the web server itself, I could use the same domain/port/endpoint to serve the static page (via a GET request) and to handle the form (via a POST request). Moot point but it goes a long way towards usability. Finally, CGI is often used to customize the content of a page for a given user. Imagine a logged in user in a forum: they must see a link that points to their profile. Anonymous users would see a login/signup bar instead. I must say that, even with these advantages in mind, I've come to think that CGI would not be appropriate for quark. Its goals are at odds with the needs of a CGI implementation, and that's fine (there are alternatives for those who want CGI). Feel free to prove me wrong :) Best regards, José Miguel
Re: [hackers] [quark][PATCH] Don't erase response on http_send_error_response
On Mon, 26 Oct 2020 11:34:17 +0100 José Miguel Sánchez García wrote: Dear José, > > I also don't see a reason for the constraints you mention. Just add > > an array of group-auth-pairs to the server struct and also add a > > group-auth-pair to the req-struct that you then fill when you parse > > the request fields in http_parse_header(). Then later, in > > http_prepare_header_buf(), you check if they match and either send > > an error-header (access denied) or allow access. > > > > In case the auth-field is empty but the file requires a password, > > you, in turn, send the desired header to ask for auth. > > You are absolutely right, and I just didn't see it when I was working > on it. Sorry for wasting your time. no problem! Sometimes it takes a few refactorings of an idea until it is implemented the best way. With best regards Laslo
Re: [hackers] [quark][PATCH] Don't erase response on http_send_error_response
On 10/26/2020 8:34 AM, Laslo Hunhold wrote: Definitely don't make exceptions here, because erasing the entire struct is a consistency measure and being inconsistent there complicates the semantics. I'll be careful then. I also don't see a reason for the constraints you mention. Just add an array of group-auth-pairs to the server struct and also add a group-auth-pair to the req-struct that you then fill when you parse the request fields in http_parse_header(). Then later, in http_prepare_header_buf(), you check if they match and either send an error-header (access denied) or allow access. In case the auth-field is empty but the file requires a password, you, in turn, send the desired header to ask for auth. You are absolutely right, and I just didn't see it when I was working on it. Sorry for wasting your time. Best regards, José Miguel
Re: [hackers] [quark] Thoughts on CGI and authentication?
On Sun, 25 Oct 2020 18:00:30 +0300 Platon Ryzhikov wrote: Dear Platon, > I've recently had an idea that instead of adding support for running > scripts by HTTP server (which in any case leads to new fork() calls) > one could use a library providing HTTP server itself while all the > logic is created separately and is performed using callbacks from > library main loop. In that case one could attempt to handle dynamic > (and static using proper callbacks) content within fixed number of > threads. there is theoretically no limit to that, but IPC is a difficult thing here given you are within a chroot. One could think of another Unix-domain socket (besides the one that would be created with the -U option) that could be used to "send" and "receive" data, but to be honest, it really is not withing quark's scope. Tell me one example where you need CGI which isn't a web forum? To give an example how you can solve something statically: A comment section could be built by having a static web server and also a very thin "handler" that is called when the form is submitted that adds the comment to a database and updates the static data on the fly. The advantage of this is that if someone manages to "crash" the comment-handler or kill the database process or something, the website is not affected. Still, maybe I'm missing something here. Please let me know what you need CGI for! With best regards Laslo
Re: [hackers] [quark][PATCH] Don't erase response on http_send_error_response
On Sun, 25 Oct 2020 11:04:26 +0100 José Miguel Sánchez García wrote: Dear José, > I'm currently relying on the req struct NOT being erased, because I'm > storing the realm the file belongs to there. Then, I'm using that > realm information to build the WWW-Authenticate header for the 401 > error response. > > I could just save that field before erasing everything else, but I > wonder if that's the way to go. If you are getting rid of everything, > maybe I shouldn't make exceptions? Definitely don't make exceptions here, because erasing the entire struct is a consistency measure and being inconsistent there complicates the semantics. I also don't see a reason for the constraints you mention. Just add an array of group-auth-pairs to the server struct and also add a group-auth-pair to the req-struct that you then fill when you parse the request fields in http_parse_header(). Then later, in http_prepare_header_buf(), you check if they match and either send an error-header (access denied) or allow access. In case the auth-field is empty but the file requires a password, you, in turn, send the desired header to ask for auth. With best regards Laslo
