25 Years of Programming Community Forum
Blog  Sitemap  Services
September 06, 2010, 11:44:14 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Many people land on pages of this website with questions that could easily have been answered if they'd asked. If your question wasn't answered on one of the web pages, feel free to ask in the forum.
 
   Home   Help Search Login Register  
This is a link to the Chat Room (for Firefox+ChatZilla) when you are logged in.
View help topic about using Live Chat
Poll
Question: What is your preference for included content?
The FrontPage included content webbots.
PHP
ASP
Apache Server Side Includes
Other
Don't know yet.

Pages: 1   Go Down
  Print  
Author Topic: Replace FrontPage webbots with PHP includes (blog comments thread)  (Read 2949 times)
0 Members and 1 Guest are viewing this topic.
SteveW
Administrator
Full Member
*****
Offline Offline

Posts: 191


WWW
« on: November 28, 2007, 03:40:38 AM »

This thread is for reader comments and questions about the blog article "How to replace FrontPage included content webbots with PHP includes - and a walkthrough of a Regular Expressions Find and Replace".

You can start a new thread, if you prefer.
« Last Edit: March 31, 2008, 03:44:25 AM by SteveW » Report to moderator   Logged
nistmaru
Newbie
*
Offline Offline

Posts: 1


« Reply #1 on: February 09, 2008, 06:59:47 AM »

I thought your article was quite well thought out, and seemed to be exactly what I need to solve an issue I'm having, but for some reason, when I test it out, the FrontPage webbot stops working.

I'm trying to use a PHP include on a form the emails the results to a specified address. Before I use the include, the form works fine, but once I add the PHP include, it stops working.

The main reason for doing this, is to remove the email address the forms sends to from the code on the page so that it cannot be harvested.

Please take a look and let me know what I'm doing wrong!

I've put together a basic form just to get this working, once I do, I will incorporate the solution into the final form.
Here is the form code:

<form method="POST" action="--WEBBOT-SELF--" onSubmit="">
<?php include($_SERVER['DOCUMENT_ROOT'] . '/inc/fpwebbot.php'); ?>

  <input type="text" name="name" size="20"><br>
  <input type="submit" value="Submit" name="B1"><input type="reset" value="Reset" name="B2"></p>
</form>

Here is the code from the page fpwebbot.php (located in the folder named inc)

  <!--webbot bot="SaveResults" u-file="_private/form_results.csv" s-format="TEXT/CSV" s-label-fields="TRUE" b-reverse-chronology="FALSE" s-email-format="TEXT/PRE" s-email-address="webmaster @ mydomain.com" b-email-label-fields="TRUE" b-email-subject-from-field="FALSE" s-email-subject="form test" s-builtin-fields startspan --><input TYPE="hidden" NAME="VTI-GROUP" VALUE="0"><!--webbot bot="SaveResults" endspan i-checksum="43374" --><p>

[Reason for edit: changed example email address so it doesn't create a mailto link to mydomain.com, which turns out to be a real website.]
« Last Edit: May 18, 2008, 02:00:34 PM by SteveW » Report to moderator   Logged
SteveW
Administrator
Full Member
*****
Offline Offline

Posts: 191


WWW
« Reply #2 on: February 09, 2008, 12:23:54 PM »

Hello nistmaru, and welcome to the forum.

It's been a long time since I used a FrontPage email form, so I haven't looked closely at your code yet to find the specific reason it isn't working, but I wanted to get this reply to you quickly because I think even if you get it working, it isn't going to achieve the result you want.

Email addresses are harvested by robots from the source code of the page that is sent out from the server when that page is requested, not from the source code of your page as it sits on the server. So pulling out the email address into an include file won't make any difference. Here's what I mean:

If you don't use the PHP include, your code on the page that is sent out from the server looks like this:

Example #1:

Code:
<form method="POST" action="--WEBBOT-SELF--" onSubmit="">
<!--webbot bot="SaveResults" u-file="_private/form_results.csv"
s-format="TEXT/CSV" s-label-fields="TRUE"
b-reverse-chronology="FALSE" s-email-format="TEXT/PRE"
s-email-address="webmaster@mydomain.com"
b-email-label-fields="TRUE" b-email-subject-from-field="FALSE"
s-email-subject="form test" s-builtin-fields
startspan -->
<input TYPE="hidden" NAME="VTI-GROUP" VALUE="0">
<!--webbot bot="SaveResults" endspan
i-checksum="43374" --><p>

  <input type="text" name="name" size="20"><br>
  <input type="submit" value="Submit" name="B1">
  <input type="reset" value="Reset" name="B2"></p>
</form>

If you do use the PHP include, your source code is what you provided:

Example #2:

Code:
<form method="POST" action="--WEBBOT-SELF--" onSubmit="">
<?php include($_SERVER['DOCUMENT_ROOT'] . '/inc/fpwebbot.php'); ?>

  <input type="text" name="name" size="20"><br>
  <input type="submit" value="Submit" name="B1">
  <input type="reset" value="Reset" name="B2"></p>
</form>

but when PHP processes the include, it grabs the text from the include file, and inserts it at the specified location, so the end result looks like this:

Example #3:

Code:
<form method="POST" action="--WEBBOT-SELF--" onSubmit="">
<!--webbot bot="SaveResults" u-file="_private/form_results.csv"
s-format="TEXT/CSV" s-label-fields="TRUE"
b-reverse-chronology="FALSE" s-email-format="TEXT/PRE"
s-email-address="webmaster@mydomain.com"
b-email-label-fields="TRUE" b-email-subject-from-field="FALSE"
s-email-subject="form test" s-builtin-fields
startspan -->
<input TYPE="hidden" NAME="VTI-GROUP" VALUE="0">
<!--webbot bot="SaveResults" endspan
i-checksum="43374" --><p>

  <input type="text" name="name" size="20"><br>
  <input type="submit" value="Submit" name="B1">
  <input type="reset" value="Reset" name="B2"></p>
</form>

which is exactly the same as Example #1. In other words, pulling the email address out into an include file doesn't change the code that your server actually sends to whoever requested the page because the code is put right back where it was in the first place.

------------

When somebody fills out your form and submits it, their browser sends all the data back to a "forms handler" program on your server. In the case of FrontPage, that forms handler program is a part of the "FrontPage Extensions".  Because the email address to which it should send the resulting email is not hard-coded into the forms handler program itself, it has to be part of the data sent back from the client's browser, which means that the email address has to be in the source code of the page. Unfortunately, I'm not aware of any tricks that allow hiding or obscuring the email address when using the FrontPage forms handler. I could be wrong, but that would seem to mean FrontPage email forms are always vulnerable to harvesting.

One solution would be to use a different forms handler, one in which the email address is hard-coded into the script itself. That way, when incoming forms data arrives, the script doesn't have to be told where the email should go, because it already knows. 

One forms handler that does this, and the one I've seen most often recommended by people knowledgable about the security issues of forms handlers is called NMS FormMail. It is available at http://nms-cgi.sourceforge.net/scripts.shtml. There is a walk-through of how to modify FrontPage forms to use it at http://25yearsofprogramming.com/blog/2008/20080518.htm. NMS has the additional advantage of getting you one step away from dependence on the FP extensions.

I'll be happy to try to help if you encounter problems.

When I stopped using the FrontPage forms handler, I wound up abandoning forms altogether, and switched to a ridiculously simple alternative: I just put my email address on the web page like:  address AT mydomain DOT com.  That wouldn't be suitable for everyone, though. Sometimes a form is needed.

« Last Edit: May 18, 2008, 02:04:07 PM by SteveW » Report to moderator   Logged
SteveW
Administrator
Full Member
*****
Offline Offline

Posts: 191


WWW
« Reply #3 on: March 16, 2008, 12:46:30 PM »

I doubt you're still working on this, but I forgot to mention that when trying to troubleshoot something like your original example, a good procedure would be to:

1) Publish the page to your website with the original webbot code.
2) Go to it with your browser.
3) Use View Source to see the HTML output. Save the text.

4) Publish the page to your website using the PHP include code.
5) Go to it with your browser.
6) Use View Source to see the output. Save the text.

Now carefully compare the text between the <form> and </form> tags.

If text is missing in the PHP version, it's possible PHP isn't processing the page.
Also make sure there are no errors in the PHP error log. Is it finding the include file ok, etc.?
Report to moderator   Logged
carlwohlforth
Newbie
*
Offline Offline

Posts: 2


« Reply #4 on: October 16, 2008, 06:02:10 PM »

I am converting my FrontPage website into something I can update with Expression Web. I'm getting back into programming after an absence. It took me longer than I care to admit to suspect that the server I use processes PHP in files with a .php extension but not files with an .htm extension.

In other words if my file to test PHP include () is named test.php it works as expected but if it is named test.htm it doesn't work. Since all the files I want to convert have .htm extensions I am stymied. I don't want to rename all my web pages .php....

Any suggestions or insight will be appreciated.
Report to moderator   Logged
SteveW
Administrator
Full Member
*****
Offline Offline

Posts: 191


WWW
« Reply #5 on: October 16, 2008, 08:19:33 PM »

If you're on an Apache server, this is easy to resolve with a configuration setting in your .htaccess file. See http://25yearsofprogramming.com/blog/20070808.htm, about 2/3 down the page at section "3) Modify your .htaccess file... 3. Optional..."

The variation of the line you use to tell Apache to process .htm files as if they were .php seems to vary depending on the Apache version, how PHP is installed on it, which version of PHP it is, and what other options are installed or enabled.

Your webhost might have a FAQ or a forum where they've posted the correct line to use. Otherwise, trial and error can work ok.

Since suPHP doesn't seem to be that common, I think I'd start with the "Apache 2 without suPHP" one first. If you can't find something that works, I can find more ideas. It will help to know the various Apache/PHP etc. versions as described above.

There is a central page at Apache where you can find the documentation on AddHandler and AddType if you need more info: http://httpd.apache.org/docs/1.3/mod/directives.html
Report to moderator   Logged
carlwohlforth
Newbie
*
Offline Offline

Posts: 2


« Reply #6 on: October 17, 2008, 10:21:18 AM »

Thanks! I greatly appreciate the articles and the reply. Following your suggestion I discovered a forum on my web host, searched and found a solution there. In case you are interested it is:

<FilesMatch .htm>
SetHandler application/x-httpd-php5
</FilesMatch>

Now I will continue removing my shared borders then come back to read the article about converting FrontPage themes to CSS...
Report to moderator   Logged
SteveW
Administrator
Full Member
*****
Offline Offline

Posts: 191


WWW
« Reply #7 on: October 17, 2008, 05:55:27 PM »

Thank you very much for posting the solution you found. It's sure to help others.
Report to moderator   Logged
Pages: 1   Go Up
  Print  
 
Jump to:  


Yahoo! Search
Search the web Search this site
 
Mazeguy Smilies Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS! View content labeling at ICRA.