[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [patch #9576] Adding authorization cookie management

From: Giuseppe Modugno
Subject: [lwip-devel] [patch #9576] Adding authorization cookie management
Date: Thu, 1 Mar 2018 06:08:39 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

Follow-up Comment #6, patch #9576 (project lwip):

> However, I'd rather give the httpd the opportunity to add user-defined
header lines using some callback. Like that, the change to httpd is minimal
and better reusable. Authentication could then be added externally. 
Simon, if you give me more details, I can try to change my patch.

Consider that authentication cookie could be needed in several parts of HTTP
request processing.
* At file opening. This is why I call an external callback named
httpd_authorized_for_uri(). Here the application tells httpd to continue
opening the file requested or another file (login form). Another solution
could be to change fs_open() (and fs_custom_open() too) to add auth cookie
among parameters. However I decided to not change many core parts of httpd
* During CGI processing. Here I changed httpd_cgi_handler() to include auth
cookie among parameters.
* Maybe during SSI processing, but I'm not familiar with SSI implementation in

I don't think a simple handler to call when a user specified HTTP header is
found in the request could solve the authentication issue. Mostly if you don't
have the possibility to save a context in the handler and compare it in
fs_open() and httpd_cgi_handler().

I think there are many data in the HTTP request that could be useful during
file opening and CGI processing (external to httpd). As well as the auth
cookie, there are some other headers such as User-Agent. I know struct
http_state is an opaque structure that is better to keep private in httpd, but
we could add a "public" structure (included in http_state) that can be passed
as an argument.
This http_req structure should contain HTTP request info and all other data
that external functions can be used to answer to the request:
* interesting headers (Auth, User-Agent, ...) fine tuned with macros;
* pointer to struct fs_file (that is already passed to
* pcb, why not (I'm not sure if it's possible to deduce the original IP
address of the request and this could be useful);
* query string;
* *additional* headers to add in the reply;
* ...

IMHO this would simplify API and processing of generic requests. For example,
with this "public" and "shared" http_req structure, you need to only enable
detection of "Cookie: Auth" header by macro and fs_open_custom() could
automatically points to "/login.html" instead of "/index.html" , if the auth
cookie is absent or not valid.

int fs_open_custom(struct http_req *req, const char *filename) {
  const char *auth_cookie = req->req_headers[HTTPD_MYHEADER_AUTH_COOKIE];
  const struct fsdata_file *f;
  struct fs_file *file = req->file;

  if (auth_is_valid(auth_cookie)) {
    f = fs_search(filename);
  } else {
    f = fs_search("/login.html");

  if (f != NULL) {
    req->file->data = (const char *)f->data;
    req->file->len = f->len;
    req->file->index = f->len;
    req->file->pextension = NULL;
    req->file->flags = f->flags;
    req->file->chksum_count = f->chksum_count;
    req->file->chksum = f->chksum;
    req->file->state = fs_state_init(file, name);
#endif /* #if LWIP_HTTPD_FILE_STATE */
    return ERR_OK;
  } else {
    return ERR_VAL;  // File not found


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]