/ 
App-MFILE-WWW-0.176
River stage one • 1 direct dependent • 1 total dependent
/ App::MFILE::WWW::Resource

NAME

App::MFILE::WWW::Resource - HTTP request/response cycle

SYNOPSIS

In PSGI file:

use Web::Machine;

Web::Machine->new(
    resource => 'App::MFILE::WWW::Resource',
)->to_app;

DESCRIPTION

This is where we override the default versions of various methods defined by Web::Machine::Resource.

METHODS

context

This method is where we store data that needs to be shared among routines in this module.

remote_addr

session

session_id

service_available

This is the first method called on every incoming request.

content_types_provided

For GET requests, this is where we add our HTML body to the HTTP response.

charsets_provided

This method causes Web::Machine to encode the response body in UTF-8.

default_charset

Really use UTF-8 all the time.

allowed_methods

Determines which HTTP methods we recognize.

uri_too_long

Is the URI too long?

is_authorized

Since all requests go through this function at a fairly early stage, we leverage it to validate the session.

_is_fresh

Takes a single argument, the PSGI session, which is assumed to contain a last_seen attribute containing the number of seconds since epoch when the session was last seen.

known_content_type

Looks at the 'Content-Type' header of POST requests, and generates a "415 Unsupported Media Type" response if it is anything other than 'application/json'.

malformed_request

This test examines the request body. It can either be empty or contain valid JSON; otherwise, a '400 Malformed Request' response is returned. If it contains valid JSON, it is converted into a Perl hashref and stored in the 'request_body' attribute of the context.

main_html

Takes the session object and returns HTML string to be displayed in the user's browser.

FIXME: might be worth spinning this off into a separate module.

test_html

Generate html for running (core and app) unit tests. The following JS files are run (in this order):

test.js (in mfile-www core)
test.js (in app, e.g. dochazka-www)
test-go.js (in mfile-www core)

login_status

Once the username and password are known (either from process_post via the login AJAX request generated by the login dialog, or from the site configuration via the MFILE_WWW_BYPASS_LOGIN_DIALOG mechanism), the validate_user_credentials method is called. That method is implemented by the derived application, so it can validate user credentials however it likes. The validate_user_credentials method is then expected to call this method - login_status - to generate a status object from the results of the user credentials validation.

Now, App::MFILE::WWW does expect the validate_user_credentials method to provide the results of user credentials validation in a peculiar format, hinging on the argument $code, where a value of 200 indicates successful validation and any other value indicates a failure.

ua

Returns the LWP::UserAgent object obtained from the lookup table. Creates it first if necessary.

rest_req

Algorithm: send request to REST server, get JSON response, decode it, return it.

Takes a single _mandatory_ parameter: a LWP::UserAgent object

Optionally takes PARAMHASH:

server => [URI OF REST SERVER]         default is 'http://0:5000'
method => [HTTP METHOD TO USE]         default is 'GET'
nick => [NICK FOR BASIC AUTH]          optional
password => [PASSWORD FOR BASIC AUTH]  optional
path => [PATH OF REST RESOURCE]        default is '/'
req_body => [HASHREF]                  optional

Returns HASHREF containing:

hr => HTTP::Response object (stripped of the body)
body => [BODY OF HTTP RESPONSE, IF ANY]