Correct typo
[interchange.git] / UPGRADE
1 -----------------------------------------------------------------------------
2
3                 U P G R A D I N G     I N T E R C H A N G E
4
5
6 Interchange is designed to be drop-in compatible in its major version.
7 Briefly summarized, here's what you can expect when upgrading from the
8 following versions:
9
10  5.10.x -- A minor bug was fixed in an edge-case usage of the [area] tag which
11           could result in incompatibility if your code relies on the buggy
12           behaviour.
13
14  5.6.x -- Perl 5.8.8 or newer is now generally required to run Interchange.
15           See "Known Issues" below.
16
17  5.4.x -- A number of incompatible changes were made. Most of them will be
18           simple to deal with, but please consult the list below in the
19           "Known Issues" section. Your code will almost certainly fail to
20           work properly until you make the necessary changes described!
21
22  5.2.x -- There should be few to no compatibility issues in
23           upgrading from Interchange 5.2.x.
24
25  5.0.x -- There should be few to no compatibility issues in
26           upgrading from Interchange 5.0.x.
27
28  4.8.x -- There should be only a few issues in upgrading from 4.8.x; known
29           issues are shown below. The major change is in the admin UI,
30           and you will have a distinctly different look and feel 
31           in that area. Most people find it an improvement.
32           
33  4.6.x -- Upgrading from 4.6.x and before is problematic if you rely on
34           the admin UI -- particularly if you have customized it. The public-
35           facing side should be fairly straightforward to port. See
36           "UPGRADING FROM 4.6.x" below.
37
38  BEFORE 5.7.2 -- A security vulnerability has been found that allows
39           remote searching of any table in your database configured in
40           Interchange.  To fix this vulnerability, you may need to 
41           make some adjustments to your catalog.  See "REMOTE SEARCHING"
42           below.
43
44 INSTALLING INTERCHANGE IN THE SAME LOCATION
45 --------------------------------------------
46
47 NOTE:    All below procedures assume you have installed in
48          /usr/local/interchange -- substitute paths as appropriate.
49
50 WARNING: BACK UP EVERYTHING BEFORE YOU START!
51
52     1. Make a tar backup of your Interchange software directory, e.g.
53
54         tar czvf ~/ic_backup.tar.gz /usr/local/interchange 
55
56     2. Unpack the new version of the software to a temporary directory,
57        and change to that directory.
58
59         tar xzf interchange-5.x.x.tar.gz
60         cd interchange-5.x.x
61
62     3. You can see the section below, "TO TEST BEFORE YOU UPGRADE", if
63        you want to try it out before you switch your running catalog.
64
65     4. Install it to the same location as your current software:
66
67         ## Create the makefile
68         perl Makefile.PL
69
70         ## Make the software
71         make
72
73         ## Test -- if this fails, don't worry too much.
74         make test
75
76         ## Install the software
77         make install
78
79     5. You don't need to run makecat again!!!
80
81     6. Restart Interchange.
82
83 That's it. Verify your catalog's operation, and you are live.
84
85 ---------------------------------------------------------------------------
86
87                          K N O W N   I S S U E S
88
89
90 KNOWN ISSUES UPGRADING FROM 5.10.x
91
92 1.  A bug was fixed in the [area] tag where if you previously passed a fully
93 qualified URL as the href and used the form attribute then the protocol://domain
94 portion of the URL would get overwritten by the one in VendUrl. If your code
95 relies on this buggy behaviour you need to fix it.
96
97
98 KNOWN ISSUES UPGRADING FROM 5.6.x
99
100 1. Perl 5.8.5 (unthreaded) or Perl 5.8.8 (threaded) or newer is now required.
101
102 2. The AdminUser configuration directive has been removed.
103
104 3. In PostgreSQL 8.3 many implicit type casts were removed, some of
105 which Interchange or your code may have relied on. You may find that some
106 features in the Standard demo and some Interchange core SQL may not work
107 with PostgreSQL 8.3 or newer, though recent testing with PostgreSQL 9.2
108 did not reveal any problems.
109
110 If you run into problems, the easiest way to get things working is
111 to manually put back any removed casts that you need. The included
112 eg/pg83-implicit-casts.sql script fixes the known problems with the
113 Standard demo.
114
115 4. Digest::SHA from CPAN is now a recommended module. If it is not
116 available, Digest::SHA1 will still be used as a fallback.
117
118 5. IPv6 incompatibility: Some of the session IP address verification
119 functions do not work correctly for traffic coming from IPv6 sources,
120 resulting in lost sessions. You can use catalog directive "WideOpen Yes"
121 as a workaround but see the documentation to be aware of tradeoffs:
122
123 http://docs.icdevgroup.org/cgi-bin/online/confs/WideOpen.html
124
125
126 KNOWN ISSUES UPGRADING FROM 5.5.2
127
128 1. Several old versions of CPAN modules were distributed in the extra/
129 directory but have been removed:
130
131     Business::UPS - part of Bundle::InterchangeKitchenSink
132     File::Spec - now distributed with Perl itself
133     Tie::ShadowHash - part of Bundle::Interchange
134     URI::URL - part of Bundle::Interchange
135
136 If you find Interchange won't start up, check to make sure you have all the
137 necessary Perl modules.
138
139 2. We have removed the option available in some polymorphs of the
140 database abstraction layer's set_slice() routine that allowed key/value
141 pairs to be passed in as a simple array. For example, this will no longer
142 work:
143
144     $db->set_slice($key, $field1, $value1)
145
146 But it can be rewritten as this, which has long worked:
147
148     $db->set_slice($key, [$field1], [$value1])
149
150 3. The syntax of the custom SQL function for counters has changed. At the time
151 of the feature's introduction on 2007-11-17, the syntax was e.g.:
152
153     UserDB  default   sql_counter  "userdb:custom_counter('userdb_username_seq')"
154
155 That conflicted with MySQL pseudo-sequence functionality that used the same
156 syntax. The new syntax does not conflict and has the benefit of being more
157 generic, allowing any SELECT statement:
158
159     UserDB  default   sql_counter  "userdb:SELECT custom_counter('userdb_username_seq')"
160
161
162 KNOWN ISSUES UPGRADING FROM 5.5.1
163
164 SpecialSub catalog_init has been renamed to request_init.
165
166 UserTrack now defaults to "no", so if you want the X-Track HTTP response header
167 to be output, add "UserTrack yes" to your catalog.cfg.
168
169 UserTrack also no longer affects TrackFile, so if you don't want TrackFile
170 output, you should not have a TrackFile directive in catalog.cfg.
171
172
173 KNOWN ISSUES UPGRADING FROM 5.4.x
174
175 Check the "special_pages/missing.html" file, in all of your Interchange-driven
176 websites, for a line that looks like the following:
177
178     [if type=explicit compare="q{[subject]} =~ m{^admin/}"]
179
180 If found then replace with the following two lines:
181
182     [tmpn missing_subject][subject][/tmpn]
183     [if scratch missing_subject =~ /^admin/]
184
185 Perl 5.8.0 or newer is now required. Running with threads is still not
186 recommended for production installations, but is allowed under Perl 5.8.5
187 or newer.
188
189 The long-deprecated [sql] tag has been removed. You'll likely want to
190 rewrite queries to use the [query] tag.
191
192 The ConfigParseComments directive has been removed, and Interchange now
193 behaves as if "ConfigParseComments No" has been specified. That means that
194 no configuration file line beginning with # will be parsed, including
195 #ifdef, #include, etc., as was done in the past. Bare ifdef, include, etc.
196 must now be used.
197
198 Global ActionMaps: Previously, the path passed to a global ActionMap
199 did not include the action itself, but the path passed to a catalog
200 ActionMap did include the action. This discrepancy was annoying to keep
201 track of. Now both kinds of ActionMaps receive a path that includes
202 the action. This means that all global ActionMap code will need to be
203 updated to deal with the action. Most simply, you can strip off the
204 action at the beginning of the sub something like this:
205
206     ActionMap your_action <<EOR
207     sub {
208         my ($path) = @_;
209         # remove action
210         $path =~ s:^[^/]+/::;
211         # your code here
212     }
213     EOR
214
215 Removed SOAP_Host, RequiredFields, HTMLmirror and UseCode directives.
216
217 All previously deprecated configuration directives have been removed.
218
219 Deprecated-feature pragmas and associated code have been removed:
220 * compatible_5_2 - used to keep table editor error text (mistakenly)
221   hidden, as it was the case up to Interchange 5.2.
222 * no_html_parse - used to disable parsing of MV= arguments inside HTML tags.
223
224 If MV_COUNTRY_FIELD was in use to determine the country for tax
225 purposes, then that setting needs to be changed to MV_COUNTRY_TAX_VAR.
226
227 The [either] tag historically reparsed its output. This has been changed
228 so that while the tag body parts are interpolated, the tag output is not
229 reparsed.
230
231 Removed the [fedex-query] tag, which hasn't been useful for some time
232 because FedEx discontinued their web API that the tag interfaced with.
233
234 Removed the [/page] and [/order] macros. The [page] and [order] tags have
235 never been container tags; [/page] and [/order] were macros that were
236 replaced with </a>. You should now just use </a> in HTML instead.
237
238 The various *Robot* directives have been split from the interchange.cfg
239 file into a new robots.cfg file.  If you are upgrading then you will
240 need to remove any existing *Robot* directives from your interchange.cfg
241 file and add "include robots.cfg" in their place.
242
243 A new subdomains.cfg file has been created, and should be included into
244 your interchange.cfg file with "include subdomains.cfg".  This file defines
245 a list of country-specific standardised subdomains that should be taken
246 into account when the DomainTail directive is in effect.
247
248 The session per IP counters have been changed to the new "timecard" round-robin
249 style counters.  You will need to delete the old counter files from the
250 tmp/addr_ctr directory with a command similar to the following:
251
252     rm -rf catroot/tmp/addr_ctr/*
253
254 ...be careful with the above command. If mistyped it can seriously mess up
255 your filesystem.
256
257 The [error] and [formel] tags now make use of the following CSS class,
258 that will need to be added to your CSS file:
259
260     .mv_contrast {
261         color: #FF0000;
262     }
263
264 The name of the class can be specified using the CSS_CONTRAST Variable,
265 or will default to "mv_contrast".
266
267
268 KNOWN ISSUES UPGRADING FROM 5.2.x
269
270     None.
271
272
273 KNOWN ISSUES UPGRADING FROM 5.0.x
274
275     None.
276
277
278 KNOWN ISSUES UPGRADING FROM 4.8.x
279
280 Interchange is designed to be compatible between major versions, and
281 for the most part a catalog designed under Interchange 4.8 should
282 be compatible with 5.0.
283
284 More information on upgrades is available in the document icupgrade, part
285 of the Interchange documentation package.
286
287 UPGRADE NOTES FOR FOUNDATION-STYLE CATALOGS
288 -------------------------------------------
289
290 * Add a new column "extended" to products/mv_metadata.asc. This just involves
291   adding a TAB and "extended" to the end of the first line of the file.
292
293 * If MV_COUNTRY_FIELD was in use to determine the country for
294   tax purposes, then that setting needs to be changed to
295   MV_COUNTRY_TAX_VAR.
296
297 * Remove variables UI_IMAGE_DIR and UI_IMAGE_DIR_SECURE or point
298   them to the new location, e.g. replace /interchange/
299   with /interchange-5/.
300
301 * If you didn't follow Interchange's SKU naming convention for Matrix
302   options, and assigned them arbitrary part numbers, or you hand-edited
303   the options table, you may find that your product options don't work. 
304   You should post the question to the user mail list or contact a
305   competent Interchange consultant at interchange-biz@icdevgroup.org.
306
307 * You will probably receive a message about "history-scan tag overrides global
308   definition". See the section "PROBLEMS WITH USERTAGS" below.
309
310 * The static-page build capability is no longer supported in
311   Interchange 5. You will receive warnings about "Directive StaticPath
312   no longer supported at line XXX". 
313
314   To stop these warnings, remove the NoCache directive and any
315   directive beginning with "Static" from your catalog.cfg file.
316   In the standard-style catalog, these are all located near
317   each other.
318
319   If you use the static page build facility, there are other means of
320   accomplishing the same thing with scripts. Contact a competent
321   Interchange consultant at interchange-biz@icdevgroup.org to get help.
322
323 * See the section "PROBLEMS WITH USERTAGS" below.
324
325 ---------------------------------------------------------------------------
326
327 TO TEST BEFORE YOU UPGRADE
328 --------------------------
329
330 YOU SHOULD STILL BACK UP, and in addition it is recommended you back
331 up your catalog. While the new server should not impact your running
332 catalog beyond normal catalog interaction for orders, statistics,
333 userdb, and such, it is not outside of the realm of possiblity that
334 something could happen. It should not happen in a catalog that is
335 based on Foundation and not heavily customized (i.e. using global UserTag
336 routines).
337
338 1. Install the new Interchange 5.x.x in /usr/lib/interchange-5.x.x
339 using the procedure from the README file.
340
341 2. Make /usr/lib/interchange-5.x.x/interchange.cfg match your
342 /usr/lib/interchange.cfg. Note that there may be new options; but the
343 existing one should work if you just copy it.
344
345 3. Run bin/compile_link:
346
347     cd /usr/lib/interchange-5
348     bin/compile_link -p 7787
349
350 NOTE: If you use the INET mode linking method, you have to run the
351       test server on a different port. Assuming you use the standard
352       7786 on your live catalog, you would add to interchange.cfg:
353
354          TcpMap  localhost:7787
355
356 After running compile_link, you should see four new files in the
357 /usr/lib/interchange-5.x.x/src:
358
359 -rwxr-xr-x  1 root  root  8088 Oct  3 09:59 tlink
360 -rwxr-xr-x  1 root  root  8088 Oct  3 09:59 tlink.localhost.7787
361 -rwxr-xr-x  1 root  root  7704 Oct  3 09:59 vlink
362 -rwxr-xr-x  1 root  root  7704 Oct  3 09:59 vlink._usr_lib_interchange_5_etc_socket
363
364 4. Note the Catalog lines in your interchange.cfg:
365
366   EXAMPLE:
367
368     Catalog standard /var/lib/interchange/standard /cgi-bin/standard
369
370 You should comment out all but the one you want to test.
371
372 5. Change the /cgi-bin/standard script link name to /cgi-bin/test5.
373
374   EXAMPLE:
375
376     Catalog standard /var/lib/interchange/standard /cgi-bin/test5
377
378 6. Copy the src/vlink (UNIX mode) or src/tlink (INET mode) link executable
379 to your CGI directory and name it "test5", i.e.
380
381   EXAMPLE:
382
383     cp -p src/vlink /var/www/cgi-bin/test5
384
385 7. IMPORTANT: Make sure its permissions match the permissions on your
386 running 4.x catalog! You may have to make it SUID, i.e.:
387
388   EXAMPLE:
389
390     chmod u+s /var/www/cgi-bin/test5
391
392 That should only be done if you are in UNIX mode and your current 
393 link program is SUID.
394
395 8. Add this line to the /usr/lib/interchange-5/interchange.cfg file:
396
397     Variable TEST_SERVER 1
398
399 9. Copy any *custom* global UserTag files to the usertag/ directory. Do not
400 copy any that were distributed with Interchange if you did not modify them.
401
402 10. Copy the new Interchange image and CSS files to the interchange-5
403 subdirectory in your document root, i.e.:
404
405         EXAMPLE:
406
407                 cp -r /usr/lib/interchange-5/share/interchange \
408                           /var/www/html/interchange-5
409
410 11. Modify your /var/lib/interchange/standard/catalog.cfg file to
411 point the URLs to the test server if appropriate by placing at the
412 end:
413
414    ifdef @TEST_SERVER
415    Variable  CGI_URL             /cgi-bin/test5
416    Variable  UI_IMAGE_DIR        /interchange-5/
417    Variable  UI_IMAGE_DIR_SECURE /interchange-5/
418    ## This ensures the UI image directory will be set properly
419    Pragma    dynamic_variables_file_only
420    VendURL   http://__SERVER_NAME____CGI_URL__
421    SecureURL   https://__SERVER_NAME____CGI_URL__
422    endif
423
424 12. Start the new interchange server:
425
426     /usr/lib/interchange-5/bin/restart
427
428 At that point, your catalog should be running on both Interchange 5 and
429 Interchange 4. Test thoroughly and then upgrade. Note that the UI will
430 be significantly changed, and that all features of the UI may not be
431 supported by your old catalog. The customer-facing side should function
432 in much the same way.
433
434 ------------------------------------------------------------------------
435
436 UPGRADING FROM 4.6.x
437
438 The public-facing side of a 4.6.x catalog is fairly straightforward to
439 port. The Admin UI is problematic, particularly if you have customized
440 it.
441
442 You should be able to update a catalog from 4.6.x if you are reasonably
443 proficient in Perl and/or Interchange. If you expect to rely on the
444 backend admin UI, it is sometimes better to build a new catalog from
445 scratch, and integrate your look and feel with that. Contact a competent
446 Interchange consultant to help (interchange-biz@icdevgroup.org).
447
448 That being said, here are some of the issues.
449
450 If you have this line in interchange.cfg:
451
452         #include usertag/*
453
454        You should change it to:
455
456         include usertag/*.tag
457
458        (The leading # sign is no longer needed).
459
460        If you have created any other UserTag definitions you will need
461        to either rename the file to add a .tag extension, or include
462        them explicitly like:
463
464           include usertag/my_tag
465
466        See the "problems with UserTags" section, below.
467
468 If you use CyberCash, you should replace these lines in catalog.cfg
469
470         Variable CYBER_MODE       mauthonly
471         Variable CYBER_CONFIGFILE /path/to/your/merchant_conf
472
473     with
474
475         Variable MV_PAYMENT_MODE        cybercash
476         Variable MV_PAYMENT_CONFIGFILE  /path/to/your/merchant_conf
477
478 There is one security change that can break constructs that ran under 4.6.x.
479
480     safe_data=1
481
482         If you had a database object which contained ITL tags and
483         they now show up as [itl-tag arg=val], then you probably
484         need to add the safe-data=1 parameter around your [loop ...]
485         or [query ...] construct.
486
487         The reason this change was made was the capability of Interchange
488         to directly enter user submissions into a database. If the
489         user put in something in [square brackets], knowingly or even
490         unknowingly, it could cause anomalous or insecure behavior. 
491         (There were no known exploits in the demo, but they could
492         easily be constructed.)
493
494
495 PROBLEMS WITH USERTAGS
496 ----------------------
497
498 You may see the following error/warning messages when you (re)start
499 Interchange:
500
501 1. Duplicate usertag xxxx found.
502
503     This message is most likely to mean that you have a global "usertags"
504     directory included from your interchange.cfg file.  Interchange 4.9 has a
505     new location (code/UserTag) for global UserTags.  Your old globals may
506     "clash" with the new ones.  Delete the old usertags that are named in the
507     error messages.  As always, it is recommended that you back up everything
508     before you start.
509
510     This message will also be raised if Interchange notices two local UserTags
511     with the same name.  If this is detected then rename or delete one of the
512     two UserTags.
513
514 2. Local usertag xxxx overrides global definition.
515
516     This message is most likely to refer to your local history_scan UserTag.
517     If you have this tag definition in your catalog.cfg file then you may
518     safely delete it;  Interchange 4.9 includes this as a global UserTag.
519
520     This message will also be raised if you have created a local UserTag
521     and have given it a name identical to one of the global tags (SystemTag,
522     UserTags, UI_Tag etc.)  The message is only a warning as your local UserTag
523     will override the global one.  If you didn't mean to override the global
524     tag of the same name then simply rename your tag and restart Interchange.
525
526
527 REMOTE SEARCHING
528 ----------------
529
530 A security vulnerability was recently discovered where any table configured
531 in your Interchange installation could be viewed remotely by an unauthenticated
532 user via a specially crafted search request.
533
534 This is a serious vulnerability, and all previous versions of Interchange are
535 affected. Even if you do not use the default search structure, your catalog
536 is likely to still be vulnerable.
537
538 To resolve this, a new configuration option, AllowRemoteSearch has been
539 introduced. It should be specified in each catalog configuration, and defaults
540 to:
541
542      AllowRemoteSearch products variants options
543
544 Any table specified in this option will be remotely searchable, and you should
545 not permit any table with sensitive information to be searched in this way. You
546 should carefully consider the implications of adding any further tables to this
547 configuration option.
548
549 Remote searches may be used by your existing catalog. These should continue
550 working without any changes as long as they only search tables that are permitted
551 by the AllowRemoteSearch configuration. You should carefully examine your
552 catalog for uses of the "search" form action, or pages which submit a form to
553 a page called "search" or "scan". If they specify a search file other than
554 products, variants or options, you should consider rewriting that page to just
555 accept the search terms via CGI parameters, and not the entire search. Please
556 consult the documentation on in page searches at:
557
558      http://www.icdevgroup.org/doc/icdatabase.html#In-Page%20Searches
559
560 If your catalog makes use of ActionMaps that perform searches, these should
561 continue to work as intended as long as they search a table allowed by 
562 AllowRemoteSearch. However, you should consider updating them to use the 
563 new "search" tag.  For example, an existing ActionMap that performs a search
564 like this:
565
566    ActionMap old_cat <<EOR
567    sub {
568         my ($action, $class) = split('/', shift);
569
570         $class =~ s/_/ /g;
571
572         # Originally, search parameters were placed in the CGI hash.
573         $CGI->{co} = 1;
574         $CGI->{fi} = 'products';
575         $CGI->{st} = 'db';
576         $CGI->{sf} = 'category';
577         $CGI->{se} = "$class";
578         $CGI->{sp} = 'results';
579         $CGI->{tf} = 'category,description:f';
580         $CGI->{op} = 'eq';
581
582         $CGI->{mv_todo} = 'search';
583         $CGI->{mv_nextpage} = 'results';
584         # And the "update" tag was called to re-evaluate the page with
585         # the provided search parameters.
586         $Tag->update('process');
587         return 1;
588    }
589    EOR
590
591 Would be updated to instead look like this:
592
593    ActionMap new_cat <<EOR
594    sub {
595         my ($action, $class) = split('/', shift);
596
597         $class =~ s/_/ /g;
598
599         # Now, you must create a hash to hold the search
600         # parameters.
601         my $search;
602         $search->{co} = 1;
603         $search->{fi} = 'products';
604         $search->{st} = 'db';
605         $search->{sf} = 'category';
606         $search->{se} = "$class";
607         $search->{sp} = 'results';
608         $search->{tf} = 'category,description:f';
609         $search->{op} = "eq";
610
611         $CGI->{mv_nextpage} = 'results';
612         # And call the new search tag, which isn't subject to the
613         # AllowRemoteSearch restrictions.
614         $Tag->search({ search => $search });
615
616         return 1;
617    }
618    EOR
619
620 If you are using a modern version of the standard catalog as the basis
621 for your catalog, there is a special subroutine that provides friendly
622 URLs for product categories, but is not a traditional ActionMap.  Similar
623 to the example above, you will need to alter your catalog.cfg, replacing
624 the entire Sub ncheck_category with:
625
626 Sub ncheck_category <<EOS
627 sub {
628     my ($name) = @_;
629     return unless $name =~ m{^[A-Z]};
630     $name =~ s,_, ,g;
631     my ($prod_group, $category) = split m{/}, $name;
632
633     my $search;
634     $search->{co} = 1;
635     $search->{fi} = 'products';
636     $search->{st} = 'db';
637     $search->{sf} = join "\0", 'prod_group', 'category';
638     $search->{op} = join "\0", 'eq', 'eq';
639     $search->{se} = join "\0", $prod_group, $category;
640     $search->{sp} = 'results';
641     $search->{mv_todo} = 'search';
642     $Tag->search({ search => $search });
643     if (($o = $Search->{''}) && @{$o->{mv_results}}) {
644         return (1,  $Config->{Special}->{results});
645     }
646
647     return;
648 }
649 EOS
650
651 In the standard and foundation catalogs, the "lost password" feature makes use
652 of the remote search feature to be able to retrieve lost passwords. We recommend
653 that you remove catalog/pages/query/get_password.html from your catalog, and
654 replace catalog/pages/query/lost_password.html with an updated version from this
655 distribution. As an alternative, you may apply the following patch to your
656 existing catalog/pages/query/get_password.html:
657
658 diff --git a/dist/standard/pages/query/get_password.html
659 b/dist/standard/pages/query/get_password.html
660 index 2d70c84..5aa51f1 100644
661 --- a/dist/standard/pages/query/get_password.html
662 +++ b/dist/standard/pages/query/get_password.html
663 @@ -32,8 +32,10 @@ ui_template_name: leftonly
664         if( $Scratch->{tried_pw_retrieve}++ > 10 ) {
665                 return "No way, Jos&eacute;. Too many times.";
666         }
667      $CGI->{mv_todo} = 'search';
668         $Config->{NoSearch} = '';
669 +       push(@{$Config->{AllowRemoteSearch}},'userdb');
670 +       return;
671  [/perl]
672  [update process]
673  [search-region]
674
675 This is not a recommended solution, and is only a workaround until you can
676 consider the changes in the updated lost password page.
677
678 If you do not wish to upgrade your Interchange installation to fix this
679 vulnerability, patches for all currently supported Interchange versions are
680 also available from http://www.icdevgroup.org/. You will still need to
681 follow the upgrade advice contained here.