On 2003.11.02, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote: > > Consider this: when you want to process binary data, you go to Tcl > alone? Well, not really. Instead, you use C (or similar). But why? > Tcl can handle binary data. There is nothing you can't do binary-wise > with Tcl. It is just so clumsy and ineffective that nobody seriously > uses this, apart from some very simple cases. Now, would you consider > Tcl having a limitation in handling binary data? Well, *strictly* > speaking not, but *practically* speaking, yes.
Poor example. Personally, I find Tcl 8 handles binary data just fine. But, in theory, your point is made: even if something is possible, it may not be practical. > This is the same here. Although you can do virtually anything in > AOLserver by overriding all default processing using some Tcl filters, > it just does not always make sense for the practical use. Again, I understand your theory, but for this actual case we're discussing, implementing Digest authentication using trace filters, IMHO, is perfectly reasonable and a very practical way of doing it. > On Apache, I'd use mod_digest, attach in on the places I need and I'm > running. What about AS? If I were to use "mod_digest" like thingy, or > any other alternative standard method, what should I do? Okay, I propose a new module called "nsauth". The next two weeks (ending 11/14) will be the requirements elicitation period. Everyone who has a REAL need for this module, please speak up now. I want specific use cases describing why you actually NEED a module to implement HTTP authentication other than Basic auth, and exactly and only what you need this nsauth module to do or implement in order for you to use it. If people actually DO produce these use cases and describe specific functionality they will actually use, I'll commit to actually implementing something. It's a bit of give and take: the community gives good, unambiguous and worthwhile requirements, and I'll give some of my personal time to implement it. > > AOLserver has few design flaws. It does, however, not very feature > > complete. Given my choice, I much prefer something that does a few > > things exceptionally well than something that does everything but > > poorly or as a conglomeration of hacks. > > This is the good point: "conglomeration of hacks". This is exactly what > we need to avoid by identifying what people need or might need in the > future and *open* the desing so that it allows for expansion. > This is for sure the case for the database layer, for example. It allows > you to snap-in database engine you like. > This is perhaps not the case with AS 4.0 socket processing since it's > http-protocol bound. > This is definitely not the case with AOLserver authentication. It is > hard-wired in C for doing only Basic method, without a clean > interface to implement (and integrate with the rest of the system) > other XYZ methods, when (if) they come along the road. Before we continue this thought, lets step back a second. Is AOLserver a general purpose, multi-threaded daemon with a Tcl interpreter that just /coincidentally/ happens to come standard with an HTTP request processor ... or is AOLserver a specialized application built specifically for the fast delivery of dynamic web pages, using a multi-threaded Tcl page generation engine? I hope you'll agree that the latter is true, and not the former. In that case, think about the 95% case for AOLserver -- serving an HTTP request with NO authentication. In this scenario, supporting N different DB drivers through a pluggable DB API doesn't directly affect performance -- supporting one vs. many, that is. Tuning the socket processing to specifically handling HTTP requests make sense: we're a HTTP request processor, why should we handle any other kind of requests? Authentication being hard-wired in C and very lightweight (only supporting Basic auth) makes sense, because authentication checks could potentially have to be performed for EVERY single HTTP request -- if it weren't lightweight and wired in C, there could be risk of performance loss at the auth layer. > > Is there really that much demand for Digest authentication? Other > > than non-SSL WebDAV, what else actually implements Digest auth as a > > requirement? > > Security. If you're using SSL, you don't need Digest auth for most applications. And, if you're using non-SSL HTTP connections, Digest auth isn't giving you much security. It's giving you authentication without transmitting the shared-secret in the clear, but it's giving you no encryption and doesn't prevent man-in-the-middle attacks. It's hardly security. Let me restate the question a little clearer: other than non-SSL WebDAV, what specific /application/ uses Digest auth as a must-have requirement? > The Basic authentication is acceptable for Intranet uses. Going to > Internet and having passwords transmitted in a clear text form is not > a very good thing, I'd say. This is what the RFC states very clearly, > encouraging people to move from the basic authentication, if possible. > Is this a good reason for you? Not really. This is the /web/ for crying out loud. Basic vs. Digest authentication is for /authentication/, not security. If your requirement is strong authentication, use SSL client certificates. Otherwise, your authentication requirements aren't worth worrying about, in which case, let folks use Basic auth and send their passwords in the clear. If you have sensitive materials that you're restricting access to, then using non-SSL HTTP means a non-authorized user could simply snoop the session of someone who has authenticated and gain access to whatever materials that other user has access to, by listening in. Authentication is not the same as encryption. > Bottom line (for me): If people are happy with tossing in a custom > Tcl layer atop of AS everytime they need to overcome some internal > "limitations", this is ok for me. But this is bad for the AS itself. Come on, now. You're just being antagonistic, now. This is like saying, "If folks feel they need to run ACS or OpenACS to get more functionality than comes stock with the AOLserver distribution, this is bad for AOLserver." AOLserver is just fine the way it is. The problem, as I mentioned before, is that AOLserver isn't feature-complete yet. However, that's not a problem that AOLserver itself must solve. I'd say PHP is pretty far from being feature-complete, but it's a lot further along. Why? Because the PHP community has mounds of freely distributed code out there that people can rape-and-paste right into their own applications. What I'm hearing from this email thread is not "AOLserver needs Digest auth" but "AOLserver needs a repository of reusable code so projects built using AOLserver can get a jump-start without having to re-implement lots of things over and over again." A lot of us on this mailing list have our own personal repositories of code that we make publically available and share, but that makes it harder for newbies and oldbies since there's no centrallized mechanism for pubilshing pointers to all these repositories. I think this is a real problem that the AOLserver community has that is worth solving. But, I could be wrong ... -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
