GSSAPI::Status - methods for handlings GSSAPI statuses
use GSSAPI;
$status = GSSAPI::Status->new(GSS_S_COMPLETE, 0);
if (GSS_ERROR($status->major)) {
die "a horrible death";
}
if (! $status) { # another way of writing the above
die "a horrible death";
}
$status = $some_GSSAPI->someop($args1, etc);
if ($status) {
foreach ($status->generic_message, $status->specific_message) {
print "GSSAPI error: $_\n";
}
die "help me";
}
GSSAPI::Status objects are returned by most other GSSAPI operations.
Such statuses consist of a GSSAPI generic code and, for most
operations, a mechanism specific code. These numeric codes can be
accessed via the methods major and minor. The standard textual
messages that go with the current status can be obtained via the
generic_message and specific_message methods. Each of these
returns a list of text which should presumably be displayed in
order.
The generic code part of a GSSAPI::Status is composed of three
subfields that can be accessed with the GSS_CALLING_ERROR,
GSS_ROUTINE_ERROR, and GSS_SUPPLEMENTARY_INFO functions. The
returned values can be compared against the constants whose names
start with GSS_S_ if your code wants to handle particular errors
itself. The GSS_ERROR function returns true if and only if the
given generic code contains neither a calling error nor a routine
error.
When evaluated in a boolean context, a GSSAPI::Status object
will be true if and only if the major status code is GSS_S_COMPLETE.
When evaluated in a string contect, a GSSAPI::Status object will
return the generic and specific messages all joined together with
newlines. This may or may not make die $status work usefully.
The base objects are currently implmented as a blessed C structure
containing the major and minor status codes. It should probably
be a blessed array or hash instead, thereby cutting down on the
amount of C code involved and making it more flexible.
Philip Guenther <pguen@cpan.org>
perl(1)
RFC2743
|