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

NAME

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

VERSION

Version 0.097

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.

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, which is assumed to be number of seconds since epoch when the session was last seen. This is compared to "now" and if the difference is greater than the MFILE_REST_SESSION_EXPIRATION_TIME site parameter, the return value is false, otherwise true.

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.

process_post

AJAX calls come in as POST requests with a JSON body of the following structure:

{ method: "PUT", path: "employee/nick", body: { nick: "bubba", realname: "Bubba Jones" } }

There is one special case: the POST request from the login dialog looks like this:

{ method: "LOGIN", path: "login", body: { nam: 'nick', pwd: 'kcin" } }

This structure represents an HTTP request to the REST server. The request is sent via the LWP::UserAgent object stored in the session data. The status object received in the response is forwarded back to the JavaScript side.

init_session

Takes a session and an IP address. Initializes the session so it no longer contains any information that might tie it to the current user.

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 unit tests