Forum

Hiawatha version: 6.18
Operating System: FreeBSD

Hi all,
I have just started using Hiawatha. The implementation of most projects was quite easy and it works just great. I love this little server. However, with davical, I have real problems. PHP works fine and I can login into the davical management center. However, it is not possible to open a (dynamically generated) calendar. As soon as I want to open such links as:

caldav.php/c-s/15f3FD3-B230-4921-9EF2-0C36BCEF3FF89234D.ics

Hiawatha protests and gives me a 404 Not Found.

What am I doing wrong?

I don't know davical. I will take a look at it, but that will take some time.

Davical is a nice calendar server and offers a dynamic caldav service using PHP. So, the calendar link posted above will allow a calendar software such as iCal or Sunbird to download and upgrade calendars.
It seems to be that I need to allow hiawatha something like dynamic links. Maybe I can do that via a rewrite rule or something like this.

Thanks for your considerations.

Hiawatha is very good at URL rewriting, so that shouldn't be a problem. Have you read the URL Toolkit HOWTO?

I think I got part of it. It was not an issue with URL rewriting but rather with

EnablePathInfo = yes

missing.
There is now still some authentication issue, but I am closer now :-)

Thanks so far.

You're welcome

Everything now seems to work except for an authentication issue that I could now track down. The problem is that php-fcgi should pass the header AUTHENTICATION to php. How can I do that?

For security reasons, the Authentication header from the HTTP request is not passed on to PHP. No application should ever need that header.

The only thing an application could possibly want to know about a HTTP authentication process is the username, which can be read from the REMOTE_USER environment variable. Any other method is not according to the standards.

Thank you very much for this answer, I'll send it to the developers of davical.

Here the answer of the developer of davical:

"Well, the developers of Hiawatha are presumably not too interested in the use case where the HTTP server does the HTTP parts of the protocol, and the web application does the rest. Perhaps they see that there are security issues with allowing an application to check it's authentication requirement itself, since someone with unauthorised access to the application might be able to gain unauthorised access to the application, or to use those usernames and passwords in other places to break into your bank and steal all your money. Or something.

Hopefully you won't run into further problems with Hiawatha rejecting requests for obscure methods like MKCALENDAR or MOVE which DAViCal needs to be passed through to the application for it to do it's work - along with GET, PUT, MKCOL, OPTIONS, PROPFIND, LOCK, PROPPATCH, UNLOCK and REPORT of course!

A developer of a truly paranoid webserver would of course only let known headers through to the application, so that if a 'Depth' or 'Destination' header came through with the request we can expect that it would be discarded by default, although possibly a configuration might be provided to allow a systems administrator to allow such things to be passed through.

Removing my tongue from my cheek, where it seems to have somehow got stuck for the first few paragraphs of this response, if you want to use DAViCal's internal authentication (the default) then you really will need need to get the password from the webserver so that you can validate that this user really is the user they say that they are.

What external authentication mechanisms does Hiawatha support? Or is it restricted to a list of authenticated users stored in a random file in the filesystem? It's quite possible for DAViCal to operate with external authentication, but there needs to be some kind of synchronisation with the usernames supplied from that external authentication and the various principal data associated with users in DAViCal (displayname, e-mail address, date format, language, membership of groups, privileges granted to and by other users/groups, DAV collections and so forth).

People often use LDAP to supply some of this data, although obviously there is a point where DAViCal's own database needs to become authoritative for some aspects, but the standard LDAP mechanism people typically use for LDAP and DAViCal also does the password validation via the PHP code.

I'm not familiar with the details of the CGI specification, having thankfully never had to restrict myself to it's limitations, and if Hiawatha is a pure play CGI webserver which doesn't support extensions such as the FastCGI 'AUTHORIZATION' value to provide the basic auth header through to an application, then you are probably going to have to write code to be able to use DAViCal with it.

What that code looks like will depend on what constraints Hiawatha's developers have placed on what authentication systems they allow to be used with their HTTP server. If they don't want to let applications do their own authentication then perhaps they support PAM authentication, and it might be possible to hack a PAM module together which did the username/password checking against the DAViCal database. I seem to recall using a pam_pgsql.so a few years ago, which possibly allowed authentication to check whether a particular query succeeded or failed, and I would be happy to work with you to create the magic SQL statement needed to confirm whether a particular username/password combination was correct.

Cheers, Andrew McMillan."

Authentication methods for a webapplication can be devided into two groups: authentication done by the webserver and authentication done by the webbaplication itself.

Authentication done by de webserver is called HTTP authentication. It works via the HTTP header "Authorization". The webserver takes care of password checks. The webapplication doesn't need to know about this process. It's logical that the applications wants to know which user has logged in. That's what the REMOTE_USER environment variable is for. Since the webserver takes care of verifying the password, there is no need for the webapplication to have access to this password and therefor doesn't need access to the HTTP Authorization HTTP header.

Authentication done by the webapplication has nothing to do with the webserver and should there for not conflict with the webserver authentication method. Using the HTTP Authorization header to implement an authentication method for a webapplication is bad design. I'm very sure that it's a common way to do so when designing webapplications for Apache, but despite what many people believe, Apache's way isn't standard.

Hiawatha has support for Basic and Digest HTTP authentication where the passwords are stored locally on disk. If you want any other kind of authentication, it should be build in the webapplication.

Having read the Davilcal's developer respons, I don't think that Davical will work with Hiawatha. No offense, but it looks like Davical was build following Apache's rules, not following the official standards.

Thank you very much for your nice reply. I am very fond with your opinion and will look for a replacement of davical in the near future. I agree that http authorization and web application authorization should not be mixed.