"sniffing document IDs"

It wouuld be very difficult to do.  In R4 and R5, it would probably be easier to sniff out via DocIDs, which are much smaller and less random.

There is no mailcious software to do that.. Your ACL does filter out most of those kind of activity from external ..

What is that exactly that you are afraid of ?

~Hemanth

Of course, you would need access to the view, and the database, and you must be authorized to read the document in the first place.

But this does work just fine for views you could expect to be present in a database ( ($All), All Documents, LU, LUVIEW, lookup, .... )), or with the defaultview url

http://server/database.nsf/$defaultview?Readviewentries

cheers,

Tom

I just detected this and it seems curious... tell me if it's correct... if you know the document unique id (of a document with no readers field on it), even if the document has been created with the form security set to prevent web reading, and the view security is set to prevent web use, you can still access the document.

Additionally, you don't even have to know a valid view name... random characters in place of the view name will work.

Anything you can tell me about this would be appreciated.

As well, if I did want to put a readers field on a form... would I just set a default value of the appropriate ACL groups or individuals?... and this would prevent it from being read even if one knows the unique document id?

-Ke

If you know the documentunique id, you can open the document if
- you can read the document (access through ACL, and readers fields)
- there is a form to display the document (you could have forms for notes use only, or a special form for web use)

cheers,

Tom

In the acl, set default to no access and set anonymous to no access. This will force only the users who are authorized to access the data...Thus by keeping out the "malicious" users..

Hemantha, if you want to create a Notes based website, that 's not really a solution, is it ?

So if you do allow anonymous access to your database, you have to be careful when designing the application.  Don't rely on 'security thru obscurity' to secure your application ....

cheers,

Tom

basically that is what he wants.. prevent other users to mess around..

Another way is to hide the location by using frames

That's 'security tru obscurity' .  No would-be hacker or nosy sniffer will be stopped by that :-)

If your users all use the same root hierarchical certifier, and all Notes client users SHOULD be able to read all documents, then set up a readers field with */RootCertName (you wil also want to set up a separate readers field with a true name, because I don't remember whether */Cert works with both ACL and readres, or just ACL, and if I am wrong, you will have a phantom doc in your DB).

A variation of the above:  If your web users will all be anonymous, then create a role called NonAnon, and assign the role to all ACL entries EXCEPT Anonymous (make sure you do have an entry named Anonymous).  Then, set a readers field with [NonAnon] computed for it.

Now, if your web users are not always anonymous, then you just need a well designed readers-restructed app to start with.

I just fail to see what the problem is. If you open a database for webusers, then those documents are meant to be visible, aren't they? If users aren't supposed to watch them, then hide them, protect them, or move them to a separate database. Users modifiying documents can easily be prevented.

But don't you have exactly the same (or worse) with any HTML-based website? Sniffing documents there isn't that difficult. Checking ww.website.ext/default.htm or /index.htm or just generate names and you'll strike oil some day. And so what? The document is visible, yes, but who has a public website with only invisible pages? Luckiloy, with Notes, you can pull up a nice fence where you want it.

The problem could be that some documents, although the content is public, are not meant to show.
Examples are documents where you store attachments (images,...) or configuration documents.

Of course, the biggest problem would be a less-than-perfect design to begin with....

cheers,

Tom