Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
As for implementing digest in AOLserver Rob Mayoff has already done the MD5 proc in his utils package here: Its also available in the nsencrypt, nspasswd (C based) modules and in pure Tcl in tcllib (along with many other goodies) Tim -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Tuesday 04 November 2003 03:37, you wrote: On 2003.11.03, Zoran Vasiljevic [EMAIL PROTECTED] wrote: I think there is a need for a better solution. Is this what you are willing to discuss? Yes and no. What I'm willing to discuss is if there is a need for /a/ solution. Then, we can talk about better ones ... This very thread is the proof that there is need for this, or? Is this a good enough for you? Besides, I'm not that phylosophical about the matter. I see this really pragmatically: AS has some internal limitations (or call this like you'd like) which can be trivially rectified. If we have to discuss this triviality *that long*, than I'm really afraid what would happen if some major change should be discussed? We'd be totally paralized and would just run in circles, with time passing by... This is a highly sensitive matter and could bring to a show-stop for an open source project. This project has already experienced a fork, but thanks to some nice people at AOL, everything is in place for some time again. BTW, I'm also in the Tcl development group. If we were to discuss all minor changes that *much* and that *long* we'd be still sitting on Tcl 7.4. Digest auth or not, if we can bring AS to be more versatile with *minimal* effort, what not doing this? I really do not undersand the point of this thread any more. Zoran -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On 2003.11.04, Zoran Vasiljevic [EMAIL PROTECTED] wrote: This very thread is the proof that there is need for this, or? Is this a good enough for you? Necessity is the mother of invention. Proof that there is need for this would be that someone has already implemented it, regardless of whether they make their implementation publically available. Having discussion threads about feature requests isn't proof that the features are necessary. :-) Digest auth or not, if we can bring AS to be more versatile with *minimal* effort, what not doing this? I personally don't want to see AOLserver become a collection trivial to implement features that a small subset of the user community wants and/or needs. If someone has the spare time to make the change Jim suggested and do all the necessary regression testing to ensure that normal request processing isn't broken by the change ... maybe their time would be better spent improving the DB API or something that's more generally useful to the majority of AOLserver users? I really do not undersand the point of this thread any more. I'm not sure there was a point in the first place. As you pointed out, this very same discussion happened nearly two years ago, and we still have nothing more than Basic auth. and the community as a whole seems to have survived without much complaint. Perhaps that's a sign ... -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Tuesday 04 November 2003 13:41, you wrote: I personally don't want to see AOLserver become a collection trivial to implement features that a small subset of the user community wants and/or needs. I have no problem with that. This is also my view on the matter. Although I would not consider this topic to be of use for a small subset of the user community. I might be wrong, though... But, why don't we simply change this boring and fruitless discussion to something more constructive? I have proposed a TIP-like mechanism some time ago. Why not follow the successful Tcl way of handling such issues, instead of wasting people's time and list-bandwidth like in this (or perhaps future) case? People write TIP's. Core team decides what/what-not. Simple as that. More constructive, more formal and with an audit trail, so nothing is lost. Works fine in Tcl. We can borrow the TIP implementation from the friendly Tcl project. I'm sure they will have no problem with that. Now, what do you say about that? Zoran -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On 2003.11.04, Zoran Vasiljevic [EMAIL PROTECTED] wrote: People write TIP's. Core team decides what/what-not. Simple as that. [...] Now, what do you say about that? Sure, of course it's a good idea. The person(s) who most want to see Digest auth can bear the burden of writing the AIP for it. :-) -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Tuesday 04 November 2003 15:07, you wrote: On 2003.11.04, Zoran Vasiljevic [EMAIL PROTECTED] wrote: People write TIP's. Core team decides what/what-not. Simple as that. [...] Now, what do you say about that? Sure, of course it's a good idea. The person(s) who most want to see Digest auth can bear the burden of writing the AIP for it. :-) Oh boy, I'm glad we're (finally) becoming more constructive! I must add to this that the AIP (= AOLserver Improvement Proposal) should address the *general* plugin interface of AOLserver, more specifically the interface used to hook-up alternate authorization methods when/if they come along the road. The Jim's fine idea can serve as the starting point. This is not the only part, though... I think there is a patch from Joshua Ginsberg [EMAIL PROTECTED] to allow for some more info for module developers about the state of the http connection, right? And there is a proposal from Vlad Seryakov [EMAIL PROTECTED] to decouple http processing in order to make AS more general vehicle for writing non-http-related services. And, I'm sure there are *lots* of other ideas for which there should be an AIP to vote for/aginst, as well. If nobody objects Because nothing comes for free and the best way to start something is to pull up the sleeves and make it happen (with the hope that others will follow) I will try to arrange that TIP-tracking infrastructure gets somehow installed on the AOLserver website. No idea how am I going to do this but I will try... Zoran -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
How about APE (AOLserver Proposed Enhancement)? :-) Seriously though, this is a great idea to help us better collect, review, and implement a lot of the great ideas being generated in the Community. - Nathan Zoran Vasiljevic wrote on 11/4/03, 9:29 AM: I must add to this that the AIP (= AOLserver Improvement Proposal) should address the *general* plugin interface of AOLserver, more specifically the interface used to hook-up alternate authorization methods when/if they come along the road. The Jim's fine idea can serve as the starting point. -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Tuesday 04 November 2003 16:33, you wrote: How about APE (AOLserver Proposed Enhancement)? :-) Seriously though, this is a great idea to help us better collect, review, and implement a lot of the great ideas being generated in the Community. Whatever the name, what I'd like to know is how the www.aolserver.com is working to be able to fit-in the TIP-tracker once I get it from Tcl people. Who is attending the site? Whom should I bug? Zoran -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
We're working on moving www.aolserver.com to one of our own servers again, which would be obviously an AOLserver. Once the move is completed, should be trivial to setup the TIP code there. - Nathan Zoran Vasiljevic wrote on 11/4/03, 10:32 AM: Whatever the name, what I'd like to know is how the www.aolserver.com is working to be able to fit-in the TIP-tracker once I get it from Tcl people. Who is attending the site? Whom should I bug? Zoran -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
Once you've done this it would be nice if www.aolserver.com became an 'example' site for new users. The code, config, adp pages, etc. etc. should be accessible in CVS. This could demonstrate good practice usage of the core AOLserver features, perhaps some of the more commonly used modules, and perhaps some ideas on how AOL goes about scaling AOLserver up to support the high levels of traffic it can handle. AOL must have a whole raft of monitoring, debugging, performance analysis tools for AOLserver. It would be nice if some of these made their way into the public domain too! ;-) Tim -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] Behalf Of Nathan Folkman Sent: Tuesday, November 04, 2003 3:46 PM To: [EMAIL PROTECTED] Subject: Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command We're working on moving www.aolserver.com to one of our own servers again, which would be obviously an AOLserver. Once the move is completed, should be trivial to setup the TIP code there. - Nathan Zoran Vasiljevic wrote on 11/4/03, 10:32 AM: Whatever the name, what I'd like to know is how the www.aolserver.com is working to be able to fit-in the TIP-tracker once I get it from Tcl people. Who is attending the site? Whom should I bug? Zoran -- 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. -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
Good ideas, and things we've talked about in the past. There's a new version of the AOLserver statistics Web interface for 4.0 being finished that will be released soon as well. - Nathan Tim Moss wrote on 11/4/03, 11:51 AM: Once you've done this it would be nice if www.aolserver.com became an 'example' site for new users. The code, config, adp pages, etc. etc. should be accessible in CVS. This could demonstrate good practice usage of the core AOLserver features, perhaps some of the more commonly used modules, and perhaps some ideas on how AOL goes about scaling AOLserver up to support the high levels of traffic it can handle. AOL must have a whole raft of monitoring, debugging, performance analysis tools for AOLserver. It would be nice if some of these made their way into the public domain too! ;-) Tim -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Mon, 2003-11-03 at 19:09, Tim Moss wrote: There's a number of modules out there that are in varying states of release - I've lost count of how many pure Tcl, pure C or hybrid session management modules I found, before deciding to refactor the OpenACS version. I too have written my own session management through filters and I would think a large number of developers have. For my sins I also have to develop sites in JBoss/Tomcat and one thing that is noticeable is that Tomcat has session management built in with authentication (through simple password files, db tables or LDAP) and authorisation through roles. These features are missing from the AOLserver API and I find that a bit strange given that its an application server and there can be very few applications which don't require some form of session, authentication and authorisation. Having said that, writing the session filter was one of the most enjoyable bits of coding I've done in a while so perhaps I shouldn't complain although I possibly need to get out more. Steve Steve Manning - Linux Mandrake 9.0 - Gnome 2.0 East Goscote - Leicester - UK +44 (0)116 260 5457 E-Mail: [EMAIL PROTECTED] - Web: www.festinalente.co.uk AIM: verbomania - Public Key: 25665CAF from: wwwkeys.pgp.net There are only 10 types of people in this world Those who understand binary and those who don't -- 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. attachment: smiley-3.png
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
This very thread is the proof that there is need for this, or? Is this a good enough for you? Necessity is the mother of invention. Proof that there is need for this would be that someone has already implemented it, regardless of whether they make their implementation publically available. Having discussion threads about feature requests isn't proof that the features are necessary. :-) To bring one usage that is probably right around the corner is web services and machines communicating without user participation. One actual usage of this is the new ATOM API that is looking to supplement RSS and aggregation. Some background links on this are: http://bitworking.org/news/New_AtomAPI_Implementation_Release2 http://dannyayers.com/archives/001464.html http://www.intertwingly.net/wiki/pie/CommentAuthentication I can see where a lot of web services want more than simple AUTH but don't want to deal with the client side coding of SSL in their tools so digest seems at least a little better. As for implementing digest in AOLserver Rob Mayoff has already done the MD5 proc in his utils package here: http://dqd.com/~mayoff/aolserver/src/dqd_utils-1.3/ Anyway I see digest being a popular comprimise in alot of the client tools that will start to make themselves visible and if AOLserver wants to interact with these it may need it for web services. Best Regards, Carl Garland PS: Thanks to Nathan Folkman and others I will be starting at AOL for a contracting position very soon and look forward to being able to better serve both AOL and the AOLserver community. _ From Beethoven to the Rolling Stones, your favorite music is always playing on MSN Radio Plus. No ads, no talk. Trial month FREE! http://join.msn.com/?page=offers/premiumradio -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
In a message dated 11/3/2003 12:02:18 AM Eastern Standard Time, [EMAIL PROTECTED] writes: But I'm still a little confused. I thought all you had to do to add a new authentication method was to use the Ns_SetRequestAuthorizeProc to provide a pointer to a custom C function. The point where this would be executed is hard wired in (which is the whole point), but is the method also limited to only basic auth? I understand this isn't available via a tcl api, but what are the limitations if you do it in C?Apart from the fixed point where (and how) this mechanism triggers,(which is a another issue) it is also the definition of the proc.Look for yourself:typedef int (Ns_RequestAuthorizeProc) (char *server, char *method,char *url, char *user, char *pass, char *peer);The "user" and "pass" are suppplied by the AS implementationand those are parsed by AS out of the http headers for the basic auth.What one would need instead would be the connection structure (or anyother related struct where you can get the conn structure back)so the module designer would have access to all connection-relatedthings (like socket, headers and such).Otherwise, what would you do? The user/pass pair is here uselessand there is no way you can get them from somewhere else becausethat "somewhere else" is not accessible to you.I remember some 2 years ago we had the very same discussion onthis very same list.Zoran Hi, Zoran is right -- auth callback isn't flexibleenough. Should be something like: typedef int (Ns_ConnAuthProc)(Ns_Conn *conn, void *arg) We should fix this in 4.1 andwrite a backwards compatible hook to support the old Ns_RequestAuthorizeProc. -Jim -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
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
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Mon, 2003-11-03 at 16:01, Dossy wrote: 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? It is a special purpose 'HTTP like' request processor over tcp. It would be nice if you could set tcp/udp per ns_sock section. It would be great if ns_http was a separate module. Digest Auth seems pretty useless if it requires storing plain text passwords. That makes a big payoff for breaking into a webserver, database or whatever stores the passwords. This is probably why no one has had reason to use it much. It is extra work for no, or even negative, effect. Having a place to plug in a general authentication module in the form Jim Davidson just suggested seems the best solution. tom jackson -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Monday 03 November 2003 17:01, you wrote: Dossy, snip_a_lot I do think that we should concentrate on the topic of this thread. The functionality of Ns_SetRequestAuthorizeProc is not exposed on the Tcl level. Period. We might just make a small wrapper to do it, or design a better more versatile and general mechanism which would allow more funtionality or drop the entire request and sit on what we have now. I think there is a need for a better solution. Is this what you are willing to discuss? Zoran -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Mon, Nov 03, 2003 at 11:01:54AM -0500, Dossy wrote: On 2003.11.02, Zoran Vasiljevic [EMAIL PROTECTED] wrote: 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 Well now, that depends, doesn't it? I'm not really familiar with how AOLservers HTTP processing works underneath (the C code, and how things changed from 3.x to 4.0, for example), that part has just worked out of the box for me, for my needs. (E.g., I have never been responsibly for tuning an extrememly large and busy site.) But I can attest from personal experience that AOLserver work quite nicely as the former, a general purpose, multi-threaded daemon with a Tcl interpreter that ... happens to come standard with an HTTP request processor. I'd suggest that the later (web serving) is AOLserver's primary role, but the former (general purpose serving) is a second job that it's also very good at. I don't really see any conflict between the two, either. To the extent that AOLserver can be improved to better support the general daemon role without hurting the web server role, doing so is clearly a Good Thing. that case, think about the 95% case for AOLserver -- serving an HTTP request with NO authentication. In this scenario, supporting N 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. Nonsense. If that were true OpenACS never would have implemented it's extensive user authentication and session tracking via Tcl, cookies, the RDBMS, and registered filters. Clearly for a large class of AOLserver users, the hard-wired authentication support in AOLserver was so minimal as to be utterly useless. Whether or not that minimal auth support it is a problem that needs solving, and how, is a different question - see below. 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. No, I think Zoran had a good point. One of AOLserver's major strengths is the flexibility and power that it's clean design provides. (Arguably, it's kind of like a microkernel OS for web apps...) We are all at least somewhat familiar with how AOLserver goes about doing this (registered filters, Tcl and C APIs, etc.) However, to the extent that OpenACS had to roll all their own authentication using registered filters BECAUSE the existing plugins or callbacks for authentication already present in AOLserver were half done or incomplete, or DESPITE the existence of those functions, then yes that IS a negative for AOLserver. It says roughly one of these these 3 things about AOLserver's authentication support: 1. OpenACS implementing all authentication via registered filters was GOOD, it was an example of the best approach for authentication overall. Authentication doesn't belong in the AOLserver core at all, it should be implemented soley via registered filters, and any existing partial and limited built-in authentication support should be removed. 2. The basic HTTP authentication built into AOLserver is simply a special purpose hack. It's ok that it's present in AOLserver, but it should be understood to be a historical, special purpose hack, and the GENERAL solution for authentication should come via registered filters as above. 3. Specific authentication callbacks in AOLserver make sense, are a good idea, and should be provided and used in place of or in combination with registered filters. Therefore, the existing authentication callbacks and such are a good but incomplete; the design and implementation needs to be finished. I have no idea which of those three is correct, but I'm curious to hear what the rest of you think. :) As an aside, there is quite a lot of code in OpenACS that is very useful in general, and not especially specific to OpenACS at all. E.g., the database API, the templating system, ad_proc and many of the other Tcl APIs, and, of particular immediate interest here, the user session authentication. It would be nice to re-factor much of that so it could be easily used in non-OpenACS AOLserver environments as well.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
I'm pretty new to AOLserver and so I'm by no mean an expert on AOLserver itself, but I have got plenty of experience in the internet world, in particular running high traffic portals. I was drawn to AOLserver for a few reasons: 1) I love Tcl 2) Having used the (Tcl based) Vignette CMS I wanted to see just how terribly slow Vignette was 3) I needed a cheap (or free) application server for a project I was working on, one that I could setup, configure and code for quickly and easily and one that would scale at a later date. AOLserver turned out to be a very capable beast, but the experience for a newbie is not incredibly enjoyable. The community *is* one of the most friendly and helpful that I've come across, which make this experience bearable, but AOLserver really is lacking example (or working) code that would help a new user build something real, rather than just serve a few random web pages. The documentation isn't really at fault as you can find information on pretty much every configurable option, but there's very little information on the *best* way to configure the server for different common uses. (e.g. simple error handling using startpage.adp and errorpage.adp - you are told it can be done, but there's little or no information on how you might usefully use this feature) There's a number of modules out there that are in varying states of release - I've lost count of how many pure Tcl, pure C or hybrid session management modules I found, before deciding to refactor the OpenACS version. There's little information on how to develop for, support and and maintain an AOLserver site e.g. tracking down bits of code that performance bottlenecks etc. I'm sure there's reams of this kicking around at AOL, and other live sites, and it owuld be invaluable to the new user (and probably to the commuity) for these to be made available. Compare this with other systems (OpenACS incldued) where there's more or less complete working solutions for many common website features that you can just download and install and have them up and running (not necesarily optimally) in minutes. 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 The answer to that will vary depending on how someone is using it - not everyone will have used AOLserver enough, or have looked into the code enough to answer with any authority. As far as I can see, if you believe the stats, the AOLserver *is* an extremely performant scalable HTTP server. Being a multithreaded app rather than a multiprocess (a la Apache 1.x) is a good thing in this environment. However, there is little information from the sites where AOLserver is really hammered on how they've done this i.e. how they have set up farms of servers, how they balance incoming requests over them, how they measure performance of both static files and dynamically generated output. To the extent that AOLserver can be improved to better support the general daemon role without hurting the web server role, doing so is clearly a Good Thing. I'd agree with this, emphasizing the *without* bit though! The authors of things like nsdns, nssnmp etc. would probably argue that AOLserver *is* a very good multipurpose server. 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. Nonsense. If that were true OpenACS never would have implemented it's extensive user authentication and session tracking via Tcl, cookies, the RDBMS, and registered filters. Clearly for a large class of AOLserver users, the hard-wired authentication support in AOLserver was so minimal as to be utterly useless. Not necessarily - may people for purely asthetic reasons don't like having the browser 'pop-up' the login box and prefer to embed this in a page that fits in their site nicely. I can't speak for OpenACS of course but this could have been a consideration. They could have easily taken the nsperm code and modified this to use info from the database but I suspect that they had a preference to do everything in Tcl to make OpenACS more 'open' - to extend it and modify it you only need know Tcl (not Tcl *and* C) Whether or not that minimal auth support it is a problem that needs solving, and how, is a different question - see below. At what point does a web server stop being a webserver when it doesn't support everything in the
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
Hi, Zoran is right -- auth callback isn't flexible enough. Should be something like: typedef int (Ns_ConnAuthProc)(Ns_Conn *conn, void *arg) We should fix this in 4.1 and write a backwards compatible hook to support the old Ns_RequestAuthorizeProc. -Jim This should be fairly easy to do. So, as soon as the 4.0 freezes (I see it is still in flux although the GM should have been released already) we could hook this in. This is a very good, simple and practical idea! Thx, Zoran -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On 04/11/2003, at 3:45 AM, Tom Jackson wrote: Digest Auth seems pretty useless if it requires storing plain text passwords. That makes a big payoff for breaking into a webserver, database or whatever stores the passwords. that's ridiculous - if you can't secure your server enough to protect the user passwords then you can't secure it enough to protect the content protected by those passwords, and you're already up the proverbial creek without a paddle. -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Tue, 4 Nov 2003, russm wrote: On 04/11/2003, at 3:45 AM, Tom Jackson wrote: Digest Auth seems pretty useless if it requires storing plain text passwords. That makes a big payoff for breaking into a webserver, database or whatever stores the passwords. that's ridiculous - if you can't secure your server enough to protect the user passwords then you can't secure it enough to protect the content protected by those passwords, and you're already up the proverbial creek without a paddle. The put all the eggs in one basket, and WATCH THAT BASKET philosophy? The crypto community soundly rejected Auth-Digest. Insulting someone's administration skills doesn't change that, and it doesn't make Digest look any better. -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
There seem to be 2 separate arguments going on here - one about the best way to implement non-Basic authentication in AOLserver, and another about the usefulness of using Digest in the first place. I'm going to avoid the implementation related stuff and stick solely to the utility of Digest auth. On 04/11/2003, at 3:01 AM, Dossy wrote: 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. snip If you're using SSL, you don't need Digest auth for most applications. So our options are either a lightweight implementation with zero real security, or a heavyweight implementation with full authentication and encryption? There's no middle ground? 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. Digest *does* provide protection against MITM - see section 2.1.2 of RFC 2069 - no intermediate party can retrieve the cleartext of the user's password, turn the user's requests for some URI into requests for another URI, or change the body of the request. Section 2.1.3 describes how the server can additionally let the client know that the response has not been changed en-route. Let me restate the question a little clearer: other than non-SSL WebDAV, what specific /application/ uses Digest auth as a must-have requirement? What are you asking for here? RFC #s? business cases? a letter from my manager? Can you see that transmitting passwords in cleartext is something that should (all other things being equal) be avoided? I have personally known people at a major ISP who hung a password-grabber off the side of the main customer web proxy in a particular city, just for amusement. I read an article a while (6 months?) ago about a US cable ISP who had their primary DNS server compromised which then served the address of a malicious proxy to all their clients. Password sniffing attacks are a real thing on the internet but because they don't leave us, the implementors, with the pain of rebuilding a rooted box we don't tend to care as much as we do about attacks against our own servers. I'm not asking you to implement it, I just find it hard to understand how so many people here can believe that there is no benefit at all to using something like Digest. Russell -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On 04/11/2003, at 12:33 PM, Todd Gillespie wrote: On Tue, 4 Nov 2003, russm wrote: that's ridiculous - if you can't secure your server enough to protect the user passwords then you can't secure it enough to protect the content protected by those passwords, and you're already up the proverbial creek without a paddle. The put all the eggs in one basket, and WATCH THAT BASKET philosophy? As opposed to the leave your eggs lying all around the place and hope that nobody comes along and picks them up philosophy? Well yes, I guess so... The crypto community soundly rejected Auth-Digest. I am extremely willing to be educated here - could you provide a reference or 2? I'm basing what I say on what I believe to be sound knowledge and if I'm wrong I'd like to know about it. Insulting someone's administration skills doesn't change that, and it doesn't make Digest look any better. Perhaps I should have been clearer - You was not any specific person, it was a generic administrator of some system. No insult was intended to anyone on this list. Russell -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On 2003.11.03, Tom Jackson [EMAIL PROTECTED] wrote: On Mon, 2003-11-03 at 16:01, Dossy wrote: 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? It is a special purpose 'HTTP like' request processor over tcp. It would be nice if you could set tcp/udp per ns_sock section. It would be great if ns_http was a separate module. If HTTP request processing could be pulled out in a clean way that didn't impact the 90% case that AOLserver will be used as an HTTP request processor from a performance perspective, I might agree with you. Doing this, however, is no easy task. Doing it right, that's even tougher. Digest Auth seems pretty useless if it requires storing plain text passwords. That makes a big payoff for breaking into a webserver, database or whatever stores the passwords. Storing passwords using a 16 bit salt and a 64 bit key (ala unix crypt) is pretty dangerous if the system storing the passwords can be compromised. With modern processing power readily available to the average consumer, brute-force attacks on 64 bit keys is trivial. Since it's so easy to break those passwords, why make yourself jump through hoops? Just store the passwords in plain text so you can take advantage of having them in that form. If you're paranoid, place the authentication mechanism on a machine that sits behind some level of network security, and don't let the passwords pass the wire into unsafe networks at all. Have the webserver call out to this authentication system passing a strong token that can be used to authenticate, and have the auth. system pass back a yes/no. This is probably why no one has had reason to use it much. It is extra work for no, or even negative, effect. Putting words in your mouth: I agree. Digest auth really isn't much more security than basic auth. If you must, pass the password in plain-text using Basic auth and protect the transport layer using SSL. Once authenticated, give the user a strong authentication token to send back with future transactions, then send the user back to a non-SSL transport layer for speed/performance reasons. -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On 2003.11.03, Zoran Vasiljevic [EMAIL PROTECTED] wrote: I think there is a need for a better solution. Is this what you are willing to discuss? Yes and no. What I'm willing to discuss is if there is a need for /a/ solution. Then, we can talk about better ones ... -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On 2003.11.03, Zoran Vasiljevic [EMAIL PROTECTED] wrote: Jim Davidson wrote: Zoran is right -- auth callback isn't flexible enough. Should be something like: typedef int (Ns_ConnAuthProc)(Ns_Conn *conn, void *arg) We should fix this in 4.1 and write a backwards compatible hook to support the old Ns_RequestAuthorizeProc. This should be fairly easy to do. So, as soon as the 4.0 freezes (I see it is still in flux although the GM should have been released already) we could hook this in. This is a very good, simple and practical idea! As Jim points out, fixing the hook into the auth. mechanism is an easy change. But, without a set of pre-written authenticators that can be plugged in, for most folks who aren't C programmers or don't want to learn how to write an HTTP authentication module in Tcl using filters, this doesn't do much good. That's why I still think it's important to understand how people will use these alternate methods of authentication that can be plugged in, so that we can actually develop a few canned procs for people to plug in and use. Just my thinking ... -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On 04/11/2003, at 1:35 PM, Dossy wrote: If you're paranoid, place the authentication mechanism on a machine that sits behind some level of network security, and don't let the passwords pass the wire into unsafe networks at all. Have the webserver call out to this authentication system passing a strong token that can be used to authenticate, and have the auth. system pass back a yes/no. snip Putting words in your mouth: I agree. Digest auth really isn't much more security than basic auth. If you must, pass the password in plain-text using Basic auth and protect the transport layer using SSL. Once authenticated, give the user a strong authentication token to send back with future transactions, then send the user back to a non-SSL transport layer for speed/performance reasons. The ability to have the plaintext passwords stored in some more secure repository on the server side is covered in Digest by the the ability of the HTTP server to retrieve H(A1) from some other source (RFC2069, sec. 2.2). The Basic/SSL - strong authentication token mechanism you describe is open to both replay and MITM attacks. To avoid replay you would need to timeout and renegotiate the tokens (which is provided with Digest's nonce management). To avoid MITM the token would also need to be somehow tied to the request URI and body (impossible with cookies, provided in Digest auth). Cryptographically, the correct solution is SSL/TLS. However, in practice we're not going to be running every single authenticated connection over SSL any time soon. As far as I can tell Digest is a step in the right direction, has already been specified, and securely* solves the problem it claims to solve (unencrypted passwords on the wire), which in my opinion puts it ahead of any ad-hoc homegrown solution to the same problem. Russell * I haven't seen any reports of weaknesses in Digest's design, and I'm keen to be informed if I'm wrong on this. -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On 2003.11.04, russm [EMAIL PROTECTED] wrote: The ability to have the plaintext passwords stored in some more secure repository on the server side is covered in Digest by the the ability of the HTTP server to retrieve H(A1) from some other source (RFC2069, sec. 2.2). Right. One problem though is that Digest auth. requires the server to store the nonce values on the server for as long as they're valid. If you use one-time nonce's, you have to remember all the nonce's you've issued until they either (a) expire or (b) you've seen them come back in a digest-response. This isn't a hard problem to solve, of course. There's plenty of ways to store server-side data ... ;-) The Basic/SSL - strong authentication token mechanism you describe is open to both replay and MITM attacks. To avoid replay you would need to timeout and renegotiate the tokens (which is provided with Digest's nonce management). To avoid MITM the token would also need to be somehow tied to the request URI and body (impossible with cookies, provided in Digest auth). True. However, folks like Amazon seem to be willing to accept replay and MITM attacks -- they auth. over SSL, then set auth. cookies and downgrade to regular HTTP after authentication. Granted, it's not strong authentication, but if e-commerce at Amazon.com doesn't require it ... what really does? Sometimes, the best solution to a technological problem can be a non-technological one. I wonder what Amazon's fraud policy looks like, and what exposure to risk they're limited to ... Cryptographically, the correct solution is SSL/TLS. However, in practice we're not going to be running every single authenticated connection over SSL any time soon. Right. While ideal, this method is quite costly with the added processing power required, as you point out. As far as I can tell Digest is a step in the right direction, has already been specified, and securely* solves the problem it claims to solve (unencrypted passwords on the wire), which in my opinion puts it ahead of any ad-hoc homegrown solution to the same problem. [...] * I haven't seen any reports of weaknesses in Digest's design, and I'm keen to be informed if I'm wrong on this. What browsers implement Digest auth? Can you use Digest auth without having to pop up a window on the client browser? Silly requirements, but they seem to drive people's decisions on how to implement authentication, strangely enough. -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Sunday 02 November 2003 00:25, you wrote: Why not? What's wrong with a pre-auth filter that uses [ns_conn authuser], [ns_conn authpasswd] and [ns_returnunauthorized]? There is nothing wrong with that, except the fact that values returned by ns_conn authpasswd and ns_conn authuser are parsed out of the http header for basic authorization only. Therefore, such are not usable for any other kind of authentication method. Zoran -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Sun, 2 Nov 2003, Zoran Vasiljevic wrote: On Sunday 02 November 2003 00:25, you wrote: Why not? What's wrong with a pre-auth filter that uses [ns_conn authuser], [ns_conn authpasswd] and [ns_returnunauthorized]? There is nothing wrong with that, except the fact that values returned by ns_conn authpasswd and ns_conn authuser are parsed out of the http header for basic authorization only. Therefore, such are not usable for any other kind of authentication method. You can always parse [ns_set get [ns_conn headers] Authorization] yourself in Tcl... -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Sunday 02 November 2003 12:33, you wrote: On Sun, 2 Nov 2003, Zoran Vasiljevic wrote: On Sunday 02 November 2003 00:25, you wrote: Why not? What's wrong with a pre-auth filter that uses [ns_conn authuser], [ns_conn authpasswd] and [ns_returnunauthorized]? There is nothing wrong with that, except the fact that values returned by ns_conn authpasswd and ns_conn authuser are parsed out of the http header for basic authorization only. Therefore, such are not usable for any other kind of authentication method. You can always parse [ns_set get [ns_conn headers] Authorization] yourself in Tcl... That's what I already told... One must do these things by hand in Tcl. But this point shows a *limitation* in the current AS design. Much better would be to be able to register callbacks (C or Tcl) at some points in the request processing which would do the right thing. Then, other high-level stuff like ns_conn authuser would already return correct values. Zoran -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On 2003.11.02, Zoran Vasiljevic [EMAIL PROTECTED] wrote: That's what I already told... One must do these things by hand in Tcl. But this point shows a *limitation* in the current AS design. Exactly how is this a limitation? If it were the case that there WAS no way to implement Digest authentication under the current AOLserver, I'd say then THAT would be a limitation. It's important to distinguish between not yet implemented vs. not currently implementable. The former is simply not feature complete. The latter is a flaw in the design. 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. Much better would be to be able to register callbacks (C or Tcl) at some points in the request processing which would do the right thing. Then, other high-level stuff like ns_conn authuser would already return correct values. Is there really that much demand for Digest authentication? Other than non-SSL WebDAV, what else actually implements Digest auth as a requirement? -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Sunday 02 November 2003 13:49, you wrote: Exactly how is this a limitation? If it were the case that there WAS no way to implement Digest authentication under the current AOLserver, I'd say then THAT would be a limitation. It's important to distinguish between not yet implemented vs. not currently implementable. The former is simply not feature complete. The latter is a flaw in the design. 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. 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. I would prefer some expert writes a clean plugin module for XYZ functionality and I just use it by plugging it where I need it, instead of becoming the XYZ expert myself and having to write all of that by hand over and over. This is what I call a limitation. 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? 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. Is there really that much demand for Digest authentication? Other than non-SSL WebDAV, what else actually implements Digest auth as a requirement? Security. 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? 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. Zoran -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Sun, 2003-11-02 at 14:19, Zoran Vasiljevic wrote: 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. Zoran I think you make a lot of good points. Mainly, there is already a place to do authentication. Before or after this point requires a little hackery. But I'm still a little confused. I thought all you had to do to add a new authentication method was to use the Ns_SetRequestAuthorizeProc to provide a pointer to a custom C function. The point where this would be executed is hard wired in (which is the whole point), but is the method also limited to only basic auth? I understand this isn't available via a tcl api, but what are the limitations if you do it in C? tom jackson -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Sunday 02 November 2003 17:55, you wrote: But I'm still a little confused. I thought all you had to do to add a new authentication method was to use the Ns_SetRequestAuthorizeProc to provide a pointer to a custom C function. The point where this would be executed is hard wired in (which is the whole point), but is the method also limited to only basic auth? I understand this isn't available via a tcl api, but what are the limitations if you do it in C? Apart from the fixed point where (and how) this mechanism triggers, (which is a another issue) it is also the definition of the proc. Look for yourself: typedef int (Ns_RequestAuthorizeProc) (char *server, char *method, char *url, char *user, char *pass, char *peer); The user and pass are suppplied by the AS implementation and those are parsed by AS out of the http headers for the basic auth. What one would need instead would be the connection structure (or any other related struct where you can get the conn structure back) so the module designer would have access to all connection-related things (like socket, headers and such). Otherwise, what would you do? The user/pass pair is here useless and there is no way you can get them from somewhere else because that somewhere else is not accessible to you. I remember some 2 years ago we had the very same discussion on this very same list. Zoran -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
We likey! -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] Behalf Of Dave Bauer Sent: Friday, October 31, 2003 3:22 PM To: [EMAIL PROTECTED] Subject: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command Would it make sense to have Ns_SetRequestAuthroizeProc available in Tcl. I want to allow HTTP authentication against my database, and this looks like the way to go. Its defined in nsd/auth.c Seems that ideally ns_perm would use this instead of only checking the ns_perm users list. -- 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. -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
The problems I have with HTTP-Auth are actually forcing me to go in the direction of Session mananged Authentication for a number of reasons -- but those are particular issues that my clients deal with. The session managed authentication that comes with OpenACS is pretty nice (and obviously tried and tested with lots of users). I've got a version of it that has been de-bundled from the rest of OpenACS working with AOLserver. I've been meaning to tidy it up and make it available for some time. If you are interested let me know - it might actually motivate me to do this! ;-) Cheers, Tim -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On 2003.10.31, Dave Bauer [EMAIL PROTECTED] wrote:
On Fri, Oct 31, 2003 at 03:29:24PM +, Patrick O'Leary wrote:
Alternatively you could just look at ns_register_filter-
It's probably what your looking for.
Not really.
Why not? What's wrong with a pre-auth filter that uses [ns_conn authuser],
[ns_conn authpasswd] and [ns_returnunauthorized]?
Instead of pre-auth filters, I did this in my startpage.adp since I'm
using one, and the code looks something like this:
if {![cms.isConnAuth]} {
ns_returnunauthorized
return
}
ns_adp_include [ns_url2file [ns_conn url]]
Obviously, the cms.isConnAuth proc is pretty straight-forward too:
proc cms.isConnAuth {} {
if {[catch {cms.auth [ns_conn authuser] [ns_conn authpassword]} err]} {
return 0
}
return 1
}
What's cms.auth look like, you ask? Here:
proc cms.auth {user pass} {
if {[catch {set expected [cms.db.get auth.dat $user]}]} {
error no such user '$user' in auth db
}
if {$pass ne $expected} {
error invalid password for user '$user' in auth db
}
}
Of course, this solution works /perfectly/ for me but that's because
it's designed to solve the problem I had.
I need to do HTTP authentication. I could write an HTTP authentication
implementation and register that as a filter, but I'd rather not.
Why would you rather not?
Sounds like you've got a technological solution and you're looking for a
problem to solve, not the other way around. Identify your problem and
many workable solutions ought to just become obvious. :-)
-- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
Dossy wrote:
On 2003.10.31, Dave Bauer [EMAIL PROTECTED] wrote:
On Fri, Oct 31, 2003 at 03:29:24PM +, Patrick O'Leary wrote:
Alternatively you could just look at ns_register_filter-
It's probably what your looking for.
Not really.
Why not? What's wrong with a pre-auth filter that uses [ns_conn authuser],
[ns_conn authpasswd] and [ns_returnunauthorized]?
Instead of pre-auth filters, I did this in my startpage.adp since I'm
using one, and the code looks something like this:
if {![cms.isConnAuth]} {
ns_returnunauthorized
return
}
ns_adp_include [ns_url2file [ns_conn url]]
Obviously, the cms.isConnAuth proc is pretty straight-forward too:
proc cms.isConnAuth {} {
if {[catch {cms.auth [ns_conn authuser] [ns_conn authpassword]} err]} {
return 0
}
return 1
}
What's cms.auth look like, you ask? Here:
proc cms.auth {user pass} {
if {[catch {set expected [cms.db.get auth.dat $user]}]} {
error "no such user '$user' in auth db"
}
if {$pass ne $expected} {
error "invalid password for user '$user' in auth db"
}
}
Of course, this solution works /perfectly/ for me but that's because
it's designed to solve the problem I had.
I need to do HTTP authentication. I could write an HTTP authentication
implementation and register that as a filter, but I'd rather not.
Why would you rather not?
Sounds like you've got a technological solution and you're looking for a
problem to solve, not the other way around. Identify your problem and
many workable solutions ought to just become obvious. :-)
-- 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.
Thanks for that code. I think I can make it work, and probably will
need to use filters.
I just wanted to see if I can reuse some code and possibly let others
use it too.
Probably I will need to implement the authentication as a filter, but I
would like to see digest authentication that does allow a tcl proc to
check the password built into AOLserver at some point.
Dave
--
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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
russm wrote: On 02/11/2003, at 10:35 AM, Dave Bauer wrote: Probably I will need to implement the authentication as a filter, but I would like to see digest authentication that does allow a tcl proc to check the password built into AOLserver at some point. are the passwords used by nsperm stored encrypted the same was as the nscp password? if so you won't be able to use them for digest auth as digest requires the server have access to plaintext passwords. for some discussion of this see the last few messages in this thread http://openacs.org/forums/message-view?message_id=116527 -- 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. Hmmm. I am not using it for nscp. I never turn that on. I need to compare the password against a database. Dave -- 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.
[AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
Would it make sense to have Ns_SetRequestAuthroizeProc available in Tcl. I want to allow HTTP authentication against my database, and this looks like the way to go. Its defined in nsd/auth.c Seems that ideally ns_perm would use this instead of only checking the ns_perm users list. -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
Alternatively you could just look at ns_register_filter- It's probably what your looking for. P Dave Bauer wrote on 31/10/2003, 15:21: Would it make sense to have Ns_SetRequestAuthroizeProc available in Tcl. I want to allow HTTP authentication against my database, and this looks like the way to go. Its defined in nsd/auth.c Seems that ideally ns_perm would use this instead of only checking the ns_perm users list. -- 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. -- Patrick O'Leary AIM: polearyuk Email: [EMAIL PROTECTED] Phone: +44 (0) 207 348 8462 This email, its contents and any files transmitted with it are confidential and may be legally privileged. It is intended solely for the addressee(s) only. If you are not the intended recipient, you must not copy, distribute, or take any action in reliance upon it. If you have received this email in error, please notify us immediately via telephone or fax and delete the material from your computer system. AOL (UK) Ltd is registered in England under number 03462696, with its registered office at 80 Hammersmith RD, Hammersmith London w14 8ud. -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
Not really. I need to do HTTP authentication. I could write an HTTP authentication implementation and register that as a filter, but I'd rather not. Dave On Fri, Oct 31, 2003 at 03:29:24PM +, Patrick O'Leary wrote: Alternatively you could just look at ns_register_filter- It's probably what your looking for. P Dave Bauer wrote on 31/10/2003, 15:21: Would it make sense to have Ns_SetRequestAuthroizeProc available in Tcl. I want to allow HTTP authentication against my database, and this looks like the way to go. Its defined in nsd/auth.c Seems that ideally ns_perm would use this instead of only checking the ns_perm users list. -- 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. -- Patrick O'Leary AIM: polearyuk Email: [EMAIL PROTECTED] Phone: +44 (0) 207 348 8462 This email, its contents and any files transmitted with it are confidential and may be legally privileged. It is intended solely for the addressee(s) only. If you are not the intended recipient, you must not copy, distribute, or take any action in reliance upon it. If you have received this email in error, please notify us immediately via telephone or fax and delete the material from your computer system. AOL (UK) Ltd is registered in England under number 03462696, with its registered office at 80 Hammersmith RD, Hammersmith London w14 8ud. -- 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. -- Dave Bauer [EMAIL PROTECTED] http://www.thedesignexperience.org -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Friday 31 October 2003 17:07, you wrote: Not really. I need to do HTTP authentication. I could write an HTTP authentication implementation and register that as a filter, but I'd rather not. I agree with you. In the same go, we might even introduce hooks for entirely different auth methods like digest etc. Cheers Zoran -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
How about an authentication plugin structure that would allow one to load their own authentication method. HTTP-Auth against a database, HTTP-Auth against a flat-file, HTTP-Auth against LDAP, etc. Digest, Certificate, Session Auth, etc. At least in the long run, it would be much more flexible. The problems I have with HTTP-Auth are actually forcing me to go in the direction of Session mananged Authentication for a number of reasons -- but those are particular issues that my clients deal with. HTTP-Auth has no decent way of maintaining 1 User, 1 Session. HTTP-Auth is easily probed by automated tools (not that they cannot be developed for other methods). Poor Realm support (user education issue here) On Fri, 2003-10-31 at 11:52, Zoran Vasiljevic wrote: On Friday 31 October 2003 17:07, you wrote: Not really. I need to do HTTP authentication. I could write an HTTP authentication implementation and register that as a filter, but I'd rather not. -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
Isn't the HTTP authentication implementation already built into AOLserver, via ns_conn authuser and ns_conn authpassword? I have a site which has a filter registered to /*. That filter merely looks at ns_conn authuser/ns_conn authpassword and then authenticates against a file -- you could to the same, and do a db call to validate the user's credentials. Ross Zoran Vasiljevic wrote on 10/31/2003, 9:52 AM: On Friday 31 October 2003 17:07, you wrote: Not really. I need to do HTTP authentication. I could write an HTTP authentication implementation and register that as a filter, but I'd rather not. I agree with you. In the same go, we might even introduce hooks for entirely different auth methods like digest etc. Cheers Zoran -- 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. -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Fri, 2003-10-31 at 17:19, Chris Davies wrote: How about an authentication plugin structure that would allow one to load their own authentication method. The named function _is_ the plugin structure. Just provide a C function that does what you want. I think Dave wants to be able to specify a tcl proc via a tcl command, or maybe a different c proc via a tcl command. But the point is, this is a single point of entry for replacing the authentication for a request. You don't need a filter, although there is already support for providing these in tcl right now. So the question is: couldn't you get the same effect by ensuring the new auth code ran as the first 'post-auth' filter? tom jackson -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
Yes. It's one of the area's we've been looking to possibly improve as in upcoming releases. Zoran Vasiljevic wrote on 10/31/03, 12:36 PM: I's only the basic authentication (hard-wired into C-code) Pretty inflexible, that is. Zoran -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Friday 31 October 2003 18:19, you wrote: How about an authentication plugin structure that would allow one to load their own authentication method. HTTP-Auth against a database, HTTP-Auth against a flat-file, HTTP-Auth against LDAP, etc. Digest, Certificate, Session Auth, etc. At least in the long run, it would be much more flexible. You read my mind. This is one of the things we can schedule for some (near)future release. In fact, we should be somehow gathering ideas for what needs to be done in 4.1 because the 4.0 is out of the door (well, almost). I'd like to see nice clean C-level hooks which would allow AS to accomodate various authentication methods as a plugin module (either in C or in Tcl alone). This is of course only one interesting addition. I'm sure there are number of them out there. Cheers, Zoran -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
Sure, Here is what I am doing. I am working on WebDAV access to content in an OpenACS intsallation. If a reqest doesn't send an authentication header, I want to ask for the info, so I figured it would be best to use what is already built into AOLserver. It looks like auth.c was written to allow this, but noone exposed the command that registers the user tcl procedure as a tcl procedure itself. Dave On Fri, Oct 31, 2003 at 10:22:45AM -0700, Ross Simpson wrote: Isn't the HTTP authentication implementation already built into AOLserver, via ns_conn authuser and ns_conn authpassword? I have a site which has a filter registered to /*. That filter merely looks at ns_conn authuser/ns_conn authpassword and then authenticates against a file -- you could to the same, and do a db call to validate the user's credentials. Ross Zoran Vasiljevic wrote on 10/31/2003, 9:52 AM: On Friday 31 October 2003 17:07, you wrote: Not really. I need to do HTTP authentication. I could write an HTTP authentication implementation and register that as a filter, but I'd rather not. I agree with you. In the same go, we might even introduce hooks for entirely different auth methods like digest etc. Cheers Zoran -- 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. -- 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. -- Dave Bauer [EMAIL PROTECTED] http://www.thedesignexperience.org -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
This is what I was thinking as well. At the very least we should make sure the necessary hooks are provided (C and Tcl). Zoran Vasiljevic wrote on 10/31/03, 12:42 PM: You read my mind. This is one of the things we can schedule for some (near)future release. In fact, we should be somehow gathering ideas for what needs to be done in 4.1 because the 4.0 is out of the door (well, almost). I'd like to see nice clean C-level hooks which would allow AS to accomodate various authentication methods as a plugin module (either in C or in Tcl alone). This is of course only one interesting addition. I'm sure there are number of them out there. Cheers, Zoran -- 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.
Re: [AOLSERVER] Ns_SetRequestAuthorizeProc has no Tcl Command
On Friday 31 October 2003 18:38, you wrote: Sure, Here is what I am doing. I am working on WebDAV access to content in an OpenACS intsallation. If a reqest doesn't send an authentication header, I want to ask for the info, so I figured it would be best to use what is already built into AOLserver. It looks like auth.c was written to allow this, but noone exposed the command that registers the user tcl procedure as a tcl procedure itself. AFAIK, the dav uses digest authentication and AS does not undersand this per-se. So, you can't just use nsperm module and its user database to authenticate users. Currently, I can't think of any solution except getting all done by hand using filters. I maybe wrong, though... Zoran -- 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.
