view release on metacpan or  search on metacpan

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

=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
user's cart and other such things.

The session id is returned to the user in a cookie. COOKIES MUST BE
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