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 2003.11.03, derek keller <[EMAIL PROTECTED]> wrote:
> > A lot of us on this mailing list have our own personal repositories
> > of code that we make publically available and share, but that makes
> > it harder for newbies and oldbies since there's no centrallized
> > mechanism for pubilshing poi
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
You can easily bind to more than one port/IP address, however, I
believe all requests in 3.x are dumped into a common connection queue,
which does not solve the original problem. It sounds like you want
multiple connection queues, so that one can be overloaded yet the
other is still getting servic
On Mon, Nov 03, 2003 at 01:35:38PM -0800, Scott Laplante wrote:
> Specifically, we would want connection threads bound to port 80, and
> internal communication threads (i.e. event messages between servers in the
> cluster) bound to port 8080 (or similar).
Yes, I'm pretty sure it can bind to two d
You definitely can do this in AOLserver 4 by loading more than one nssock
module.
In AOLserver 4 if you are using the built in 'virtual server' support, you
configure one global nssock and it listens on whatver port you configure it
to.
You can then have an individual virtual server (within the sa
I'm interested in specifics regarding whether AOLServer can bind itself to
more than one port at a time.
Specifically, we would want connection threads bound to port 80, and
internal communication threads (i.e. event messages between servers in the
cluster) bound to port 8080 (or similar).
Our in
> 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
What would be the cgi2fastcgi bridge - does it have any advantages
over SpeedyCGI? I didn't find anything regarding this on google.
It's actually "cgi-fcgi" ... code/docs are here :
http://www.fastcgi.com/devkit/doc/overview.html
The primary advantage of FastCGI is something I don't think you c
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
> A lot of us on this mailing list have our own personal repositories
> of
> code that we make publically available and share, but that makes it
> harder for newbies and oldbies since there's no centrallized
> mechanism
> for pubilshing pointers to all these repositories. I think this is a
> real
* John Sequeira <[EMAIL PROTECTED]> [20031103 15:46]:
> If your app was written portably enough to run under CGI, then I would
> recommend going that route with AOLServer.
>
> If you want a performance boost, look into persistent perl, SpeedyCGI
> or FastCGI (using t
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
Beware that there is no such thing as lightweight C code if you run this
on Solaris, it will fork and to do that first assign enough memory as the
parent process (AOLserver) is using, which can be costly if your box is
hit hard.
Another way of doing this, if the app positively must run on the same
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
Tilman,
If your app was written portably enough to run under CGI, then I would
recommend going that route with AOLServer.
If you want a performance boost, look into persistent perl, SpeedyCGI
or FastCGI (using the cgi2fastcgi bridge, since AOLServer doesn't
support FastCGI). There might be sl
On 2003.11.02, Tilmann Singer <[EMAIL PROTECTED]> wrote:
>
> I have an application that runs under apache mod_perl, and I was
> wondering if it would be possible to make it run under aolserver
> somehow as well.
Is this an off-the-shelf package, or something custom-developed by you?
If it's an OT
28 matches
Mail list logo
