applications to authenticate and/or authorize clients.
A fair amount of code was taken from or at least based on
mod_proxy_fcgi, with a smaller amount taken from mod_fcgid.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1515403 13f79535-47bb-0310-9956-ffa450edef68
by the big ldap revert r1150179.
Original commit log:
Use APR_ADDTO instead of APR_SETVAR or direct
variable assignment.
...
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1150231 13f79535-47bb-0310-9956-ffa450edef68
Incorporate the ap_ldap incomplete API, as there is no interest or effort
at APR to make this a complete abstraction, and it was voted 'off the island'
with APR 2.0. This will allow httpd 2.3 to build against either apr-2.0
or apr+util 1.x.
This also reverts part of r1142938, which needs to be re-done.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/revert-ap-ldap@1150172 13f79535-47bb-0310-9956-ffa450edef68
via the MOD_XXX_LDADD variables.
Use APR_ADDTO instead of APR_SETVAR or direct
variable assignment.
This is especially useful when building mod_lua
or mod_deflate against a lua resp. libz which
are installed in non-standard locations.
One can add "-R ..." to MOD_LUA_LDADD and
MOD_DEFLATE_LDADD before configure to fix
the RPATH/RUNPATH of those modules.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1142938 13f79535-47bb-0310-9956-ffa450edef68
at APR to make this a complete abstraction, and it was voted 'off the island'
with APR 2.0. This will allow httpd 2.3 to build against either apr-2.0
or apr+util 1.x.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1129808 13f79535-47bb-0310-9956-ffa450edef68
Note: I've attempted to work through the Windows and Netware build files,
but if those with such systems could repair any damage, that would be
appreciated.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@709839 13f79535-47bb-0310-9956-ffa450edef68
Merge from branches/authz-dev
Basically here is a list of what has been done:
- Convert all of the authz modules from hook based to provider based
- Remove the ap_requires field from the core_dir_config structure
- Remove the function ap_requires() since its functionality is no
longer supported or necessary in the refactoring
- Remove the calls to ap_some_auth_required() in the core request
handling to allow the hooks to be called in all cases.
- Add the new module mod_authz_core which will act as the authorization
provider vector and contain common authz directives such as 'Require',
'Reject' and '<RequireAlias>'
- Add the new module mod_authn_core which will contain common
authentication directives such as 'AuthType', 'AuthName' and
'<AuthnProviderAlias>'
- Move the check for METHOD_MASK out of the authz providers and into
the authz_core provider vector
- Define the status codes that can be returned by the authz providers
as AUTHZ_DENIED, AUTHZ_GRANTED and AUTHZ_GENERAL_ERROR
- Remove the 'Satisfy' directive
- Implement the '<RequireAll>', '<RequireOne>' block directives to
handle the 'and' and 'or' logic for authorization.
- Remove the 'AuthzXXXAuthoritative' directives from all of the authz
providers
- Implement the 'Reject' directive that will deny authorization if the
argument is true
- Fold the 'Reject' directive into the '<RequireAll>', '<RequireOne>'
logic
- Reimplement the host based authorization functionality provided by
'allow', 'deny' and 'order' as authz providers
- Remove the 'allow', 'deny' and 'order' directives
- Merge mod_authn_alias into mod_authn_core
- Add '<RequireAlias>' functionality which is similar to
'<AuthnProviderAlias>' but specific to authorization aliasing
- Remove all of the references to the 'authzxxxAuthoritative'
directives from the documentation
- Remove the 'Satisfy' directive from the documentation
- Remove 'Allow', 'Deny', 'Order' directives from the documentation
- Document '<RequireAll>', '<RequireOne>', 'Reject' directives
- Reimplement the APIs ap_auth_type(), ap_auth_name() as optional
functions and move the actual implementation into mod_authn_core
- Reimplement the API ap_some_auth_required() as an optional function
and move the actual implementation into mod_authz_core
Major Changes:
- Added the directives <RequireAll>, <RequireOne>, <RequireAlias>,
Reject
- Expanded the functionality of the directive 'Require' to handle all
authorization and access control
- Added the new authz providers 'env', 'ip', 'host', 'all' to handle
host-based access control
- Removed the directives 'Allow', 'Deny', 'Order', 'Satisfy',
'AuthzXXXAuthoritative'
- Removed the ap_require() API
- Moved the directives 'AuthType', 'AuthName' out of mod_core and into
mod_authn_core
- Moved the directive 'Require' out of mod_core and into
mod_authz_core
- Merged mod_authn_alias into mod_authn_core
- Renamed mod_authz_dbm authz providers from 'group' and 'file-group'
to 'dbm-group' and 'dbm-file-group'
Benefits:
- All authorization and access control is now handle through two
directives, 'Require' and 'Reject'
- Authorization has been expanded to allow for complex 'AND/OR' control
logic through the directives '<RequireAll>' and '<RequireOne>'
- Configuration is now much simpler and consistent across the board
- Other modules like mod_ssl and mod_proxy should be able to plug into
and take advantage of the same provider based authorization mechanism
by implementing their own providers
Issues:
- Backwards compatibility between 2.2 and 2.3 configurations will be
broken in the area of authorization and access control due to the fact
that the directives 'allow', 'deny', 'order' and 'satisfy' have been
removed. When moving from 2.2 to 2.3 these directives will have to be
changed to 'Require all granted', 'Require all denied' or some variation
of the authz host-based providers.
- Existing third party authorization modules will have to adapt to the
new structure.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@368027 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
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
the DSO link problems for DAV and the new aaa modules by moving the
provider code into the core of the server and generalizing them to be
used by any code.
Remove the auth{nz}_*_provider functions as they are no longer needed.
Change the dav_*_provider functions to wrap the ap_*_provider functions
as they have a bit more of a historical precedent that we should keep
around.
Reviewed by: John K. Sterling <john@sterls.com> (in concept)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96919 13f79535-47bb-0310-9956-ffa450edef68
do not have to re-implement basic auth and to allow mod_auth_digest (and
other modules) to leverage the authn backends.
Adds AuthBasicProvider and AuthDigestProvider directives.
This also moves a lot of the basic auth handling code inside of mod_auth_basic
(but does not remove the code in server/protocol.c - that will have to wait
for a version bump so that we don't totally bust old modules).
This patch incorporates code review comments by Greg Stein.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96739 13f79535-47bb-0310-9956-ffa450edef68
All modules are reorganized under the following scheme:
- mod_auth_*: Front-end (basic, digest)
- mod_authn_*: Authentication (anon, dbm, default, file)
- mod_authz_*: Authorization (dbm, default, groupfile, host, user)
This passes the httpd-test suite when it accounts for the renaming of
aaa modules.
Originally written by: Dirk-Willem van Gulik
Completed by: Justin Erenkrantz
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96728 13f79535-47bb-0310-9956-ffa450edef68
Lars) and ample warning has been posted to dev@httpd.
mod_auth_dbm should be able to take over all functionality of mod_auth_db
with the AuthDBMType directive.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93010 13f79535-47bb-0310-9956-ffa450edef68
(the AC_* way of doing what Martin committed)
- Fix the configuration check for mod_auth_digest so that:
- Everything is on separate lines so that the preprocessor doesn't scream
- It adds the path to APR. (APR_SOURCE_DIR looks right, but I'm not sure.)
By the time the modules are configured, the CPPFLAGS and such are not
setup to point at APR. This should probably be rectified and then this
can be taken out - so you could assume that apr.h is in your CPPFLAGS
somewhere when configuring the modules.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90392 13f79535-47bb-0310-9956-ffa450edef68
rather than in libdb. Also, be more precise in telling what is actually
checked for (we are NOT testing for main(), but we are testing for dbopen(),
right?).
Without the first fix, configuration would fail completely for FreeBSD
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90391 13f79535-47bb-0310-9956-ffa450edef68
by allowing a module to disable itself if its prerequisites are not met.
This introduces the subtle nuance that if you request a module and you
don't meet its prerequisites, it'll refuse to build itself.
mod_ssl exits if its prerequisites are not met.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90261 13f79535-47bb-0310-9956-ffa450edef68
and apr-util, allow it to be overridden by the configure command-line
(default="--silent") and introduce LT_LDFLAGS to replace what we were
formally abusing as LTFLAGS.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89094 13f79535-47bb-0310-9956-ffa450edef68
variables CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS and LIBS by moving
the configure additions to EXTRA_* variables. Also, allow the user
to specify NOTEST_* values for all of the above, which eliminates the
need for THREAD_CPPFLAGS, THREAD_CFLAGS, and OPTIM. Fix the setting
of INCLUDES and EXTRA_INCLUDES. Check flags as they are added to
avoid pointless duplications. Fix the order in which flags are given
on the compile and link lines.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88960 13f79535-47bb-0310-9956-ffa450edef68
the file name, and it is easier to automate the installation
process (generating LoadModule directives from the module filenames).
Next step is to remove the 4th argument to the APACHE_MODULE macro
completely and require people to use the matching names, and to
reduce the LoadModule directive to 1 argument.... Objections?
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88189 13f79535-47bb-0310-9956-ffa450edef68
