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
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
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
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
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.
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
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 (=
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
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
-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
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
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
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.
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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 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
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
53 matches
Mail list logo
