Lighttpd

I agree, this support would be excellent, especially if {{{mod@mod_accesslog@ allowed you to print these environment variables in your access log. For example, the most common use case for an authorizer FastCGI process is when you want to set the REMOTE_USER cgi environment variable, and most people will want to log the contents of that environment variable.

If you download and apply the attached fastcgi-authorizer-fixes.diff file, both #321 and #322 will be fixed (as well as a fix for infinite 301 redirection when specifying "/" as your authorizer).

This is excellent news. When can this be applied to the main trunk?

-- André Cruz

I think that with this patch we still have to opt between serving static content or another fcgi application, by configuring or not a docroot.

Why can't we serve both? If I protect the / URL with an authorizer I want to serve static content, the site CSS, and process the PHP files using a fcgi application.

I enabled this by setting con->status = 0 on line 3114 of mod_fastcgi.c (after the patch). This way mod_staticfile catches the request.

Is there something I am forgetting with this small change?

Replying to EDevil:

I think that with this patch we still have to opt between serving static content or
another fcgi application, by configuring or not a docroot.

This should not be the case. I've used this patch successfully for many months to serve static content, cgi content, and fastcgi content "behind" a fastcgi authorizer.

Why can't we serve both? If I protect the / URL with an authorizer I want to serve
static content, the site CSS, and process the PHP files using a fcgi application.

I enabled this by setting con->status = 0 on line 3114 of mod_fastcgi.c (after the
patch). This way mod_staticfile catches the request.

The connection struct (typedef struct defined in base.h) does not have a status field. It does have an http_status field. Perhaps you tried to apply the patch against an older version of lighttpd? I've applied the patch against svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x/.

Is there something I am forgetting with this small change?

FYI, this patch does not apply cleanly since 1.4.15. It's about time this patch is integrated.

You're right, it's http_status.

It ends up like this:

                             con->http_status == 0)) {
                                /*
                                 * If we are here in AUTHORIZER mode then a request for autorizer
                                 * was proceeded already, and status 200 has been returned. We need
                                 * now to handle autorized request.
                                 */
                                con->http_status = 0;
                                if ( ! buffer_is_empty(host->docroot) ) {
                                        /*
                                         * Serve local file if they specified
                                         * a docroot
                                         */

An enhancement with severity "blocker"? you are funny...

I think we shouldn't use con->authed_user to decide if we should do a authorizer request - that would mean every authorizer behind mod_auth gets broken, which is not acceptable imho.

This bug has a patch available. It is attached.

I have tried to patch a more recent version but it seems authorizer does not work for FastCGI URL prefix based content. Could somebody provide an example of configuration for using FastCGI in both authorizer and responder for URL prefix? Could somebody provide an updated patch?

Sorry for the late response, didn't watched this issue until now.

gstrauss wrote:

@ckreutzer: this patch purportedly combines three different issues. Besides the feature for setting Variable-* in the environment, are the other two still valid? Please review the commits in the past few months which improve robustness of fastcgi in lighttpd. My read of the patch looks like it extends FastCGI authorizer mode to send static file (if authorized) if host->docroot is set (which is the current behavior), or else (if host->docroot is not set), create a new behavior which sets an environment variable and restarts request processing so that any module can handle the subsequent request, such as mod_cgi.

That's correct. I added the decision on host->docroot to not totally reverse the original lighty way of handling.

• as you pointed out, this handles #322
• #321 is also handled - as you pointed out -, because the request handling will be restarted and the fastcgi responder jumps in (in my case PHP)
• "(as well as a fix for infinite 301 redirection when specifying "/" as your authorizer)" - this should be fixed, too, I use it like this: "/" => (( [...] "mode" => "authorizer" )),

To apply to current master, the patch needs to be updated to at least

I would be happy if this could be contributed upstream!

@ckreutzer: Would you be interested in explaining what the patch is trying to accomplish and to help redo the patch? Thanks.

I will try to help. C is not my day to day job and I just digged into the lighty sources for this issue ;)
My objective was to use the Shibboleth SP as FastCGI Authorizer in front of a PHP FastCGI responder (like a lot of people here, I like it much more than Apache). I used a lot of code from EDevil's patch and just tried to mangle it in the much reworked fastcgi code. Things he did which weren't working any longer I just rewrote with workarounds I found screening the existing code.

I will review the changes between 1.4.39 and 1.4.40 in the next few days, I hope, and try to come up with a clean solution.

Great to hear back!

I haven't looked at this patch in a while, but recently made a commit to mod_cgi to enable internal redirect from a subrequest handler. Take a look at 8861c2bb for some inspiration. :)

I started working on it yesterday and created a modified fastcgi-auth.conf and corresponding fcgi-auth.c, fcgi-responder.c, so I can check the results.

gstrauss wrote:

I haven't looked at this patch in a while, but recently made a commit to mod_cgi to enable internal redirect from a subrequest handler. Take a look at 8861c2bb for some inspiration. :)

Do I understand correctly that if cgi_handle_fdevent(server *srv, void *ctx, int revents) returns HANDLER_COMEBACK, the request will be restarted? Like it was done in the patch before using something like:
+ fcgi_connection_close(srv, hctx);
+ con->mode = DIRECT;
+ con->file_started = 0;
+ con->file_finished = 0;
+ buffer_reset(con->physical.path);
Then it should be possible to use the same behavior in fcgi_handle_fdevent?

I need to study the old patch and the new mod_fastcgi.c more closely in the evening.

Yes. It sounds like you're on the right track. The handler needs to fully clean up if the request is to be restarted, since a new handler might be used, or a new fastcgi handler might be used.

Hi,

I opened a PR on GitHub: https://github.com/lighttpd/lighttpd1.4/pull/70

If there are any improvements needed, feel free to comment in the diffs :)

Regards,
Christoph

sorry, I haven't had a chance to dive into this again. I'll try to do so the weekend of Sep 10.

No problem, take your time. Looking forward to your feedback ;)