Provided by: libnet-openid-consumer-perl_1.18-1_all bug

NAME

       Net::OpenID::Consumer - Library for consumers of OpenID identities

VERSION

       version 1.18

SYNOPSIS

         use Net::OpenID::Consumer;

         my $csr = Net::OpenID::Consumer->new(
           ua    => LWPx::ParanoidAgent->new,
           cache => Cache::File->new( cache_root => '/tmp/mycache' ),
           args  => $cgi,
           consumer_secret => ...,
           required_root => "http://site.example.com/",
           assoc_options => [
             max_encrypt => 1,
             session_no_encrypt_https => 1,
           ],
         );

         # Say a user enters "bradfitz.com" as his/her identity.  The first
         # step is to perform discovery, i.e., fetch that page, parse it,
         # find out the actual identity provider and other useful information,
         # which gets encapsulated in a Net::OpenID::ClaimedIdentity object:

         my $claimed_identity = $csr->claimed_identity("bradfitz.com");
         unless ($claimed_identity) {
           die "not actually an openid?  " . $csr->err;
         }

         # We can then launch the actual authentication of this identity.
         # The first step is to redirect the user to the appropriate URL at
         # the identity provider.  This URL is constructed as follows:
         #
         my $check_url = $claimed_identity->check_url(
           return_to  => "http://example.com/openid-check.app?yourarg=val",
           trust_root => "http://example.com/",

           # to do a "checkid_setup mode" request, in which the user can
           # interact with the provider, e.g., so that the user can sign in
           # there if s/he has not done so already, you will need this,
           delayed_return => 1

           # otherwise, this will be a "check_immediate mode" request, the
           # provider will have to immediately return some kind of answer
           # without interaction
         );

         # Once you redirect the user to $check_url, the provider should
         # eventually redirect back, at which point you need some kind of
         # handler at openid-check.app to deal with that response.

         # You can either use the callback-based API (recommended)...
         #
         $csr->handle_server_response(
             not_openid => sub {
                 die "Not an OpenID message";
             },
             setup_needed => sub {
                 if ($csr->message->protocol_version >= 2) {
                     # (OpenID 2) retry request in checkid_setup mode (above)
                 }
                 else {
                     # (OpenID 1) redirect user to $csr->user_setup_url
                 }
             },
             cancelled => sub {
                 # User hit cancel; restore application state prior to check_url
             },
             verified => sub {
                 my ($vident) = @_;
                 my $verified_url = $vident->url;
                 print "You are $verified_url !";
             },
             error => sub {
                 my ($errcode,$errtext) = @_;
                 die("Error validating identity: $errcode: $errcode");
             },
         );

         # ... or handle the various cases yourself
         #
         unless ($csr->is_server_response) {
             die "Not an OpenID message";
         } elsif ($csr->setup_needed) {
              # (OpenID 2) retry request in checkid_setup mode
              # (OpenID 1) redirect/link/popup user to $csr->user_setup_url
         } elsif ($csr->user_cancel) {
              # User hit cancel; restore application state prior to check_url
         } elsif (my $vident = $csr->verified_identity) {
              my $verified_url = $vident->url;
              print "You are $verified_url !";
         } else {
              die "Error validating identity: " . $csr->err;
         }

DESCRIPTION

       This is the Perl API for (the consumer half of) OpenID, a distributed identity system
       based on proving you own a URL, which is then your identity.  More information is
       available at:

         http://openid.net/

CONSTRUCTOR

       new
            my $csr = Net::OpenID::Consumer->new( %options );

           The following option names are recognized: "ua", "cache", "args", "consumer_secret",
           "minimum_version", "required_root", "assoc_options", and "nonce_options" in the
           constructor.  In each case the option value is treated exactly as the argument to the
           corresponding method described below under Configuration.

METHODS

   State
       $csr->message($key)
           Returns the value for the given key/field from the OpenID protocol message contained
           in the request URL parameters (i.e., the value for the URL parameter "openid.$key").
           This can only be used to obtain core OpenID fields not extension fields.

           Calling this method without a $key argument returns a Net::OpenID::IndirectMessage
           object representing the protocol message, at which point the various object methods
           are available, including

            $csr->message->protocol_version
            $csr->message->has_ext
            $csr->message->get_ext

           Returns undef in either case if no URL parameters have been supplied (i.e., because
           args() has not been initialized) or if the request is not an actual OpenID message.

       $csr->err
           Returns the last error, in form "errcode: errtext", as set by the various handlers
           below.

       $csr->errcode
           Returns the last error code.  See Error Codes below.

       $csr->errtext
           Returns the last error text.

       $csr->json_err
           Returns the last error code/text in JSON format.

   Configuration
       $csr->ua($user_agent)
       $csr->ua
           Getter/setter for the LWP::UserAgent (or subclass) instance which will be used when
           direct HTTP requests to a provider are needed.  It's highly recommended that you use
           LWPx::ParanoidAgent, or at least read its documentation so you're aware of why you
           should care.

       $csr->cache($cache)
       $csr->cache
           Getter/setter for the cache instance which is used for storing fetched HTML or XRDS
           pages, keys for associations with identity providers, and received response_nonce
           values from positive provider assertions.

           The $cache object can be anything that has a ->get($key) and
           ->set($key,$value[,$expire]) methods.  See URI::Fetch for more information.  This
           cache object is passed to URI::Fetch directly.

           Setting a cache instance is not absolutely required, But without it, provider
           associations will not be possible and the same pages may be fetched multiple times
           during discovery.  It will also not be possible to check for repetition of the
           response_nonce, which may then leave you open to replay attacks.

       $csr->consumer_secret($scalar)
       $csr->consumer_secret($code)
            $code = $csr->B<consumer_secret>; ($secret) = $code->($time);

           The consumer secret is used to generate self-signed nonces for the return_to URL, to
           prevent spoofing.

           In the simplest (and least secure) form, you configure a static secret value with a
           scalar.  If you use this method and change the scalar value, any outstanding requests
           from the last 30 seconds or so will fail.

           You may also supply a subref that takes one argument, $time, a unix timestamp and
           returns a secret.

           Your secret may not exceed 255 characters.

           For the best protection against replays and login cross-site request forgery,
           consumer_secret should additionally depend on something known to be specific to the
           client browser instance and not visible to an attacker.  If "SSH_SESSION_ID" is
           available, you should use that.  Otherwise you'll need to set a (Secure) cookie on the
           (HTTPS) page where the signin form appears in order to establish a pre-login session,
           then make sure to change this cookie upon successful login.

       $csr->minimum_version(2)
       $csr->minimum_version
           Get or set the minimum OpenID protocol version supported. Currently the only useful
           value you can set here is 2, which will cause 1.1 identifiers to fail discovery with
           the error "protocol_version_incorrect" and responses from version 1 providers to not
           be recognized.

           In most cases you'll want to allow both 1.1 and 2.0 identifiers, which is the default.
           If you want, you can set this property to 1 to make this behavior explicit.

       $csr->args($ref)
       $csr->args($param)
       $csr->args
           Can be used in 1 of 3 ways:

           1.  Set the object from which URL parameter names and values are to be retrieved:

                $csr->args( $reference )

               where $reference is either an unblessed "HASH" ref, a "CODE" ref, or some kind of
               "request object" — the latter being either a CGI, Apache, Apache::Request,
               Apache2::Request, or Plack::Request object.

               If you pass in a "CODE" ref, it must,

               •   given a single parameter name argument, return the corresponding parameter
                   value, and,

               •   given no arguments at all, return the full list of parameter names from the
                   request.

               If you pass in an Apache (mod_perl 1.x interface) object and this is a POST
               request, you must not have already called "$r->content" as this routine will be
               making said call itself in order to extract the request parameters.

           2.  Get a parameter value:

                my $foo = $csr->args("foo");

               When given an unblessed scalar, it retrieves the value.  It croaks if you haven't
               defined a way to get at the parameters.

               Most callers should instead use the "message" method above, which abstracts away
               the need to understand OpenID's message serialization.

           3.  Get the parameter getter:

                my $code = $csr->args;

               this being a subref that takes a parameter name and returns the corresponding
               value.

               Most callers should instead use the "message" method above with no arguments,
               which returns an object from which extension attributes can be obtained by their
               documented namespace URI.

       $csr->required_root($url_prefix)
       $csr->required_root
           Gets or sets the string prefix that, if nonempty, all return_to URLs must start with.
           Messages with return_to URLS that don't match will be considered invalid (spoofed from
           another site).

       $csr->assoc_options(...)
       $csr->assoc_options
           Get or sets the hash of parameters that determine how associations with identity
           providers will be made.  Available options include:

           "assoc_type"
               Association type, (default 'HMAC-SHA1')

           "session_type"
               Association session type, (default 'DH-SHA1')

           "max_encrypt"
               (boolean) Use best encryption available for protocol version for both session type
               and association type.  This overrides "session_type" and "assoc_type"

           "session_no_encrypt_https"
               (boolean) Use an unencrypted session type if the ID provider URL scheme is
               "https:".  This overrides "max_encrypt" if both are set.

           "allow_eavesdropping"
               (boolean) Because it is generally a bad idea, we abort associations where an
               unencrypted session over a non-SSL connection is called for.  However the OpenID
               1.1 specification technically allows this, so if that is what you really want, set
               this flag true.  Ignored under protocol version 2.

       $csr->nonce_options(...)
       $csr->nonce_options
           Gets or sets the hash of options for how response_nonce should be checked.

           In OpenID 2.0, response_nonce is sent by the identity provider as part of a positive
           identity assertion in order to help prevent replay attacks.  In the
           check_authentication phase, the provider is also required to not authenticate the same
           response_nonce twice.

           The relying party is strongly encouraged but not required to reject multiple
           occurrences of a nonce (which can matter if associations are in use and there is no
           check_authentication phase).  Relying party may also choose to reject a nonce on the
           basis of the timestamp being out of an acceptable range.

           Available options include:

           "nocheck"
               (boolean) Skip response_nonce checking entirely.  This overrides all other
               nonce_options.

               "nocheck" is implied and is the only possibility if $csr->cache is unset.

           "lifetime"
               (integer) Cache entries for nonces will expire after this many seconds.

               Defaults to the value of "window", below.

               If "lifetime" is zero or negative, expiration times will not be set at all;
               entries will expire as per the default behavior for your cache (or you will need
               to purge them via some separate process).

               If your cache implementation ignores the third argument on $entry->set() calls
               (see Cache::Entry), then this option has no effect beyond serving as a default for
               "window".

           "ignoretime"
               (boolean) Do not do any checking of timestamps, i.e., only test whether nonce is
               in the cache.  This overrides all other nonce options except for "lifetime" and
               "nocheck"

           "skew"
               (integer) Number of seconds that a provider clock can be ahead of ours before we
               deem it to be misconfigured.

               Default skew is 300 (5 minutes) or "window/2", if "window" is specified and
               "window/2" is smaller.

               ("skew" is treated as 0 if set negative, but don't do that).

               Misconfiguration of the provider clock means its timestamps are not reliable,
               which then means there is no way to know whether or not the nonce could have been
               sent before the start of the cache window, which nullifies any obligation to
               detect all multiply sent nonces.  Conversely, if proper configuration can be
               assumed, then the timestamp value minus "skew" will be the earliest possible time
               that we could have received a previous instance of this response_nonce, and if the
               cache is reliable about holding entries from that time forward, then (and only
               then) can one be certain that an uncached nonce instance is indeed the first.

           "start"
               (integer) Reject nonces where timestamp minus "skew" is earlier than "start"
               (absolute seconds; default is zero a.k.a. midnight 1/1/1970 UTC)

               If you know the start time of your HTTP server (or your cache server, if that is
               separate — or the maximum of the start times if you have multiple cache servers),
               you should use this option to declare that.

           "window"
               (integer) Reject nonces where timestamp minus "skew" is more than "window" seconds
               ago.  Zero or negative values of "window" are treated as infinite (i.e., allow
               everything).

               If "lifetime" is specified, "window" defaults to that.  If "lifetime" is not
               specified, "window" defaults to 1800 (30 minutes), adjusted upwards if "skew" is
               specified and larger than the default skew.

               On general principles, "window" should be a maximal expected propagation delay
               plus twice the "skew".

               Values between 0 and "skew" (causing all nonces to be rejected) and values greater
               than "lifetime" (cache may fail to keep all nonces that are still within the
               window) are not recommended.

           "timecop"
               (boolean) Reject nonces from The Future (i.e., timestamped more than "skew"
               seconds from now).

               Note that rejecting future nonces is not required.  Nor does it protect from
               anything since an attacker can retry the message once it has expired from the
               cache but is still within the time interval where we would not yet expect that it
               could expire — this being the essential problem with future nonces.  It may,
               however, be useful to have warnings about misconfigured provider clocks — and
               hence about this insecurity — at the cost of impairing interoperability (since
               this rejects messages that are otherwise allowed by the protocol), hence this
               option.

           In most cases it will be enough to either set "nocheck" to dispense with
           response_nonce checking entirely because some other (better) method of preventing
           replay attacks (see consumer_secret) has been implemented, or use "lifetime" to
           declare/set the lifetime of cache entries for nonces whether because the default
           lifetime is unsatisfactory or because the cache implementation is incapable of setting
           individual expiration times.  All other options should default reasonably in these
           cases.

           In order for the nonce check to be as reliable/secure as possible (i.e., that it block
           all instances of duplicate nonces from properly configured providers as defined by
           "skew", which is the best we can do), "start" must be no earlier than the cache start
           time and the cache must be guaranteed to hold nonce entries for at least "window"
           seconds (though, to be sure, if you can tolerate being vulnerable for the first
           "window" seconds of a server run, then you do not need to set "start").

   Performing Discovery
       $csr->claimed_identity($url)
           Given a user-entered $url (which could be missing http://, or have extra whitespace,
           etc), converts it to canonical form, performs partial discovery to confirm that at
           least one provider endpoint exists, and returns a Net::OpenID::ClaimedIdentity object,
           or, on failure of any of the above, returns undef and sets last error ($csr->err).

           Note that the identity returned is not verified yet.  It's only who the user claims
           they are, but they could be lying.

           If this method returns undef, an error code will be set.  See Error Codes below.

   Handling Provider Responses
       The following routines are for handling a redirected provider response and assume that,
       among other things, $csr->args has been properly populated with the URL parameters.

       $csr->handle_server_response( %callbacks );
           When a request comes in that contains a response from an OpenID provider, figure out
           what it means and dispatch to an appropriate callback to handle the request. This is
           the callback-based alternative to explicitly calling the methods below in the correct
           sequence, and is recommended unless you need to do something strange.

           Anything you return from the selected callback function will be returned by this
           method verbatim. This is useful if the caller needs to return something different in
           each case.

           The available callbacks are:

           "not_openid"
               the request isn't an OpenID response after all.

           "setup_needed"
               a checkid_immediate mode request was rejected, indicating that the provider
               requires user interaction.

           "cancelled"
               the user cancelled the authentication request from the provider's UI.

           "verified ($verified_identity)"
               the user's identity has been successfully verified.  A
               Net::OpenID::VerifiedIdentity object is passed in.

           "error ($errcode, $errmsg)"
               an error has occurred. An error code and message are provided.  See Error Codes
               below for the meanings of the codes.

           For the sake of legacy code we also allow

           "setup_required ($setup_url)"
               [DEPRECATED] a checkid_immediate mode request was rejected and $setup_url was
               provided.

               Clients using this callback should be updated to use setup_needed at the earliest
               opportunity.  Here $setup_url is the same as returned by $csr->user_setup_url.

       $csr->is_server_response
           Returns true if a set of URL parameters has been supplied (via $csr->args) and
           constitutes an actual OpenID protocol message.

       $csr->setup_needed
           Returns true if a checkid_immediate request failed because the provider requires user
           interaction.  The correct action to take at this point depends on the OpenID protocol
           version

           (Version 1) Redirect to or otherwise make available a link to $csr->"user_setup_url".

           (Version 2) Retry the request in checkid_setup mode; the provider will then issue
           redirects as needed.

               N.B.: While some providers have been known to supply the "user_setup_url"
               parameter in Version 2 "setup_needed" responses, you cannot rely on this, and,
               moreover, since the OpenID 2.0 specification has nothing to say about the meaning
               of such a parameter, you cannot rely on it meaning anything in particular even if
               it is supplied.

       $csr->user_setup_url( [ %opts ] )
           (Version 1 only) Returns the URL the user must return to in order to login, setup
           trust, or do whatever the identity provider needs them to do in order to make the
           identity assertion which they previously initiated by entering their claimed identity
           URL.

               N.B.: Checking whether "user_setup_url" is set in order to determine whether a
               checkid_immediate request failed is DEPRECATED and will fail under OpenID 2.0.
               Use "setup_needed()" instead.

           The base URL that this function returns can be modified by using the following options
           in %opts:

           "post_grant"
               What you're asking the identity provider to do with the user after they setup
               trust.  Can be either "return" or "close" to return the user back to the return_to
               URL, or close the browser window with JavaScript.  If you don't specify, the
               behavior is undefined (probably the user gets a dead-end page with a link back to
               the return_to URL).  In any case, the identity provider can do whatever it wants,
               so don't depend on this.

       $csr->user_cancel
           Returns true if the user declined to share their identity, false otherwise.  (This
           function is literally one line: returns true if "openid.mode" eq "cancel")

           It's then your job to restore your app to where it was prior to redirecting them off
           to the user_setup_url, using the other query parameters that you'd sent along in your
           return_to URL.

       $csr->verified_identity( [ %opts ] )
           Returns a Net::OpenID::VerifiedIdentity object, or returns undef and sets last error
           ($csr->err).  Verification includes double-checking the reported identity URL declares
           the identity provider, verifying the signature, etc.

           The options in %opts may contain:

           "required_root"
               Sets the required_root just for this request.  Values returns to its previous
               value afterwards.

           If this method returns undef, an error code will be set.  See Error Codes below.

ERROR CODES

       This is the complete list of error codes that can be set.  Errors marked with (C) are set
       by claimed_identity.  Other errors occur during handling of provider responses and can be
       set by args (A), verified_identity (V), and user_setup_url (S), all of which can show up
       in the "error" callback for handle_server_response.

           "provider_error"
               (A) The protocol message is a (2.0) error mode (i.e., "openid.mode = 'error'")
               message, typically used for provider-specific error responses.  Use $csr->message
               to get at the "contact" and "reference" fields.

           "empty_url"
               (C) Tried to do discovery on an empty or all-whitespace string.

           "bogus_url"
               (C) Tried to do discovery on a non-http:/https: URL.

           "protocol_version_incorrect"
               (C) None of the ID providers found support even the minimum protocol version
               ($csr->minimum_version)

           "no_identity_server"
               (CV) Tried to do discovery on a URL that does not seem to have any providers at
               all.

           "bad_mode"
               (SV) The "openid.mode" was expected to be "id_res" (positive assertion or, in
               version 1, checkid_immediate failed).

           "no_identity"
               (V) The "openid.identity" parameter is missing.

           "no_sig"
               (V) The  "openid.sig" parameter is missing.

           "no_return_to"
               (V) The "openid.return_to" parameter is missing

           "bogus_return_to"
               (V) The "return_to" URL does not match $csr->required_root

           "nonce_missing"
               (V) The "openid.response_nonce" parameter is missing.

           "nonce_reused"
               (V) A previous assertion from this provider used this response_nonce already.
               Someone may be attempting a replay attack.

           "nonce_format"
               (V) Either the response_nonce timestamp was not in the correct format (e.g., tried
               to have fractional seconds or not UTC) or one of the components was out of range
               (e.g., month = 13).

           "nonce_future"
               (V) "timecop" was set and we got a response_nonce that was more than "skew"
               seconds into the future.

           "nonce_stale"
               (V) We got a response_nonce that was either prior to the start time or more than
               window seconds ago.

           "time_expired"
               (V) The return_to signature time ("oic.time") is from too long ago.

           "time_in_future"
               (V) The return_to signature time ("oic.time") is too far into the future.

           "time_bad_sig"
               (V) The HMAC of the return_to signature ("oic.time") is not what it should be.

           "server_not_allowed"
               (V) None of the provider endpoints found for the given ID match the server
               specified by the "openid.op_endpoint" parameter (OpenID 2 only).

           "unexpected_url_redirect"
               (V) Discovery for the given ID ended up at the wrong place

           "bogus_delegation"
               (V) Asserted identity ("openid.identity") does not match claimed_id or
               local_id/delegate.

           "unsigned_field"
               (V) In OpenID 2.0, "openid.op_endpoint", "openid.return_to",
               "openid.response_nonce", and "openid.assoc_handle" must always be signed, while
               "openid.claimed_id" and "openid.identity" must be signed if present.

           "expired_association"
               (V) "openid.assoc_handle" is for an association that has expired.

           "signature_mismatch"
               (V) An attempt to confirm the positive assertion using the association given by
               "openid.assoc_handle" failed; the signature is not what it should be.

           "naive_verify_failed_network"
               (V) An attempt to confirm the positive assertion via direct contact
               (check_authentication) with the provider failed with no response or a bad status
               code (!= 200).

           "naive_verify_failed_return"
               (V) An attempt to confirm a positive assertion via direct contact
               (check_authentication) received an explicitly negative response ("openid.is_valid
               = FALSE").

PROTOCOL VARIANCES

       XRI-based identities are not supported.

       Meanwhile, here are answers to the security profile questions from section 15.6 of the
       OpenID 2.0 specification <http://openid.net/specs/openid-authentication-2_0.html#anchor47>
       that are relevant to the Consumer/Relying-Party:

       1.  Are wildcards allowed in realms?  Yes.

       2.  N/A.

       3.  Types of claimed identifiers accepted.  HTTP or HTTPS

       4.  Are self-issued certificates allowed for authentication?  Depends entirely on the user
           agent ("ua") supplied.  LWP::UserAgent, as of version 6.0, can be configured to only
           accept connections to sites with certificates deriving from a set of trusted roots.

       5.  Must the XRDS file be signed?  No.

       6.  Must the XRDS file be retrieved over secure channel?  No.

       7.  What types of session types can be used when creating associations?  Any of
           "no-encryption","DH-SHA1","DH-SHA256"

       8.  N/A.

       9.  N/A.

       10. Must the association request take place over a secure channel?  If the session type is
           "no-encryption", then Yes for version 2.0 providers and likewise for version 1.1
           providers if "allow_eavesdropping" is not set, otherwise No.

COPYRIGHT

       This module is Copyright (c) 2005 Brad Fitzpatrick.  All rights reserved.

       You may distribute under the terms of either the GNU General Public License or the
       Artistic License, as specified in the Perl README file.  If you need more liberal
       licensing terms, please contact the maintainer.

WARRANTY

       This is free software. IT COMES WITHOUT WARRANTY OF ANY KIND.

MAILING LIST

       The Net::OpenID family of modules has a mailing list powered by Google Groups. For more
       information, see <http://groups.google.com/group/openid-perl>.

SEE ALSO

       OpenID website: <http://openid.net/>

       Net::OpenID::ClaimedIdentity -- part of this module

       Net::OpenID::VerifiedIdentity -- part of this module

       Net::OpenID::Server -- another module, for implementing an OpenID identity provider/server

AUTHORS

       Brad Fitzpatrick <brad@danga.com>

       Tatsuhiko Miyagawa <miyagawa@sixapart.com>

       Martin Atkins <mart@degeneration.co.uk>

       Robert Norris <rob@eatenbyagrue.org>

       Roger Crew <crew@cs.stanford.edu>