Apache-OWA
view release on metacpan or search on metacpan
###################################################################
sub auth_handler ($) {
$r = Apache::Request->new( shift );
($DEBUG) = $r->dir_config('DEBUG');
$r->warn('Apache::OWA::auth_handler start.') if ($DEBUG > 1);
my ($sent_pw, $user, $db);
# get username & password
(my $res, $sent_pw) = $r->get_basic_auth_pw;
return $res if $res != OK;
$user = $r->connection->user;
# need both username & password
unless ( $user && $sent_pw) {
$r->note_basic_auth_failure;
$r->warn('Apache::OWA::auth_handler exit(AUTH_REQUIRED)') if ($DEBUG > 1);
return AUTH_REQUIRED;
}
# get configuration
if ($r->dir_config('DB_AUTH')) {
$r->dir_config('DB') ?
Useful while developing procedures.
2 - Heavy debugging of Apache::OWA inetrnal stuff.
PerlAuthenHandler Apache::OWA
This invokes my special authentication handler that can do a few clever
things. Then it passes control on to the content-handler, so if you
use this you don't need to specify "PerlHandler Apache::OWA". It
might also be useful in combination with "PerlSetVar SCHEMA".
PerlSetVar DB_AUTH true
Uses database uername and password to authenticate. If no DAD-string
is set, it can also use the supplied username and password to execute
your PL/SQL application.
PerlSetVar DB_PROC_AUTH schema.function
Uses an arbitrary PL/SQL procedure or function to authenticate.
The procedure should take the username and password as arguments
and return 0 for success and more than 0 for failure.
PerlSetVar NEVER_USE_WEIRD_TYPES 1
Only set this if you know that you never use multi-value CGI variables
that need to be mapped to PL/SQL Table datatypes. Finding these datatypes
is some extra work and will slow down executions a little bit.
For further documentation see the README.
This module has only been tested (by me) on Solaris 2.6, Oracle 8.0.5, 8.1.5, 8.1.6.
INSTALLATION
============
Unpack the file, run "perl Makefile.PL", "make" and then "make install".
"make test" does nothing useful at the moment.
Next you need to edit your httpd.conf. Here is a sample configuration where
the database user and password is provided. Use this for applications that use
their own authentication-mechanisms, or that don't need any authenticaton.
<Location /dir/> can be anything you want. Example:
<Location /scott/ >
SetHandler perl-script
PerlHandler Apache::OWA
PerlSetVar DAD oracle1:scott:tiger
</Location>
SetHandler perl-script
PerlHandler Apache::OWA
PerlSetVar DAD oracle1:scott:tiger
PerlSetVar SCHEMA oas_public
</Location>
the same url would now execute "oas_public.cgi_print_env".
Next, a configuration where all users have to log in using their Oracle
user-id and password, and applications are executed under their user-id in the
database, but the schema works the same as adbove. This means that they need
execute permissions on the application, proper synonyms set up and "create
session" priveliges.
<Location /ows_db_auth/ >
AuthName ows_db_auth
AuthType Basic
PerlAuthenHandler Apache::OWA
Require valid-user
PerlSetVar DB oracle1 # defaults to $ORACLE_SID
PerlSetVar SCHEMA oas_public
PerlSetVar DB_AUTH true
</Location>
The final method is authentication using a custom database function that takes
the username and password as arguments and then returns zero for success and
non-zero for failure. The format of the DB_PROC_AUTH variable is:
<schema>.<function>. Remember that the user in the DAD-string needs permission
to execute this function.
<Location /ows_db_proc_auth/*>
AuthName db_proc_auth
AuthType Basic
PerlAuthenHandler Apache::OWA
Require valid-user
PerlSetVar DAD oracle:user:password
PerlSetVar DB_PROC_AUTH user.authen
</Location>
To get verbose errors sent to the brovser, use "PerlSetVar DEBUG 1" in your
<Location ...>. To debug Apache::OWA itself set DEBUS to 2.
BUGS
====
Probably lots. Here's the ones I know about.
( run in 1.103 second using v1.01-cache-2.11-cpan-49f99fa48dc )