Skip to main content
    Country/region select      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

The question before us today: should the DXL Exporter give an error and refuse to export design elements if (a) the user has less than Designer access to the application, and/or (b) the design of the application is hidden?

I'm going to argue that the answer is "no" in both cases. At the moment, there are restrictions -- you can't export any design elements if the database design is hidden, and (last I checked) you can't export an entire design at once if you don't have Designer access, but you can export individual design notes.

Some of you might regard these as security features, e.g. if you're using hide design to prevent users from seeing information in "hidden" fields, you don't want them to export the form design and see what the field names are. Others, including myself, regard these limits as a nuisance that does far more harm by preventing useful applications, than any good that may come from making it easier to hide information.

This is an example of "security through obscurity;" it only protects your information insofar as the people trying to get to it don't know how the technique for bypassing the restriction. Security through obscurity is still security; for instance, I know that it's not all that hard to open any combination padlock if you know the trick, but I'm not overly concerned that someone will use that knowledge to break into my gym locker (though I always give the dial a couple of turns to make it harder, should anyone try). But security of any sort is only valuable if there's not an obvious workaround.

There are several APIs that let users access information about Notes databases and design elements. None of these APIs are restricted by lack of Designer access or by design hiding (except that you can't get formulas that are hidden without going to the C/C++ APIs).

For instance, here's a very simple way to see the values of hidden fields in a database with hidden design. Any user can do this even without the Designer client, and without using DXL.

There are also various tools, such as NotesMan and the Teamstudio suite, that let users with zero application development skill get all sorts of detailed information about nsf files. The NotesPeek program, which is publically available, also will give you basically all the information you would need to know about an application. DXL adds very little to that.

Even without such tools, a user who can program in LotusScript or Java can use those APIs to get basic information about the names of design elements and their contents -- a list of all the fields on a form, for instance. The DXL restrictions I'm discussing seem to be aimed at users who can program, who have a Designer client, and are looking for information that they couldn't get from these other APIs or from publicly available tools. To me, this sounds like an empty set.

But let's just suppose for a moment that there are such users. We have to also assume that they aren't bright enough to use the NotesNoteCollection class to get all the design elements in the database and copy them to a local database without a hidden design, in which they are Manager. Then they can use DXL to their hearts' content. This is really pretty obvious, and takes maybe 10 lines of code.

The Hide Design feature, in particular, isn't really appropriate to use for security. Read/write access to documents and design elements, database ACL lists, and the like -- those are security. There are too many ways for an even somewhat clever person to get access to any information that they technically do have access to, for that to be effective as a security measure. Hide design's real purpose is to protect proprietary source code.

So in brief, these DXL limitations do very, very little to protect information, but they do make it more difficult to write efficient applications that use DXL to do useful tasks, such as scanning databases on a server for fields without field help or images without alt text.

Please comment. If you support leaving these restrictions in place (or adding to them!), could you give examples of a way in which they increase security or some other benefit?

Andre Guirard | 1 July 2009 01:32:56 PM ET | Caribou Coffee, Plymouth, MN, USA | Comments (15)


1) DXL and fake security
Brian Miller | 7/1/2009 3:35:55 PM

I agree - No on both.

I expect to write applications in which Authors and Editors can run scripts that do things by reading and writing design elements by way of DXL. If this is not permitted, I have to add the extra step of changing the user context in order to run the script. No point in having that as a restriction, really.

2) Agreed. Limitation outweighs any benefit.
Tim Tripcony | 7/1/2009 3:56:25 PM

No on both

(aside: when I tried to append [EOM] to the comment subject and post with an empty comment field, was told it was blocked by the spam filter)

3) You’re right, no on both
Robert McDonagh | 7/1/2009 4:00:32 PM

-No content-

4) No way!
Mac Guidera | 7/1/2009 4:12:23 PM

I agree!

5) I Agree
Peter Presnell | 7/1/2009 4:17:07 PM

I agree Andre. Besides, the people most likely to be doing a DXL export are also the ones most likely to either know how to bypass the "security" and/or have access to the tools that can.

6) I agree, NO!
Colin Macdonald | 7/1/2009 6:13:03 PM

Absolutely most emphatically NO on both!

I've written code for dynamically generated dialogs that would break if this were the case. Then I think this might break some of Rocky's SAP integration stuff, but I could be wrong.

Besides all the other techniques you mention, you could just read the design elements out of the cache.ndk on the client.

So don't start down this slippery slope.

7) I agree - no on both.
Ernie Mercer | 7/1/2009 6:38:05 PM

I agree - no on both. I ran into this problem recently when I needed to scan all databases on a server for certain coding references and couldn't processes some databases due to ACL restrictions. I had to temporarily get full admin access rights in order to complete the job.

8) Agree, no on both...
Jamie Magee | 7/1/2009 7:20:05 PM

Anyone can download the free version of NoteMan Toolbar, select any doc anywhere in Notes (even in a hidden design), and can see any field value or open any design element in a couple of clicks. Even without a tool, you can copy a document to another db (such as your mail file), then look at document properties.

9) No on both, esp. first
Kendall | 7/2/2009 12:06:09 AM

I wasn't aware there were things you could do in LS that would fail if you didn't have a certain piece of software installed. This doesn't make any sense to me. So, BIG no on #1.

#2, I don't care about (never use hidden designs).

10) agree to all, "no" to both
Julian Buss | 7/2/2009 3:15:55 AM

agree to all, "no" to both

11) I Agree, no on both
Arshad Mahmoud | 7/2/2009 4:34:29 AM

#1 & #2 are like brick walls, which with the correct ladders can be climbed, so why place the wall in the first place.

12) I totally agree
Peter von Stöckel | 7/2/2009 6:20:24 AM

It is pointless to put this kind of restrictions in place.

13) Hmmmm
Nathan T. Freeman | 7/2/2009 10:51:19 AM

I think I'm going to say to leave the restrictions in place, just to be contradictory. ;-)

(Kidding, of course. Remove the restrictions -- they are silly and useless.)

14) I agree, no to both...
Art Zoutendijk | 7/2/2009 2:56:16 PM

The scanEZ Lite tool also lets you access a doc and see its fields…This is also free and publicly available to anyone (like Notespeek)...And since scanEZ uses the Notes API you can also use it to perform a DXL export (no matter what kind of restriction there is on the Notes Client or Designer).

15) I agtee, no to both ...
Harald Wolf | 7/28/2009 3:03:23 AM

The DocViewer Sidebar widget will show you all fields of documents including their values, even if there are hidden, too. So just remove the restrictions like Andre said.

 Add a Comment
Comment:  (No HTML - Links will be converted if prefixed http://)
Remember Me?     Cancel

Search this blog 


    About IBM Privacy Contact