> 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 yours
> 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.
Hav
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 ses
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
n 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
>
>
>
On Tuesday 04 November 2003 16:45, you wrote:
> 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.
Great! Thanks Nathan!
In the meantime I'll try to get the
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 th
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 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 (= AOLs
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
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
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 conside
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 wh
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
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 prob
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 s
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 compatib
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 Shi
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
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 cree
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.
O
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 y
+-- On Nov 4, russm said:
| 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.
Suppose an intruder b
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 us
> 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 fair
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
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 co
On Monday 03 November 2003 17:01, you wrote:
Dossy,
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 gen
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 specia
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 c
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 thi
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
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 goo
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"
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 aut
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 noth
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
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" a
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
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 s
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.
Wh
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_
> 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
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
>
>
&g
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 int
On Friday 31 October 2003 18:39, you wrote:
> 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 w
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
>
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 t
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.
>
> 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 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
On Friday 31 October 2003 18:22, you wrote:
> Isn't the HTTP authentication implementation already built into
> AOLserver, via ns_conn authuser and ns_conn authpassword?
>
I's only the basic authentication (hard-wired into C-code)
Pretty inflexible, that is.
Zoran
--
AOLserver - http://www.aols
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
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.
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 met
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 wh
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
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
58 matches
Mail list logo
