Customizing WebPublisher Edit Feedback

by Peter Tyrrell Wednesday, October 19, 2005 4:53 PM

I was recently asked to develop an alternative to the WPP edit feedback page. The complaint was that it showed all the fields, could not be customized to suit the intranet template, and looked the same for all textbases. What would be nice, they said, is a different feedback page for each database, that didn't show all the fields, and that could have a completely customizable look. The file that all edits submit to, which performs all database interactivity and which acts as the feedback page, is /dbtw-wpd/asp/iwpp-edit.asp. It is a bad idea to mess with any file in the WebPublisher install directory which will be overwritten with each WPP upgrade, so I didn't want to touch it. I created a copy of it instead and moved it to an application subfolder, beneath the search page/new record page location: [application root]\EditHelper\iwpp-edit.asp. This makes it simple to keep track of and I don't disturb the original. I changed nothing in my new copy of iwpp-edit.asp except for the addition of a script block at the very end which redirects after database interaction, based on the name of the textbase being edited, and passes on any error message from the edit. For example, a textbase called "sales" would be redirected to [application root]\EditHelper\sales\EditSuccess.htm on a successful edit action. EditFailure.htm is similar but has some script that picks up the error msg from the query string and displays it on the page. The only addition to the edit forms was adding script to change the form action on page load. Instead of /dbtw-wpd/asp/iwpp-edit.asp, the edit form posts to EditHelper/iwpp-edit.asp. Since the dynamic edit form does not expose its body tag onload event, I attached an event listener from the script. The addition of a new textbase to this scheme is easy because redirection is based on textbase name. I just need to add a new folder under EditHelper which matches the name of the textbase, e.g. [application root]\EditHelper\catalog, and put a "catalog" version of EditSuccess.htm and EditFailure.htm in there. Easy peasy.



Run query on page load

by Peter Tyrrell Monday, October 17, 2005 10:39 AM

To run a canned query when a web page is loaded, instead of a user having to manually begin the query by clicking a link:

<head> <script type="text/javascript"> window.location.replace("http://localhost/dbtw-wpd/exec/dbtwpub.dll ?AC=QBE_QUERY&TN=cars&RF=Full+information&QY=Findall"); </script> </head>

Obviously the query itself will change depending on your needs, but the key is to set the window.location to the canned query url.


International Directory of Forest Information Services

by Administrator Sunday, October 16, 2005 11:42 AM
The International Directory of Forest Information Services: Libraries, Documentation Centers and Subject Specialists is available online at

The Directory was formally launched at the IUFRO European Regional Conference in Copenhagen in August 2002, however it was manually updated until late 2003. Andornot was approached to host the database and develop a web interface that would allow participants to both register and update their records online.

The site uses the Andornot templating system and WebPublisher PRO to provide an easy to maintain site that permits both web searching and data entry. Some simple measures were also taken to provide protection against misuse as this is a publicly available website.

Design specifics:

To avoid the possibility of pranksters entering records into a live database, an access control field was added to the database that allows the silent password (i.e. the default web access) to see only records with "Active" in this field.

When new entries are submitted through the Registration page they are tagged with a status of "New" and cannot be seen until validated and changed to "Active" by the IUFRO administrator. The registration page was exported from DB/TextWorks as a web edit form and then modified to include code for this hidden field, i.e.

Registrants in the directory can update their own records using their email address and a password. We used a Random Password Generating program which creates passwords that contain just alphanumeric characters to avoid inserting characters that have meaning to WebPublisher. We then populated the database with these passwords and created a DB/TextWorks form that included the persons name, email and new password. The text also gave instructions on how to update their record and change their password to one memorable to them. We then used the "mail each record to a different address" feature within DB/TextWorks to notify everyone of their passwords using this form.

Registrants can update their own records through the login page. ( This was created in DB/TextWorks as a query screen and then exported to HTML. A couple of validation scripts were added to this page to ensure that searches find only the one record that exactly matches the username and password. The first script turns all entries into terms, i.e. ="term" to prevent anyone entering >h* to find any entry starting with h or telus to find records with a Telus email account. It also disallows a * as a search term. Another script ensures that there is an entry in both boxes.

The registration form has popup validation lists. If new registrants enter a term not in the validation lists it will not be added. However when an Administrator edits the record to change the status to Active, on saving, these new values will be added to the validation lists. This is set in the DB/TextWorks forms. The Registration form has the value and the Admin one .

An unlinked page has been set up where the Administrator can search the Status field for newly added records. The admin password must be entered to edit these new records or delete records. Another script ensures that a password is entered to prevent edit access by anyone inadvertently finding this page. Additional display forms were created matching the public search forms but with Edit and Delete options.

The IUFRO site highlights the possibilities available with WebPublisher PRO and some minimal scripting. For sites where more stringent security or roles based access is needed, Andornot offers complete application design services.

Contact Andornot for more information

WebPublisher security and our WPDK

by Peter Tyrrell Thursday, October 13, 2005 11:39 AM

We have many times discussed amongst ourselves the best way to deal with the following security issue: the WebPublisher dll must either be open to anonymous access or locked down, but not both, at least through the same IIS alias. Even though an anonymous user has access to the dll, they should not be able to retrieve results from every database.

What we have done up until now is create a .NET control (the Andornot Results Control) that takes a query, whether a form POST or a canned query string GET, and handles communication with the WebPublisher dll. The active account being used is therefore the ASP.NET worker process account (NETWORK SERVICE on Win 2003) and not IUSR_machinename. We give NETWORK SERVICE the permissions on the WebPublisher install directory it needs (same as IUSR has). We then strip IUSR permissions from the "internal" databases. Even if an anonymous user knows an internal database name and constructs a canned query to target it, NTFS permissions deny them.

Now, the funky thing is that the WebPublisher dll does not behave the way you think it would. If directory security on the dbtw-wpd alias is set to both anonymous access and integrated Windows authentication, as is the default case, then these two things should happen in IIS: 1) Anonymous requests to any database with permissions allowing anonymous read requests should return results without further ado. This happens. 2) Anonymous requests to any database that DOES NOT allow anonymous read requests should return a HTTP 401 Access Denied and a message that says integrated Windows authentication is acceptable. A bit of back and forth occurs, but essentially if the requestor has Windows credentials, they should be accepted and the request carried out.

In the case of our .NET control, what should happen is that the initial request should bounce, but that the passed-in credentials (proof that it is operating as NETWORK SERVICE) should be accepted and the request fulfilled. This does not happen. The WebPublisher dll sends back a 401 for the initial anonymous request for a database with no IUSR read permissions, but then is unable to accept valid credentials and thus does not fulfill the request. So, we must set up two dbtw-wpd directories, one with anonymous access allowed and one without, until we come up with something better. We recently brainstormed about this, and we'll see what we come up with.

You can get more information about IIS authentication here: MSDN Authentication and Security for Internet Developers More information about the Results Control and the WPDK (WebPublisher Developer Kit) here:


Peter Blum's spidey senses detect a Cry For Help

by Peter Tyrrell Thursday, October 06, 2005 7:20 AM

Peter Blum himself comments on my naive, whiny and complaining post. I am so impressed! It's like making a disparaging remark about Brad Pitt in a DVD you rented, and having him, surprise!, drop by later to personally explain. The Validation and More package is incredible. I just didn't expect it to cover so much ground. And that's a good thing, regardless of my mewling over how much I have to learn. Okay, so, wow! Thanks, Mr. Blum - my personal estimation of you just rose about 1000%.


Month List