![]() |
![]()
| ![]() |
![]()
NAMENet::OAuth2::Profile::WebServer - OAuth2 for web-server use INHERITANCENet::OAuth2::Profile::WebServer is a Net::OAuth2::Profile SYNOPSIS# See examples/psgi/ my $auth = Net::OAuth2::Profile::WebServer->new ( name => 'Google Contacts' , client_id => $id , client_secret => $secret , site => 'https://accounts.google.com' , scope => 'https://www.google.com/m8/feeds/' , authorize_path => '/o/oauth2/auth' , access_token_path => '/o/oauth2/token' , protected_resource_url => 'https://www.google.com/m8/feeds/contacts/default/full' ); # Let user ask for a grant from the resource owner print $auth->authorize_response->as_string; # or, in Plack: redirect $auth->authorize; # Prove your identity at the authorization server # The $info are the parameters from the callback to your service, it # will contain a 'code' value. my $access_token = $auth->get_access_token($info->{code}); # communicate with the resource serve my $response = $access_token->get('/me'); $response->is_success or die "error: " . $response->status_line; print "Yay, it worked: " . $response->decoded_content; DESCRIPTIONUse OAuth2 in a WebServer context. Read the DETAILS section, far below this man-page before you start implementing this interface. Extends "DESCRIPTION" in Net::OAuth2::Profile. METHODSExtends "METHODS" in Net::OAuth2::Profile. ConstructorsExtends "Constructors" in Net::OAuth2::Profile.
AccessorsExtends "Accessors" in Net::OAuth2::Profile.
ActionsExtends "Actions" in Net::OAuth2::Profile.
example: my $auth = Net::OAuth2::Profile::WebServer->new(...); # From the Plack demo, included in this distribution (on CPAN) get '/get' => sub { redirect $auth->authorize }; # In generic HTTP, see method authorize_response use HTTP::Status 'HTTP_TEMPORARY_REDIRECT'; # 307 print HTTP::Response->new ( HTTP_TEMPORARY_REDIRECT => 'Get authorization grant' , [ Location => $auth->authorize ] )->as_string;
HelpersExtends "Helpers" in Net::OAuth2::Profile.
DETAILSOAuth2 is a server-server protocol, not the usual client-server set-up. The consequence is that the protocol handlers on both sides will not wait for another during the communication: the remote uses callback urls to pass on the response. Your side of the communication, your webservice, needs to re-group these separate processing steps into logical sessions. The processThe client side of the process has three steps, nicely described in <https://tools.ietf.org/html/rfc6749|RFC6749>
Saving the tokenYour application must implement a persistent session, probably in a database or file. The session information is kept in an Net::OAuth2::AccessToken object, and does contain more facts than just the access token. Let's discuss the three approaches. no saving The Plack example contained in the CPAN distribution of this module is a single process server. The tokens are administered in the memory of the process. It is nice to test your settings, but probably not realistic for any real-life application. automatic saving When your own code is imperative: my $auth = Net::OAuth2::Profile::WebServer->new ( ... , auto_save => \&save_session ); sub save_session($$) { my ($profile, $token) = @_; ... } When your own code is object oriented: sub init(...) { my ($self, ...) = @_; my $auth = Net::OAuth2::Profile::WebServer->new ( ... , auto_save => sub { $self->save_session(@_) } ); } sub save_session($$) { my ($self, $profile, $token) = @_; ... } explicit saving In this case, do not use new(auto_save). COPYRIGHTSCopyrights 2013-2019 on the perl code and the related
documentation
Copyrights 2011-2012 by Keith Grennan. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See http://dev.perl.org/licenses/
|