API
@-Formulas
JavaScript
LotusScript
Reg Exp
Web Design
Notes Client
XPages
 
Protect $$-Templates
Someone who knows what they're doing can really cause a headache for your database very easily. For example, if you're in a Domino database from the browser, how easy would it be to put in .../$$ViewTemplateDefault?OpenForm in the URL? This could open up the view template as an actual form which can be submitted to the server. And that form could be submitted hundreds of times, filling up your precious disk space which could cost you money if you're paying someone to host your site.

But there is a better way!!

There's some simple things you can do to protect your $$ Templates from unauthorized use. One item you can try is to make the form entirely HTML. This setting is available on the Defaults Tab when you're in design on a form. If you have this set, then when someone tries to do an ?OpenForm on that form they'll get this error message:

Error 500 - Documents treated as HTML cannot be edited. This protects your form from unauthorized "submission".

There is one drawback to using this method, however. You can't use an "Embedded View" or "Embedded Navigator" in your form when the form is entirely HTML.

Plan B

One other thing you can do is to put a hidden submit button down at the bottom of the form, shown only when in edit mode. To put a hidden submit button on the form, you can put in the "hide" HTML tag (<!--) (that's an open tag, exclamation point, then two hyphens) right before the "submit" button and an "unhide" HTML tag (-->) (that's two hyphens, then the close tag) right after the button. The button has to be a regular Notes button (not HTML) so Domino won't put its own button on the form. Note that the comment before and after has to be in pass-through HTML and button not in pass-through HTML. For this method, we prefer to use the bracket notation because it can all be on one line and we don't have to worry about whether the button should be pass-through HTML or not.

In addition to hiding the submit button, it's also a good idea to add the SaveOptions field to your form. The field should be a hidden, computed, text field that computes to a text value zero ("0"). This will prevent documents with this form from being saved to disk. Because even with hiding the submit button, a savvy (and nasty) programmer could take your HTML code, modify it, add a submit button, and view that updated HTML in their browser. Then they would be able to submit pages to your server, even though you hid the submit button. But adding SaveOptions will prevent that submit from being written to disk.

One Other Thing.

We like to have $$ Template for specific views and navigators rather than just one Default. Frankly, the $$ViewTemplates aren't used much in our designs (they aren't used at all in the Breaking Par web site). A developer has much more control over the look of views when they are built on the fly. But that's another story. Anyway, since we don't usually have a default $$ViewTemplate or $$NavigatorTemplate, most of the time we end up putting one in with a "hey, don't do that" message and a link back to the home page. If the user is getting cute and trying to open up a view that we don't intend for web users to see (it's a lookup view or something), we don't want the user to be able to see that info. So the Default Template shows up and tells them that's a no-no. In the past we used to put security on $$ViewTemplateDefault which would prompt the user typing in the URL. The intention there was that there was no way they could get in because that form was so secured, but we decided that the user would probably think they could get in if they just knew the password and would keep trying different things. So we decided that probably wasn't as good of an idea as was anticipated.