now populates r->user with the (possibly unauthenticated) user,
and mod_auth_digest returns 500 when a provider returns
AUTH_GENERAL_ERROR
Reviewed by: justin
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@102719 13f79535-47bb-0310-9956-ffa450edef68
not when linking modules or support programs.
* modules/aaa/config.m4, modules/arch/win32/config.m4,
modules/cache/config.m4, modules/echo/config.m4,
modules/filters/config.m4, modules/generators/config5.m4,
modules/metadata/config.m4: Don't add -export-dynamic to LT_LDFLAGS.
* modules/mappers/config9.m4: Add -export-dynamic to HTTPD_LDFLAGS
when mod_so is enabled.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@102235 13f79535-47bb-0310-9956-ffa450edef68
the older .dbg format symbols are not worth the interference with
generating complete .pdb symbolic debugging databases.
This patch further eliminates pdbtype:sept flags that interfere with
deciphering local symbols and type information.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@98970 13f79535-47bb-0310-9956-ffa450edef68
fairly redundant when you retain rich .pdb debugging symbol files. We
have rarely used them, and generally .dbg and .pdb files prove much more
useful for the cases we have.
While eliminating /map files, we are also shrinking the size of the .dbg
files by stripping 'private' symbol information. Really this means less
rich diagnostics from Dr. Watson on NT or Win9x when they query the .dbg
symbols in creating a DrWatson log file. But it's more than compensated
for on newer OS'es where Dr. Watson will query the .pdb symbols, on all
Win32 flavors when WinDbg is used with the .pdb symbols, and the fact that
the distribution of binary symbols will use less bandwidth when less
information is duplicated from the .pdb format into the .dbg files.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@98743 13f79535-47bb-0310-9956-ffa450edef68
was badness. Twist this puppy to .dbr, the only name I could invent that
doesn't look like any database file extension I recall.
It stands for .dbg rebased.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@98712 13f79535-47bb-0310-9956-ffa450edef68
Our docs say about AuthDigestDomain:
This directive should always be specified and contain at least the (set of)
root URI(s) for this space. Omitting to do so will cause the client to send
the Authorization header for every request sent to this server.
guessing the parameter is somewhat bogus. guess_domain() also resulted sometimes
in relative URIs, non-URI strings or empty strings, which caused a lot of
problems.
According to the docs, the domain parameter will be omitted now,
if not specified. This is exactly, what one would expect.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@98636 13f79535-47bb-0310-9956-ffa450edef68
and .dbg files (older debuggers and Dr. Watson-type utilities
on WinNT or Win9x don't support the newer .pdb flavor.)
[Allen Edwards, William Rowe]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@98596 13f79535-47bb-0310-9956-ffa450edef68
mod_authz_owner: forward port of require file-owner/file-group functionality
The goal of the module is to do all the neccessary file system work to
figure out username and groupname. "Require file-owner" is completely
resolved within the module. "file-group" is only determined there and the
groupname will be extracted from the stat call and stored within the
r->notes. Done that, the module will decline, so that the group database
modules (mod_authz_groupfile, mod_authz_dbm) can verify the groupname with
their lists.
Thus every group module that supports the file-group requirement must be
hooked after mod_authz_owner. They have to recognize "file-group" and read
the groupname from r->notes. (If there's no name stored, the modules should
ignore the file-group requirement). The backstopper module will do its work
in worst case.
not solved yet:
- the module doesn't work as one could expect if the file doesn't exist in
the first request round (consider MultiViews) (the 1.3 version has the
same problem). I played around with some subrequest techniques, but got
no helpful result. Is there any magic to recognize the actual resulting
filename (if there is)?
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@98281 13f79535-47bb-0310-9956-ffa450edef68
evaluate multiple "require group" directives even for DBM files.
this was always applicable for plain text group files.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@98180 13f79535-47bb-0310-9956-ffa450edef68
- remove superfluid #include
- remove no longer neccessary bitmask handling
- be more efficient if there are no groups for the user
- call ap_note_auth_failure instead of ap_note_basic_auth_failure
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@98178 13f79535-47bb-0310-9956-ffa450edef68
- The weird bit mask handling is not really neccessary.
- call ap_note_auth_failure instead of ap_note_basic_auth_failure
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@98177 13f79535-47bb-0310-9956-ffa450edef68
files. This is done by looking up first "$user:$realm" and if no success
then $user as key.
The patch also restores the possibility of group files only
($user -> group,group... or "$user:$realm" -> group,group...).
That got somehow lost during the auth rewrite.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@98175 13f79535-47bb-0310-9956-ffa450edef68
authentication requests.
e.g.:
AuthType Digest
AuthName foo
require user nd
with no mod_auth_digest present; or consider a TP digest module
with Authoritative funcionality etc.
It's still a question whether we should throw a 500 instead of 401
in that case...
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@98167 13f79535-47bb-0310-9956-ffa450edef68
key is "$user:$realm" (perl speaking), the value is the MD5-hash,
optionally followed by a colon and other garbage.
Note that currently there's no tool to create such databases.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@98144 13f79535-47bb-0310-9956-ffa450edef68
AuthDigestProvider dbm? This results in a great kaboom. The patch makes
apache throw an error, if someone tries a provider, that doesn't support
the particular auth scheme.
Submitted by: Andre Malo <nd@perlig.de>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@97802 13f79535-47bb-0310-9956-ffa450edef68
not only break, if access is granted. It should also break, if
access was *denied* by one provider. To be safe, it has to break
also, if an error occured. So the patch turns the condition around
and continues only, if the user was not found.
I find it also weird, that if auth was denied (by password
usually), the AuthBasicAuthoritative behaviour can override that
by "passing to lower modules". The patch changes that behaviour,
too.
Justin notes:
I'm kind of on the fence about that. I was originally thinking
optimistically, but yeah, it might make sense to do it
pessimistically. If there's any error, bug out.
Submitted by: Andre Malo <nd@perlig.de>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@97801 13f79535-47bb-0310-9956-ffa450edef68
