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