[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
Log:
* 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;.
</para><para>
&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>
designation.
</para>
<note><para>
&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.
</para></note>
<para>
Interchange uses the &conf-SecureURL; directive to set the base URL for secure
transactions, and the &conf-VendURL; directive for normal non-secure
transactions.
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></a></code>.
A certain page
can be set to always be secure with the &conf-AlwaysSecure; directive.
</para><para>
Interchange incorporates additional security for credit card numbers. The
field <mv>mv_credit_card_number</mv> will not ever be written to disk.
</para><para>
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:
<programlisting>
CreditCardAuto Yes
EncryptProgram /usr/bin/pgpe -fat -r <replaceable>sales at company.com</replaceable>
</programlisting>
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
</para></question>
<answer><para>
There's a built-in &IC; way to control user access to pages served
from the &conf-PageDir; directories.
</para><para>
Namely, if the directory containing the requested page contains file
named <filename>.access</filename> — and that file's size is zero bytes
— then access can be "gated" in one of the following ways:
<itemizedlist>
<listitem><para>
If the file <filename>.access_gate</filename> is also present, it will be
read and scanned to perform page-based access decision.
</para></listitem>
<listitem><para>
</para></listitem>
<listitem><para>
</para></listitem>
</itemizedlist>
</para>
<section>
<title>.access_gate format</title>
<para>
The <filename>.access_gate</filename> file has the general format of:
<programlisting>
<replaceable>PAGE_NAME</replaceable>: <replaceable>CONDITION</replaceable>
</programlisting>
<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.
</para><para>
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.
</para>
<para>
Here's a very simple example:
<programlisting>
pubview: Yes
*: No
</programlisting>
</para>
<para>
Here's an example that includes &glos-ITL; interpolation and is
verbose enough not to require additional explanation.
<programlisting>
foo.html: [if session username eq 'flycat'] 202,1 32%
Yes
[/if]
bar: [if session username eq 'flycat'][or scratch allow_bar] 202,1 32%
Yes
[/or][/if]
baz: yes
*: [data session logged_in]
</programlisting>
</para>
</section>
<para>
<!-- 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
</para></question>
<answer><para>
Since your stock may be limited, you could want to stop users from
ordering more items than you have.
</para><para>
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:
</para><para>
<programlisting><![CDATA[
[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.";
}
[/perl]
]]></programlisting>
Then you can place <code>[item-modifier q_message]</code> somewhere in the
item line to notify the customer of adjusted quantity.
</para><para>
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
</para></question>
<answer><para>
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.
</para><para>
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
<filename>products/<replaceable>DATABASE_NAME</replaceable>.sql</filename>
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
</para></question>
<answer><para>
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
ones.
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
</para></question>
<answer><para>
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:
</para><para>
<programlisting><![CDATA[
my $sess_string = $Tag->uneval( { ref => $Session } );
$Tag->writefile("tmp/$Session->{id}.save", $sess_string);
]]></programlisting>
Then, in your retrieve route (which must be a global &glos-usertag;),
do something like:
<programlisting><![CDATA[
my $safe = new Safe;
my $sess_string = $Tag->file("tmp/$id_to_retrieve.save");
my $session_ref = $safe->reval($sess_string);
]]></programlisting>
<!-- PORT_OLD -->
More information about the docs
mailing list