NAME
CallBackery::RpcService - RPC services for CallBackery
SYNOPSIS
This module gets instantiated by CallBackery and provides backend functionality.
DESCRIPTION
This module provides the following methods
allow_rpc_access(method)
is this method accessible?
logRpcCall
Set CALLBACKERY_RPC_LOG for extensive logging messages. Note that all values with keys matching /password|_pass/ do get replaced with 'xxx' in the output.
logRpcReturn
Set CALLBACKERY_RPC_LOG for extensive logging messages. Note that all values with keys matching /password|_pass/ do get replaced with 'xxx' in the output.
ping()
check if the server is happy with our authentication state
getSessionCookie()
Return a timeestamped session cookie. For use in the X-Session-Cookie header or as a xsc field in form submissions. Note that session cookies for form submissions are only valid for 2 seconds. So you have to get a fresh one from the server before submitting your form.
getConfig()
get some gloabal configuration information into the interface
login(user,password)
Check login and provide the user specific interface configuration as a response.
logout
Kill the session.
instantiatePlugin_p
get an instance for the given plugin
processPluginData(plugin,args)
handle form sumissions
validateField(plugin,args)
validate the content of the given field for the given plugin
getPluginData(plugin,args);
return the current value for the given field
getUserConfig
returns user specific configuration information
getPluginConfig(plugin,args)
Returns a plugin configuration removing all the 'back end' keys and non ARRAY or HASH references in the process.
runEventActions(event[,args])
Call the eventAction handlers of all configured plugins. Currently the following events are known:
changeConfigsetPreDestroyAction(key,callback);
This can be used to have tasks completed at the end of a webtransaction since the controller gets instantiated per transaction. An example application would be backing up the configuration changes only once even if more than one configChange event has occured.
handleUpload
Process incoming upload request. This is getting called via a route and NOT in the usual way, hence we have to render our own response!
handleDownload
Process incoming download request. The handler expects two parameters: name for the plugin instance and formData for the data of the webform.
The handler getting the request must return a hash with the following elements:
- filename
-
name of the download when saved
- type
-
mime-type of the download
- asset
-
a Mojo::Asset. eg
Mojo::Asset::File-new(path => '/etc/passwd')>.
BUGS
The idea was to implement preDestoryActions via a DESTROY method, but it seems that the datastructures in the controller are not letting it DESTORY itself as the handle goes out of scope. For now I am using the finish event on tx ... not pretty.
COPYRIGHT
Copyright (c) 2013 by OETIKER+PARTNER AG. All rights reserved.
LICENSE
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
AUTHOR
Tobias Oetiker <tobi@oetiker.ch>
HISTORY
2013-01-01 to Initial