[interchange-docs] xmldocs - docelic modified 9 files

docs at icdevgroup.org docs at icdevgroup.org
Thu Aug 3 17:58:41 EDT 2006

User:      docelic
Date:      2006-08-03 21:58:40 GMT
Added:     glossary SSL gate reconfigure usertag
Added:     howtos   control-access-to-certain-pages
Added:              forcibly-adjust-quantity-of-ordered-item
Added:              modify-database-text-source-file-and-apply-changes
Added:              override-admin-UI-page write-and-read-a-session
* Some additions as glossary and howto entries

Revision  Changes    Path
1.1                  xmldocs/glossary/SSL

rev 1.1, prev_rev 1.0
Index: SSL
<ulink url="http://en.wikipedia.org/wiki/Secure_Sockets_Layer">Secure
Sockets Layer</ulink> resource at &WIKIPEDIA;.
&IC; has several features that enable secure ordering via SSL.
Despite their mystique, SSL web servers are actually
quite easy to operate. The difference between the standard &HTTP; server
and the SSL HTTPS server, from the standpoint of the user, is only in
the encryption that happens kind-of transparently, and the specification
of the URL -- <literal>https:</literal> is used for the
&URL; protocol specification instead of the usual <literal>http:</literal>

&IC; attempts to perform operations securely,
but no guarantees or warranties of any kind are made! Since Interchange
comes with &PERL; source, it is possible to modify the program to create
bad security problems. One way to minimize this possibility is to record
digital signatures, using MD5 or PGP, of
<filename>bin/interchange</filename>, <filename>interchange.cfg</filename>,
and all modules included in Interchange. Then verify them on a regular basis to
ensure they have not been changed.

Interchange uses the &conf-SecureURL; directive to set the base URL for secure
transactions, and the &conf-VendURL; directive for normal non-secure
Secure URLs can be enabled for individual forms through a form action of 
<code>[process secure=1]</code>. An individual page can be displayed
via SSL with <code>[page href=<replaceable>PAGE_URL</replaceable> secure=1]<replaceable>PAGE_NAME</replaceable>&lt;/a&gt;</code>.
A certain page
can be set to always be secure with the &conf-AlwaysSecure; directive.

Interchange incorporates additional security for credit card numbers. The
field <mv>mv_credit_card_number</mv> will not ever be written to disk.

To enable automated encryption of the credit card information, you need
to enable &conf-CreditCardAuto;. &conf-EncryptProgram;
also needs to be set to a command which will, with hope, encrypt the number
when invoked. PGP is now recommended above all other encryption
program. The entries should look something like:

  CreditCardAuto Yes
  EncryptProgram /usr/bin/pgpe -fat -r <replaceable>sales at company.com</replaceable>

See &conf-CreditCardAuto;, &conf-PGP;, &conf-GPG_PATH;, 
&conf-EncryptKey;  and &conf-EncryptProgram; configuration directives
for more information and examples.

<!-- TODO move credit card info to credit card glossentry -->

1.1                  xmldocs/glossary/gate

rev 1.1, prev_rev 1.0
Index: gate
In &IC; parlance, "gating" is the process of controlling access to
certain pages. See &howto-control-access-to-certain-pages; HOW-TO entry
for further information and examples.

1.1                  xmldocs/glossary/reconfigure

rev 1.1, prev_rev 1.0
Index: reconfigure
See &howto-daemon-control;.

1.1                  xmldocs/glossary/usertag

<<usertag: empty>>

1.1                  xmldocs/howtos/control-access-to-certain-pages

rev 1.1, prev_rev 1.0
Index: control-access-to-certain-pages
Control Access to Certain Pages

There's a built-in &IC; way to control user access to pages served
from the &conf-PageDir; directories.
Namely, if the directory containing the requested page contains file
named <filename>.access</filename> &mdash; and that file's size is zero bytes
&mdash; then access can be "gated" in one of the following ways:


If the file <filename>.access_gate</filename> is also present, it will be
read and scanned to perform page-based access decision.


	<title>.access_gate format</title>
	The <filename>.access_gate</filename> file has the general format of:
<replaceable>PAGE_NAME</replaceable>: <replaceable>CONDITION</replaceable>
<replaceable>PAGE_NAME</replaceable> is the name of page to be controlled,
and the page suffix (such as <literal>.html</literal>) is optional.
Page name of <literal>*</literal> can be used to set a default permission.
The implicit default permission is <literal>No</literal>, so leaving the default
entry unspecified results in all non-matching users being denied access.
The <replaceable>CONDITION</replaceable> is a simple &glos-true; (or 
<literal>Yes</literal>) or &glos-false; (or <literal>No</literal>) value
which may come, and in fact often comes, from
&glos-interpolate;d &glos-ITL; code.
Here's a very simple example:
pubview: Yes
*: No
Here's an example that includes &glos-ITL; interpolation and is
verbose enough not to require additional explanation.
foo.html: [if session username eq 'flycat']                202,1         32%

bar:      [if session username eq 'flycat'][or scratch allow_bar]                           202,1         32%

baz:      yes

*:        [data session logged_in]

<!-- TODO is it first match wins, and can you say page*: ... ? 

+If the Variable C<MV_USERDB_REMOTE_USER> is set (non-zero and non-blank), any user logged in via the UserDB feature will receive access to all pages in the directory. NOTE: If there is a C<.access_gate> file, it overrides this.

+If the variables C<MV_USERDB_ACL_TABLE> is set to a valid database identifier, the UserDB module can control access with simple ACL logic. See USER DATABASE. NOTE: If there is a C<.access_gate> file, it overrides this. Also, if C<MV_USERDB_REMOTE_USER> is set, this capability is not available.


1.1                  xmldocs/howtos/forcibly-adjust-quantity-of-ordered-item

rev 1.1, prev_rev 1.0
Index: forcibly-adjust-quantity-of-ordered-item
Forcibly Adjust Quantity of Ordered Item

Since your stock may be limited, you could want to stop users from 
ordering more items than you have.
There are a number of ways to do this. Here is one; the code should
be placed at the top of the basket and checkout page:
[perl tables=inventory]
  my $cart = $Carts->{main};
  my $item;
  foreach $item (@$cart) {
    my $on_hand = tag_data('inventory', 'quantity', $item->{code});
    next if $on_hand >= $item->{quantity};
    $item->{quantity} = $on_hand;
    $item->{q_message} = "Order quantity adjusted to fit stock.";

Then you can place <code>[item-modifier q_message]</code> somewhere in the
item line to notify the customer of adjusted quantity.
For the code to work, you need an <database>inventory</database>
&glos-database; that has a <database class='field'>quantity</database> field
for all items.

<!-- PORT_OLD -->

1.1                  xmldocs/howtos/modify-database-text-source-file-and-apply-changes

rev 1.1, prev_rev 1.0
Index: modify-database-text-source-file-and-apply-changes
Modify Database Text Source File and Apply Changes

With some kind of a DBM &glos-database;, this should be automatic. Changes
to the text source file will be detected on first client access to the
specific database; &IC; will then re-read the text source file and override
the previous contents in the DBM database. See the &conf-NoImport; to disable
this behavior.
With &glos-SQL; databases, the import happens only once (when the
&glos-database; is initally populated with contents from the text source file).
To manually trigger the re-import for a specific database, delete file
and &glos-reconfigure; the catalog.

1.1                  xmldocs/howtos/override-admin-UI-page

rev 1.1, prev_rev 1.0
Index: override-admin-UI-page
Override page from Admin UI with catalog's custom version

At any time, you can copy pages from
the <filename class='directory'>lib/UI/pages/admin/</filename> directory
into the <filename class='directory'>pages/admin/</filename> directory
under your catalog tree, to make custom versions that override the distribution
You only need copy the pages you want to override; the rest are automatically
picked up from the usual, default location.

1.1                  xmldocs/howtos/write-and-read-a-session

rev 1.1, prev_rev 1.0
Index: write-and-read-a-session
Write and read a session

If you are going to save a &glos-session; and
do something specific with it, do it explicitly by saving to 
a separate, named file:
my $sess_string = $Tag->uneval( { ref => $Session } );
$Tag->writefile("tmp/$Session->{id}.save", $sess_string);

Then, in your retrieve route (which must be a global &glos-usertag;),
do something like:

my $safe = new Safe;
my $sess_string = $Tag->file("tmp/$id_to_retrieve.save");
my $session_ref = $safe->reval($sess_string);

<!-- PORT_OLD -->

More information about the docs mailing list