Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Extending DotNetNuke Search with item-by-item permissionsExtending DotNetNuke Search with item-by-item permissions
Previous
 
Next
New Post
5/17/2008 11:17 PM
 
This post discusses the possibility of extending the DotNetNuke search provider to support security at the SearchItem level. 
Out of the box DotNetNuke provides security at a Tab (page) and Module level. The default Search provider uses this security to filter results to only show items from Modules the current user is allowed to view.  Unfortunately this is “all or nothing” for the contents of a module - there is no way for a module to indicate that some of its search results should only be visible to certain users.

There are many examples of where this could be useful. Consider a module that shows different News items depending on the roles of the current user or perhaps a Forum module where some forums are restricted to certain users. If those modules implement the ISearchable interface then all search results will be visible to any user with view access to the module. Even though the module should prevent access to the full detail of the search item, the summary that is shown in the search results list may be confidential in itself. Also it is not really “good form” to show search results that the user can’t access the details for.

OK, so let's extent DotNetNuke's search provider.

How would this affect module developers? It wouldn’t - unless they want to take advantage of the new features. If the module doesn’t need to secure part of its content it just carries on implementing ISearchable as it does now - no change. The module’s GetSearchItems returns a SearchItemInfoCollection filled with SearchItemInfo objects just as it does now. The DotNetNuke search provider continues to check Tab and Module permissions to confirm the user has the right to view the search results.
So what changes? A new class called SearchItemInfoWithPermissions is derived from SearchItemInfo. If the module wants to implement search item-by-item security it’s GetSearchItems fills the SearchItemInfoCollection with objects of this new class instead. The extended search provider will then persist the extra permission information along with the search item and use it when processing results.
On a different but related topic, this security could also be used to control items shown in RSS feeds and would be particularly useful when combined with basic authentication (connected to DotNetNuke’s forms authentication) for the RSS results page so that news readers could get results for secured content. (see the article about MADAM at http://msdn.microsoft.com/en-us/library/aa479391.aspx for more info about this). Anyway back to searching...
There is an enhancement request on Gemini along these lines. Feel free to vote for it if you think it would be useful J. (http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=2727&PROJID=2)
I’m going to work on fleshing out some code for this and will probably keep having a conversation with myself here in this forum. Please let me know if work has already been done on this topic or if I’ve missed a really obvious issue.
 
New Post
5/18/2008 11:38 AM
 

While you are working this out, you might want to consider ISearchable which might include

FilterPermissions (Builtin Security)
SortByRelevence (Did this ever work properly?)
SortBySponsor (Google via DotNetNuke including revenue generation)

Or extend the functionality of filtering in PreProcess and sorting in PostProcess for the SearchItemInfoCollection.

It's a tough call to get SQL to do the work or process the collection from SQL results.

I agree It would be nice to extend the search functionality as required, either by implementing a new interface or class.


Dwayne J. Baldwin
 
New Post
5/18/2008 5:52 PM
 

Hi Dwayne. 

I was thinking it would be good to start with "extending" the ISearchable interface so that modules can advise the search engine about item-by-item permissions.  Obviously the built-in search engine will then need modifying to take those permissions into account.

After that can be achieved (in the core) I'd like to work on an SQL specific search engine, as you suggest, to get "SQL Server to do the work".  This would probably never become part of DotNetNuke as it would be dependant on using SQL Server for the database and probably on using built-in DotNetnet Security only BUT it would  be faster and allow for better phrase searching and pattern matching, etc. 

The thoughts I'd had on this so far would involve each module providing an SQL view of their search items with predefined columns (eg URL, Title, Summary, SearchText, Permissions).  The Search engine would simply query these views to get the search results in real time using LIKE clauses  (ie no pre-indexing or storage would be required).  It should be easy to create these views for the standard modules.  Other modules could create their own view and register it with the seach engine (perhaps via an ISQLSearchable interface ).  This search engine may even continue to offer "traditional" DotNetNuke indexing for modules that don't store their data in SQL Server - and then append these results to the SQL results.

All thoughts are appreciated.  Regards, Brendan.

 

 
New Post
5/30/2008 3:14 PM
 

In our DNN solution I've created a search solution based on SQL Server's Full Text Indexing.  I created Full Text indexes on all the tables/columns that need searching and then a class for each module that runs the full text query agianst those tables.  I even search the content of files as long as they are stored in a "Database" folder as this is a feature of Full Text Indexing.

I know this is a SQL Server only solution but most database engines provide some sort of indexing capability so it should be possible to make a generic solution.  ISearchable could require a "IndexSearch" method that returns a list of "hits".  The module's data provider could then run the DB specific SQL for returning the results and build a collection of "HitInfo" objects containing results information (URL, DisplayText, etc).  If needed,  the module could impliment SearchItem level security.  The core search engine would agragate the HitInfo collections and display the results.  No DNN indexing or storage would be required and the results would always be up to date.

This appraoch leaves the "heavy lifting" to the database engine which they excel at, keeps the core search code very small and gives the modules ultimate control over what results are returned for each search.

This is pretty much what I do but I don't use the DNN provided search at all as I didn't want to modify core code.  My search module is independant of the module but my list of modules that is searched is "hard coded". 

 
Previous
 
Next
HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Extending DotNetNuke Search with item-by-item permissionsExtending DotNetNuke Search with item-by-item permissions


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out