Brad Nicholes [EMAIL PROTECTED] wrote in news:sdf8b26d.020@prv-
mail25.provo.novell.com:
In order to solve WebDAV's problem, the
scope of this discussion needs to be much broader. Any ideas??
Hm, not really. :/
This should be done by someone with more experience to the code.
Kess
* Brad Nicholes wrote:
This patch eliminates the hardcoded charset table. Instead it reads the
charset table from a conf file. The directive AuthLDAPCharsetConfig allows
the admin to specify the charset conf file.
You should change the command error messages... ;-)
Is there also a need to
* Brad Nicholes wrote:
Second cut at allowing extended characters. The name of the directive
changed to AuthLDAPCharsetConversion rather than
AuthLDAPConvertFromLanguage since it is mainly dealing with character
sets rather than languages. It also changed from an AP_INIT_TAKE1 to and
converting the user ID
to UTF8 of try to derive the language from the header. It allows the admin to specify
use-header which will attempt to determine which language to convert from, by
parsing the accept-language header from the request. Once the user ID has been
converted to UTF8, authentication
).
It allows the admin to specify use-header which will attempt to
determine which language to convert from, by parsing the accept-language
header from the request. Once the user ID has been converted to UTF8,
authentication is performed against the LDAP directory using the raw
password
At 03:42 PM 12/6/2002, Brad Nicholes wrote:
This patch adds a new directive AuthLDAPConvertFromLanguage to mod_auth_ldap
that allows the admin to either define a specific language when converting the user
ID to UTF8 of try to derive the language from the header.
Ewww... charsets aren't
At 09:35 PM 10/27/2002, Rich Bowen wrote:
On Sun, 27 Oct 2002, William A. Rowe, Jr. wrote:
MAIN branch - current development, 2.1 stays here.
\--- APACHE_2_0_BRANCH [when we declare 2.1, we 'freeze' 2.0]
\--- APACHE_2_2_BRANCH [as we prepare to release 2.2, we branch]
I have had very
On Mon, 14 Oct 2002, Ian Holsman wrote:
I was wondering if anyone knows of something (preferably using openSSH)
which would allow Apache to authenticate via a SSH keypair.
what i would like ideally is for the browser to use the
passwords/pass-phrases of the ssh-agent running on the local
The ssh tools don't export the operations (signing, checking
signatures).
I looked into teases them out out of the code, for example authfd.c has
the signing code. One could create a command to bootstrap an
authenticated
session and then hand it off to the browser. Bridging auth to unlocked
I was wondering if anyone knows of something (preferably using openSSH)
which
would allow Apache to authenticate via a SSH keypair.
what i would like ideally is for the browser to use the
passwords/pass-phrases of the ssh-agent running on the local machine
to execute something remotely without
On Mon, 14 Oct 2002, Ian Holsman wrote:
I was wondering if anyone knows of something (preferably using openSSH)
which would allow Apache to authenticate via a SSH keypair. what i would
like ideally is for the browser to use the passwords/pass-phrases of the
ssh-agent running on the local
At 11:11 PM 10/1/2002, Jerry Baker wrote:
Currently, authentication is broken with the standard Windows config file and current
HEAD. Where is the documentation on the complete mess-up of the auth modules and how
to get it working again?
The documentation is not complete, nor hooked up
fixed the problem.
Please accept my apologies for the spam. The problem is not with DAV,
but with LimitExcept GET HEAD POST. When I remove the LimitExcept
directive, basic authentication works again. Makes no difference whether
Dav On or Dav Off.
Right. You were saying require
. Turning off DAV
fixed the problem.
Please accept my apologies for the spam. The problem is not with DAV,
but with LimitExcept GET HEAD POST. When I remove the LimitExcept
directive, basic authentication works again. Makes no difference whether
Dav On or Dav Off.
Right. You were saying
* Jerry Baker wrote:
Except for that directory is configured to require authentication. See
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13218
Location sections override Directory, see
http://httpd.apache.org/docs-2.0/sections.html#mergin
Sorry, I can't believe, that it worked ever
André Malo says:
* Jerry Baker wrote:
Except for that directory is configured to require authentication. See
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13218
Location sections override Directory, see
http://httpd.apache.org/docs-2.0/sections.html#mergin
Sorry, I can't believe
André Malo says:
Sorry, I can't believe, that it worked ever before the way you
described. Are you sure, that you've changed nothing else?
So Location matches are even more important than .htaccess matches? That
doesn't make sense. I would think that a directive in .htaccess is
always more
André Malo says:
Sorry, I can't believe, that it worked ever before the way you
described. Are you sure, that you've changed nothing else?
If there's no way to have a LimitExcept *and* separate directories
requiring authentication for everything, how in the world could you have
a DAV enabled
YES!
The pattern is:
VirtualHost
Directory (and .htaccess'es within those directories)
Files
Location
with the Limit[Except]s parsed in the appropriate container.
We repeat Location because the original Location could
have changed in translate_name, and yes, the URI permissions
On Wed, 2 Oct 2002, William A. Rowe, Jr. wrote:
YES!
All that merging stuff is true. But let's go back to the original
problem:
Location /
limitexcept GET
require valid-user
/limitexcept
/location
directory /
require valid-user
/directory
This has the effect of leaving GET unrestricted,
Joshua Slive says:
This has the effect of leaving GET unrestricted, according to the bug
report. Is this correct behavior? It seems like, since the other methods
are not change by the limitexcept, the require should still apply to
them.
That's what I thought at first, but there are two
Joshua Slive says:
This has the effect of leaving GET unrestricted, according to the bug
report. Is this correct behavior? It seems like, since the other methods
are not change by the limitexcept, the require should still apply to
them.
I agree. The LimitExcept directive implies that the
* Jerry Baker wrote:
If there's no way to have a LimitExcept *and* separate directories
requiring authentication for everything, how in the world could you
have a DAV enabled server while still being able to restrict
directories with authentication requirements?
There are several ways
* André Malo wrote:
# or: use advantages of PCRE
Location /(?!secret)
which have to be turned on, of course
Location ~ /(?!secret)
[...]
nd
On Wednesday, October 2, 2002, at 08:07 PM, Joshua Slive wrote:
Location /
limitexcept GET
require valid-user
/limitexcept
/location
directory /
require valid-user
/directory
This has the effect of leaving GET unrestricted, according to the bug
report. Is this correct behavior?
Hi,
Please refer to my earlier post regarding 304 response and the
Authentication-Info header. I am resending it in the hope of
receiving an authoratitive response.
Is Authentication-Info header (as defined in RFC-2617) for
Digest-authentication considered Entity-header? When Apache retuns
Currently, authentication is broken with the standard Windows config
file and current HEAD. Where is the documentation on the complete
mess-up of the auth modules and how to get it working again?
Thanks.
--
Jerry Baker
Jerry Baker says:
Yet, when I access that directory, I am just given an empty directory
listing. No prompt for a username or pass.
Nevermind. It's just something else that DAV broke. Turning off DAV
fixed the problem.
--
Jerry Baker
. The problem is not with DAV,
but with LimitExcept GET HEAD POST. When I remove the LimitExcept
directive, basic authentication works again. Makes no difference whether
Dav On or Dav Off.
--
Jerry Baker
Jerry Baker says:
Currently, authentication is broken with the standard Windows config
file and current HEAD. Where is the documentation on the complete
mess-up of the auth modules and how to get it working again?
Perhaps I should be more clear. I have a directory containing an
.htaccess
Is Authentication-Info header (as defined in RFC-2617) for
Digest-authentication considered Entity-header? When Apache retuns a
304 Not Modified, it simply includes WWW-Authenticate and
Proxy-Authenticate among the authentication related headers
(http_protocol.c:1609 for Apache2
Hi there!
I am interested in the integrity protection, an option of the digest
authentication described in RFC 2617.
mod_auth_digest implements the default Quality of Protection qop=auth,
which doesn't provide integrity protection.
Is someone working on the implementaion of the integrity
Hi there!
I am interested in the integrity protection, an option of the digest
authentication described in RFC 2617.
mod_auth_digest implements the default Quality of Protection qop=auth,
which doesn't provide integrity protection.
Is someone working on the implementaion of the integrity
I recently ran into an issue with non-ASCII user names in LDAP-based authentication
-- both via the Apache 1.3.x auth_ldap module from www.rudedog.org and with
the httpd-ldap sub-project for Apache 2.0.x.
This issue is rather nicely documented in:
http://www.rudedog.org/pipermail/auth_ldap
. This will enable AUTH_LDAP to get more
exposure as an external module, allow it to be included in future
releases of Apache 2 for testing and stabilization, and make sure that
it is not overlooked in future development. LDAP is an important
authentication method and should be supported in Apache
and into experimental. This will enable AUTH_LDAP to get more
exposure as an external module, allow it to be included in future
releases of Apache 2 for testing and stabilization, and make sure that
it is not overlooked in future development. LDAP is an important
authentication method and should
On Tue, Aug 27, 2002 at 05:25:25PM -0700, Greg Stein wrote:
It would seem that changes to the directives would be easy, and we could
also deprecate older directives. In all cases, we'd change our .conf files
and the doc, issue warnings for old usage, and then just wait a while
before removing
On Wed, Aug 28, 2002 at 01:59:29AM -0700, Justin Erenkrantz wrote:
On Tue, Aug 27, 2002 at 05:25:25PM -0700, Greg Stein wrote:
It would seem that changes to the directives would be easy, and we could
also deprecate older directives. In all cases, we'd change our .conf files
and the doc,
I don't want to add it in and then have to back it out because people
didn't realize that it is going to hose existing configs.
Justin - you want me to commit this
http://www.webweaving.org/~dirkx/aaa.tgz simplication first ? I've held
back as we where releasing .40. That should make your
On Wed, Aug 28, 2002 at 11:19:43AM +0200, Dirk-Willem van Gulik wrote:
I don't want to add it in and then have to back it out because people
didn't realize that it is going to hose existing configs.
Justin - you want me to commit this
http://www.webweaving.org/~dirkx/aaa.tgz
Hmm. Crap. I'm looking at mod_auth_dbm.c. Damn... it appears that *both*
mod_auth and mod_auth_dbm define the AuthUserFile and AuthGroupFile
directives.
Yes - this is the main reason I started the www.apache.org/~dirkx/aaa.tgz
simplification.
Beats the crap outta me how that happens to
On Wed, Aug 28, 2002 at 11:19:43AM +0200, Dirk-Willem van Gulik wrote:
I don't want to add it in and then have to back it out because people
didn't realize that it is going to hose existing configs.
Justin - you want me to commit this
http://www.webweaving.org/~dirkx/aaa.tgz
Hi -
-- Original Message --
Reply-To: [EMAIL PROTECTED]
Date: Wed, 28 Aug 2002 04:50:52 -0700
From: Justin Erenkrantz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: authentication rewrite
I'm not sure I like mod_authz_dbm.c either. Hmm. But, frankly, I
just can't come up with something
On Wed, Aug 28, 2002 at 04:50:52AM -0700, Justin Erenkrantz wrote:
I'm beginning to think that we're going to lose all hope of
maintaining backwards compat with the current 2.0 auth. But, as
Greg said, I definitely think that we're going is going to be an
awfully nice place. -- justin
If
On Wed, Aug 28, 2002 at 10:42:01AM -0700, Aaron Bannert wrote:
On Wed, Aug 28, 2002 at 04:50:52AM -0700, Justin Erenkrantz wrote:
I'm beginning to think that we're going to lose all hope of
maintaining backwards compat with the current 2.0 auth. But, as
Greg said, I definitely think that
On Wed, Aug 28, 2002 at 11:57:42AM -0700, Aaron Bannert wrote:
This is a big enough of a change that I would be willing to allow
for a branch to 2.1 at this point (not a full new repository, just
a cvs branch) so that you and others who are interested can work on
the auth stuff, and so we
On Wed, 28 Aug 2002, Aaron Bannert wrote:
On Wed, Aug 28, 2002 at 12:25:36PM -0700, Justin Erenkrantz wrote:
branches in CVS are awful (perhaps not so with SVN though).
I have only heard anecdotal evidence for this, but have actually
used cvs branches on other large and very successful
-To: [EMAIL PROTECTED]
Date: Wed, 28 Aug 2002 12:25:36 -0700
From: Justin Erenkrantz [EMAIL PROTECTED]
To: Aaron Bannert [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Going to 2.1? was Re: authentication rewrite
On Wed, Aug 28, 2002 at 11:57:42AM -0700, Aaron Bannert wrote:
This is a big enough
modules we currently support (which are almost never changed or
augmented) i suppose it wouldn't be a big deal. The ldap module,
My point is that I need to add another front end authentication
module (namely within mod_dav). I think it'd be pointless to
duplicate all of the backend work done
Justin Erenkrantz wrote:
Ideally, you could use the LDAP filters that most PAM implementations
use, but definitely allow the user to tweak them. I'd like to get
mod_auth_ldap ported to this, and if we move towards a provider-based
system, I think mod_auth_ldap should be moved back into the
+1
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
[EMAIL PROTECTED] Tuesday, August 27, 2002 4:20:43 AM
Justin Erenkrantz wrote:
Ideally, you could use the LDAP filters that most PAM
implementations
use, but
: authentication rewrite
+1
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
[EMAIL PROTECTED] Tuesday, August 27, 2002 4:20:43 AM
Justin Erenkrantz wrote:
Ideally, you could use the LDAP filters that most PAM
implementations
use
On Tue, Aug 27, 2002 at 09:27:16AM -0600, Brad Nicholes wrote:
modules, I would like to propose that we move AUTH_LDAP out of it's own
project and into experimental. This will enable AUTH_LDAP to get more
+1.
Especially if the auth rewrite occurs, auth_ldap would become much
simpler. --
On Tue, Aug 27, 2002 at 12:44:35PM -0400, Joshua Slive wrote:
I would be happier with a good system for integrating non-core modules,
such as an apache-rollup or a CPAN/freebsd ports like system. BUT, since
nobody seems willing to step-up and create such a system, I think it
would be a
On Tue, Aug 27, 2002 at 10:12:43AM -0400, [EMAIL PROTECTED] wrote:
than the current AAA modules. In a 'require group' world, it is very nice
to abstract this stuff out so backends can be re-used, and apache specific
logic can be centralized - as you have proposed. But it will be harder
to
Yeah, you hit the problem with stacking - authoritative. I'm not
sure how useful having multiple backends could be. I'd almost
suggest that something like a PAM backend would be much better and
allows a fairly standard configuration. (I know Dirk has a PAM
It is integrated into the PAM
Graham Leggett wrote:
Aaron Bannert wrote:
I would *love* to see this happen. I think a decoupling of modules
from the core httpd server would give us many benefits:
True, but keeping functionality out of the server until such a system
exists is a mistake. Any CPAN style system should
a big +1...
On Mon, Aug 26, 2002 at 11:44:32PM -0700, Justin Erenkrantz wrote:
...
My point is that I need to add another front end authentication
module (namely within mod_dav). I think it'd be pointless to
duplicate all of the backend work done in mod_auth* so that
mod_dav can
Hi -
-- Original Message --
Reply-To: [EMAIL PROTECTED]
Date: Tue, 27 Aug 2002 09:51:09 -0700
From: Justin Erenkrantz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: authentication rewrite
On Tue, Aug 27, 2002 at 10:12:43AM -0400, [EMAIL PROTECTED] wrote:
Without seeing use cases, it's
On Tue, Aug 27, 2002 at 02:43:24PM -0400, [EMAIL PROTECTED] wrote:
I could send a patch to your current code if that would be clearer - its
really pretty simple, but would allow the backends to get at least a little
more powerful (and would solve the ldap_prop case i illustrated above
On Tue, Aug 27, 2002 at 03:27:10PM -0700, Justin Erenkrantz wrote:
On Tue, Aug 27, 2002 at 02:43:24PM -0400, [EMAIL PROTECTED] wrote:
I could send a patch to your current code if that would be clearer - its
really pretty simple, but would allow the backends to get at least a little
more
On Tue, Aug 27, 2002 at 05:03:11PM -0700, Greg Stein wrote:
Put it in there, then :-)
I haven't really seen any objects so far. And hey... this *is* version
control. It can always be backed out :-)
I don't want to add it in and then have to back it out because people
didn't realize that it
On Tue, Aug 27, 2002 at 05:02:19PM -0700, Justin Erenkrantz wrote:
On Tue, Aug 27, 2002 at 05:03:11PM -0700, Greg Stein wrote:
Put it in there, then :-)
I haven't really seen any objects so far. And hey... this *is* version
control. It can always be backed out :-)
I don't want to add
I need to be able to get at the authentication backends to implement
some DAV enhancements - namely DAV has its own authentication model
(DAV ACL support). My idea would be to allow mod_dav to reuse the
aaa backends and just implement the client-facing bits there.
Therefore, I've begun to split
wrote:
I need to be able to get at the authentication backends to implement
some DAV enhancements - namely DAV has its own authentication model
(DAV ACL support). My idea would be to allow mod_dav to reuse the
aaa backends and just implement the client-facing bits there.
Therefore, I've begun
Does anyone have any answers here? Or am I asking this question
to the wrong list?
Thanks, Rob
-Original Message-
From: Rob Emanuele [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 3:27 PM
To: [EMAIL PROTECTED]
Subject: code sharing in authentication
I'm curious to the inner
On Mon, 10 Jun 2002, Rob Emanuele wrote:
I was wondering if they use each other or can use each other?
Can they share code? For example the mod_auth_digest module and
the mod_auth_mysql or mod_auth_dbm, can the latter modules make
use of the digest code?
As they're currently written, no,
I'm curious to the inner workings of the authentication modules
for 1.3 and 2.0.
I was wondering if they use each other or can use each other?
Can they share code? For example the mod_auth_digest module and
the mod_auth_mysql or mod_auth_dbm, can the latter modules make
use of the digest code
httpd2.0.35
server/protocol.c
Is there any reason why ap_get_basic_auth_pw() rejects
authentication itself if the client provides no Auth line? I can see a
theoretical reason, but it seems to me that the practical reasons not to do
this would outweigh that. If I specify a module
that modules there seem to implement both
authentication and authorization.
IMO this should be split. Auth and authz are
completely different things and it would be nice
to have different modules to do authentication
in a different way, but still utilize the same
authorization method.
To accomplish
William A. Rowe, Jr. wrote:
-1 (veto) for 2.0 development. I'd love to see this happen.
Not in the current cycle. I was actually contemplating an entire
split between the authn/authz storage and methods. But that can't
happen in this cycle either if we ever want to get to release.
From
release, and authn/authz hackers can go a little crazy on the
2.1 branch?
Bill
- Original Message -
From: Graham Leggett [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, September 09, 2001 8:06 AM
Subject: Re: Authentication and Authorization
William A. Rowe, Jr. wrote:
-1 (veto
Hi,
I've been going through the modules/aaa directory
and found that modules there seem to implement both
authentication and authorization.
IMO this should be split. Auth and authz are
completely different things and it would be nice
to have different modules to do authentication
Sander Striker wrote:
IMO this should be split. Auth and authz are
completely different things and it would be nice
to have different modules to do authentication
in a different way, but still utilize the same
authorization method.
I'm not sure if splitting them will accomplish
Sander Striker wrote:
IMO this should be split. Auth and authz are
completely different things and it would be nice
to have different modules to do authentication
in a different way, but still utilize the same
authorization method.
I'm not sure if splitting them will accomplish
[replying to my own msg]
Sander Striker wrote:
IMO this should be split. Auth and authz are
completely different things and it would be nice
to have different modules to do authentication
in a different way, but still utilize the same
authorization method.
I'm not sure if splitting
Sander Striker wrote:
I've been going through the modules/aaa directory
and found that modules there seem to implement both
authentication and authorization.
Yar, that's a right bugger. I have had a replacement
system in my head for a couple of years now, but it
requires some substantial
From: Sander Striker [EMAIL PROTECTED]
Sent: Friday, September 07, 2001 6:36 AM
I've been going through the modules/aaa directory
and found that modules there seem to implement both
authentication and authorization.
IMO this should be split. Auth and authz are
completely different
201 - 278 of 278 matches
Mail list logo
