view release on metacpan or  search on metacpan

lib/Apache/iNcom.pm  view on Meta::CPAN

=item 2

Session ID are transmitted only by cookies to assure confidentiality.

=item 3

There are no user transmitted magic variables. Form data doesn't act upon
the framework. All actions are triggered by the application and not the
user. All form data that should be used for action are determined by the
application through the various profiles. This means that you won't be
burned by a magic feature that sprung without you knowing it.

=item 4

Regular access control of Apache can be used. Also see the ACLs
mechanism offered by the DBIx::UserDB(3) for access control with finer
resolution than URL or file based.

=item 5

SSL can (and should) be used to assure confidentiality.

=item 6

Executable content (pages) that shouldn't be directly accessible from
the user (include file, error pages, etc) can be kept in separate
directory which aren't accessible directly.

=back

The major (current) security limitations is that the application
programmer is trusted. Apache::iNcom pages have complete control over
the Apache server environment in which they run. Keep this in mind
when running multiple sites. Future version will use the Safe(3) module
to improve on this.

=head1 MULTIPLE CATALOGS

Multiple e-commerce sites can easily be run by using the VirtualHost
capability of apache.

=head1 PERFORMANCE AND SCALABILITY

No state is kept between requests which makes it easy to scale the
load on Apache::iNcom across multiple server.

mod_perl general tips for improving performance should be applied. See
the mod_perl guide for details (http://perl.apache.org/guide/).

=head1 ERROR HANDLING

Error are handled in a way similar to the ErrorDocument functionality.
The error profile is an file which should C<eval> to an hash
reference. Keys are error number and values are the file that should
be returned on error. The pages are assumed to be relative to the
I<INCOM_ERROR_ROOT> directory, or if unspecified the I<INCOM_ROOT>.

If a localized version of the page exists, that one will be use. The
page will be executed as a normal Apache::iNcom pages. Error are keyed
either by the HTTP response code (404,403,500, etc) or by an arbitrary
key for application specific error. In order to return an arbitrary
error, you set the pnote I<INCOM_ERROR> in the page before returning
an error.

    Example: $req_rec->pnotes( "INCOM_ERROR", "validation_failed" );
	     die "validation_failed";

The page linked to the "validation_failed" key in the error profile
will be used.

The "no_cookies" key is used to find the error page to return in case
the user has turned off cookies.

In the case of an error handler trigerred by an error in an HTML::Embperl
page. The error page will received in the @param array the error messages
emitted by HTML::Embperl.

=head1 AUTHOR

Copyright (c) 1999 Francis J. Lacoste and iNsu Innovations Inc.
All rights reserved.

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.

=head1 SEE ALSO

Apache::iNcom::Request(3) Apache::iNcom::CartManager(3)
Apache::iNcom::OrderManager(3) DBIx::SearchProfiles(3) DBIx::UserDB(3)
Locale::Maketext(3) HTML::Embperl

=cut