view release on metacpan or  search on metacpan

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

To turn off the creation of an input profile set this directive to
C<NONE>.

=item INCOM_PRICING_PROFILE

Sets the pricing profile that will be used to initialize the $Cart
object. Defaults to F<conf/pricing_profile.pl> relative to server's
root.

See Apache::iNcom::CartManager(3) for details on the format of this file.

If you don't need the cart management feature, set this directive to
C<NONE>.


=item INCOM_ORDER_PROFILE

Sets the order profiles file that will be used to initialize the
$Order object. Defaults to F<conf/order_profiles.pl> relative to server's
root.

See Apache::iNcom::OrderManager(3) for details on the format of this file.

If you don't need this feature, you can set this directive to C<NONE>.

=back

=head2 USERDB DIRECTIVES

=over

=item INCOM_USERDB_PROFILE

Name of the profile to use for the user database. Defaults to
C<userdb>. See DBIx::UserDB(3) for more information. To disable the
use of a DBIx::UserDB object, sets this directives to C<NONE>.

=item INCOM_GROUPDB_PROFILE

Name of the profile to use for the group database access. Defaults to
C<groupdb>. See DBIx::UserDB(3) for more information.

=item INCOM_SCRAMBLE_PASSWORD

Turn on or off scrambling of user's password in the UserDB.

=back


=head2 LOCALIZATION DIRECTIVES

=over

=item INCOM_DEFAULT_LANGUAGE

The language of the files without a language extension. Defaults to C<en>.

=item INCOM_LOCALE

The package uses to create Locale::Maketext(3) instance. If this is
set, an instance appropriate for the user's locale will be available
through the $Locale object.

=back


=head2 SESSION DIRECTIVES

=over

=item INCOM_SESSION_SERIALIZE_ACCESS

Set this to 1 to serialize access through session. This will make sure
that only one session's request is processed at a time. You should set
this to 1 if your site uses frameset.

=item INCOM_SESSION_SECURE

Sets this to true if you want the cookie that contains the session id
to be only transmitted over SSL connections. Be aware that setting
this variable to true will require that all Apache::iNcom transactions
be conducted over SSL.

=item INCOM_SESSION_DOMAIN

The domain to which the Apache::iNcom session's cookie will be
transmitted. You can use this, if you are using a server farm for
example.

=item INCOM_SESSION_PATH

The path under which the session id is valid. Defaults to
I<INCOM_URL_PREFIX>.

=item INCOM_SESSION_EXPIRES

The time for which the use session is valid. Defaults is for a browser
session. (Once the user exists its browser session will become
invalid).

=back

=head2 ERROR HANDLING DIRECTIVES

=over

=item INCOM_ERROR_PROFILE

The error profile that will be used for displaying server error.

=item INCOM_ERROR_ROOT

The directory which contains error pages. If a non absolute path
is specified, it is relative to the server's root.

=back

=head1 SESSION HANDLING

On the user's first request, a new session is created. Each and every
other request will be part of a session which will used to track the

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

ENABLED for Apache::iNcom to function. Fortunately, Apache::iNcom
detects if the user has cookies turned off and will send the user an
error.

Cookies are used for security and confidentiality. The session id is a
truly random 128bits number, which is make it very much unguessable.
That means that you can't try to stomp into another user's session.
That is a good thing since having access to the session id means
having access to a whole bunch of informations. (What information is
application specific.) IP address aren't used to restrict the session
access because of the various problems with proxies and other Internet
niceties.

Now, what has this to do with cookies ? Well, using URL rewriting was
originally considered, but then two big issues cralwed in : proxies
and the Referer header. Having the session id embedded in the URL
means that our precious session id will be stored in various log files
across multiple server (web server, proxy server, etc) This is a bad
thing. Also, must request contains a Referer header which means that
the session id is likely to leak to third party sites which are linked
from your site (or not, Netscape used to send the header even if the
user only typed in the new URL while viewing your page). This is
another bad thing, and this is why we are using cookies.


=head1 APACHE::INCOM PAGES

Apache::iNcom pages are HTML::Embperl pages with some extra variables
and functions available. See Apache::iNcom::Request(3) for details.
You may also which to consult the HTML::Embperl documentation for
syntax. Additionnaly, the normal $req_rec object in the page is an
instance of Apache::Request(3) so that you can handle multipart
upload.

=head1 DATABASE CONNECTIVITY

The database connection is opened once per request and shared by
all modules that must use it. Database access is mediated through
the use of the DBIx::SearchProfiles(3) module. 

Connections are opened in commit on request mode. The database
connection is commit after the page is executed. If an error occurs,
the transaction will be rolled back. The application may elect to
commit part of the transaction earlier.

=head1 CART MANAGEMENT

See Apache::iNcom::CartManager(3) for details.

=head1 ORDER MANAGEMENT

See Apache::iNcom::OrderManager(3) for details.

=head1 USER MANAGEMENT

User management is handled through the DBIx::UserDB(3) module.

=head1 LOCALIZATION

Apache::iNcom is designed to make it easy to adapt your e-commerce
application to multiple locale.

The framework uses Locale::Maketext(3) for message formatting.

All pages may have a localized version available. The localized should
have an extension describing its language. (.en for English, .fr for
French, .de for German, etc.)

The user locale will
be negotiated through the Accep-Language header which is part of the
HTTP protocol. It can also be set explicitely by sending the user to
a special link (since not many users took the time to configure their
browser for language negotiation).

The URL :

    I<INCOM_URL_PREFIX>/incom_set_lang/I<LANG>

This will set the language to use in the user's session.

=head1 SECURITY

Apache::iNcom has been with security has one of its primary design goal.

=over

=item 1

Session ID are 128bits truly random number.

=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