How can I prevent visiters to use the ?SearchView url command and search for documents in the database?
I would like to disable all kind of search options from webbrowsers…
Subject: How to prevent ?SearchView url to search a database.
try creating an empty form named $$SearchTemplateDefault. You might want to add some text at the top (“Searching is not allowed in this context”).
Subject: RE: How to prevent ?SearchView url to search a database.
A much better idea in EVERY way is to properly secure documents users should not have access to and ENCOURAGE searching in the rest of the application. I can’t believe anyone would actually want to prevent users finding what they’re looking for. Securing data is a good thing, but what possible good can come of disabling a search of data that users can access anyway?
Subject: $$SearchTemplateDefault will do…
Ok thanks, this confirms there is no database setting or something to prevent it.
An empty $$SearchTemplateDefault does what I want: it shows nothing.
Subject: RE: How to prevent ?SearchView url to search a database.
Stan… you might be making too many assumptions about Marcel’s application. He may be primarily concerned w/ users access to views that haven’t been properly formatted for the web (maybe a notes client app on a server running HTTP not meant for web). Another possibility is that he may not want to rely on document level security (ie reader fields) as they are a real performance hit for both web and notes applications (much view re-indexing).
cheers,
Mark
Subject: RE: How to prevent ?SearchView url to search a database.
I think not.
$$SearchTemplates and $$ViewTemplates for the views in question (accessible to the web but not amenable to web use) will stop embarrassments if formatting is an issue. But then, the user would have to know about the view (NoteID URLs don’t work in D6+, and users can’t see server-side lookup code), so, again we are back to the developer granting access to stuff the user shouldn’t see.
Readers fields are NOT a particular performance hit, especially when compared to “security” coded with LS and Formulas. You can combine them with RestrictToCategory to minimise the already minimal hit. A search will not reveal anything the user cannot already see.
Home-rolled “security” is NOT security. If the view and the documents in it are accessible (and you can’t search if they’re not), then preventing searching is merely a developer’s way of saying “you’ll get there when I’m ready to let you”. That is a long way from good design.
Subject: RE: How to prevent ?SearchView url to search a database.
Again assumptions and broad generalizations are being made about whether or not security is even an issue in this particular case. I am certainly NOT advocating building home grown security within a notes/domino application. My goal is to give you some possible scenarios for Marcel’s requirement. Neither one of us actually knows what his original requirements are/were, but I’m sure that your solution is better in EVERY way.
Other possible reasons for limiting $$Search/$$ViewTemplate:
Restrict web access to a subset of the views that have full application functionality behind them. Maybe there are certain visible “notes only” views that contain actions that won’t work on the web. hmmm… I wonder if the user will expect that button to work the same way it does in notes?
BTW…quote and link below from the domino performance redbook on reader field usage(note the word severely)
"Be Careful When Restricting Access via Reader Names
Restricting readership of individual documents via reader names fields also
has an impact on view performance (restricting access to the entire view has
no impact).
Depending on how many documents are visible to the user, reader names
can severely affect the response times for a view to be displayed. For shared
views there is a single index for the view. Since this index is shared by all
users, an additional filter is used to display to the user only documents for
which their name appears in the reader name field.
Remember, the server will serve to the client only enough data to fill the one
and a bit screens. If the server must process many thousands of documents
via the filter before enough data to fill one screen is found, then response
will be slow."
128 Performance Considerations for Domino Applications