Preventing Import

Bill-Hanson
Bill-Hanson used Ask the Experts™
on
I need to be able to prevent users (Author with Create Documents enabled) from using the "File - Import" menu item to import documents into a database.  I'm pretty sure that it can't be done, but I thought I'd ask anyway.  Does anyone know if it is possible?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
just a couple thoughts ...

i guess you can run your database in the kiosk mode

nlnotes.exe /kiosk server!!path\filename.nsf

but then user can relaunch notes in regular mode and open database

also, you can put in plase database script that would change ECL for current user and take away "File System" access until database is closed (and access is restored). however, the ECL change would apply to all client activities, so user would not be able to attach/detach attachments to the mail until database is closed etc


Sjef BosmanGroupware Consultant
Commented:
There is a possibility, I think, but there ought to be a better one: create an agent that's triggered on When documents are Created or Modified. It'll surely catch the created documents, but... is it possible to find out if those documents were imported? Maybe. Just some thoughts:
- there might be some special field that indicates that it's an imported document, but I don't think so.
- if your agent is triggered on multiple documents, you can judge by the time they were created that they are imported
- if many documents have been imported and some poor sod creates a reall document while the import is running, his document will be considered as import as well
- maybe you can sign real documents with some special sign that cannot be faked by an Import??

Anyway, I think this makes another fine idea for IdeaJam: suggest a QueryDocumentCreate and PostDocumentCreate in the Database Script of a database. If you don't post it I will, but it's your idea and yours to describe and defend.
just extending your thought on Created or Modified agent...
It is my understanding that creating documents through import is a backend process. So you can flag documents when user created document through UI front-end process. You can also flag documents if you have your own backend processes that create documents.
If any of the flags are missing then the document is created through "illegal" backend process, i.e. import
I understand that this is far from perfect as this solution is "retroactive" and you want "proactively" prevent import into the database
C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.

Author

Commented:
Thanks for the comments!

Here is my particular situation.  I have a database that contains several forms (StaffMember, Department, OutOfOffice, etc).  I control who can create/edit/read a particular document type using roles (UserModifier, EditUnits, EditOOO, etc).  Each form is associated with a role in the ACL.  Standard users do not get any roles enabled, but still have Author access with CreateDocuments enabled in order to use certain tools such as being able to create and maintain their own personal OutOfOffice profile.

So in a nutshell, the scenario is that users needs to create and edit certain forms but not others.  For example, user "A" can read all documents in the database, but has a role enabled that grants access to create and edit any OutOfOffice document.  This user is setup as an AUTHOR with CreateDocuments enabled and the "EditOOO" role assigned.  Since no other roles are assigned, the user should not be able to create any other document type.

Here is how I setup the security for this database:

1) Hide all forms from the "Create" menu ("Include in menu" form property).
2) Provide "Compose" view actions and links that are only visible to users with the proper role enabled.
3) Control who can create documents using the "Who can create documents with this form" form property and the specific role for that form (it would be nice if Import obeyed this setting!).
4) I have AUTHORS and READERS fields on all secure forms.  These contain the specific roles for that form.
5) Added code to all views to prevent pasting documents.

Well, guess what?  If the user decides to use Import (or any other data loader that uses back-end methods), he can bypass all of my "security" precautions.  He can even check a box to have the imported documents computed with any form in the database, so adding a special field to the form as a flag will not work.

To answer your specific responses:

>> "you can run your database in the kiosk mode"
Not a bad idea, but kiosk mode is a bit too limiting and savvy users can bypass it.

>> "database script that would change ECL"
Again not bad, but easy for savvy users to bypass and creates several other design limitations.

>> "create an agent that's triggered on When documents are Created or Modified"
This was my first thought, but I want to avoid it if there is another, more proactive solution.  I'll probably end up using a flag and an agent in the end, though.

>> "you can flag documents when user created document through UI front-end process"
This is what I will probably end up doing since I can control most of the process.  My first thought is to use QuerySave in the Notes Client and a WebQuerySave agent for web browsers to set the flag.  This is still not "true security" because it can be circumvented by a savvy user who knows the name and value of the flag field (examining document properties will reveal the field and value pretty easily).  I guess I could hide the database design, but I'd rather not.

I'm looking for any documented or undocumented feature including using EXTMGR_ADDINS and NSF_HOOKS with custom DLLs.  The solution needs to be bullet-proof with no way for the user to circumvent security.  Like I said, I don't think this is currently possible.  I'm just gathering ideas.  I'll leave this question open for a couple of days, then split points.

Sjef, you're right.  Lotus needs to provide this feature.  I went ahead and posted the idea in IdeaJam.  Here's a link to the page:
http://ideajam.net/IdeaJam/P/ij.nsf/0/62563C60531348038625751B005A67C4?OpenDocument
Sjef BosmanGroupware Consultant
Commented:
You have two statements in the above:
1) ... so adding a special field to the form as a flag will not work...
2) ... I'll probably end up using a flag and an agent in the end...

I'll let you draw your own conclusion.

The EXTMGR stuff won't work: I create a local replica and by Jove there's no EXTMGR here!

The ONLY bulletproof way (IMHO) is to use a controlled-access section on the form, with a signature, and a signature that's ONLY set when the document is created and verified by YOUR QuerySave or PostSave events.

No signed section? No valid document. QED.

Author

Commented:
>> "I'll let you draw your own conclusion."
I already stated my own conclusion above, which is this - I'll probably end up using a flag and an agent because I think that there is no true solution for this problem.  A flag and an agent seems to be the most secure option at this point.

>> "I create a local replica and by Jove there's no EXTMGR here!"
EXTMGR_ADDINS is a notes.ini entry that allows programmers to provide custom features in the Notes client.  It has nothing to do with a local replica!

>> "use a controlled-access section on the form,"
Good idea, except that this will only work in the Notes Client.  Since our apps run in the web browser as well as the Notes client, controlled-access sections are not an option for me.
instead of the flag you can collect DocumentUniqueID of the properly created documents in the database profile(s) - one profile for each role etc or similar arrangements.

Profiles are cached so the access to verify documents should be quick and no flag will show up in documents.
The profiles are not as easy visible as document properties (although you can access them through notespeek or programatically). You can also sign (or even encrypt?) profile documents

Author

Commented:
I have plenty of "retroactive" workaround ideas including the flag and agent method.  I could even generate new unique keys for the flag values each time the validator agent runs to thwart savvy users.  But what I'm really after is a way to prevent the bogus documents from being created "proactively" as you mentioned above.
Sjef BosmanGroupware Consultant

Commented:
What I meant with "drwaing your own conclusion" is that first you say a flag won't work, and then you decide to use a flag. Thats all.

About the EXTMGR: you'd have to install it on EVERY PC that has Notes. Do you have savvy users who can delete a DLL? They can adapt their notes.ini, they have edit-rights on the file. Ergo: won't work.

Are you sure it is not possible to have a special signed agent sign a controlled-access section during a WebQuerySave, or right after?

Author

Commented:
>> "What I meant with..."
I knew what you meant, and I explained my comments - twice.  I knew it was a contradiction when I typed it the first time.  In fact, in the same post I wrote: "This is still not "true security" because it can be circumvented by a savvy user".

>> "Do you have savvy users who can delete a DLL?"
Sure, but I am also savvy.  The Database PostOpen code can check to ensure that the addin is running.  If it is not, I can prevent access to the db and install the addin automatically.  The user would not be able to open the database without restarting Notes.  I'm still not crazy about this solution because a savvy user could still use a 3rd party app for loading bogus documents.

>> "Are you sure it is not possible to have a special signed agent sign a controlled-access section"
No, I'm not sure.  I might take a look at that idea, but in reality, it may be more trouble than it is worth.  Actually, this is not much different that the flag and agent idea.  With the flag and agent method, you hide all documents that have an invalid flag field.  Maybe I'm wrong, but I don't think I can select documents in a view by the presence of a signature.  So, we've made it harder for someone to spoof the system, but also made it harder to design the application.  Plus, a savvy user can still post invalid documents using Import so the denial of service vulnerability is still there.

I'll look into signing the documents, but I will probably still opt for the simpler flag and agent method until a true solution comes along.

Thanks for your help guys!
Sjef BosmanGroupware Consultant

Commented:
I assume that a flag can be imported, but if a signature could be imported... would be BAD, I think... Basic question is: what cannot be imported using any of the import types, e.g. Structured text.

Good luck with your quest!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial