Requirements

There exists a site that requires authentication to use, and specific rights are assigned to the user when they login. The rights determine the fields that a user can see on each page. For example, an admin user might be able to see all fields, call them Fields A, B and C, but a basic user with no special rights can only see Field A.  How can search be setup in order to limit 'basic' users to search only basic content on a page (even though the same page contains 'admin' content for admin users)?

A proposed solution

Make the page URLs include something that distinguishes the permission level (eg. a GET parameter), and this would be fairly simple to solve.

Eg.

page1.aspx?level=basic
and
page1.aspx?level=admin

the indexer will see them as different pages, and indeed, for the first URL, only 'basic' user's text is shown and for the second URL, the admin stuff is shown. Therefore, at result time, just filter out the 'admin' pages for your 'basic' users (and so forth). Of course, a basic user would still be barred from seeing the second URL, it wouldn't just be based on the GET param, for security reasons (in case they kludged the URL to be 'admin' level).

Attached is a simple self contained project that is setup to do this.  It contains 3 pages; default, page2 and page3.  Each of them contains links, which have the href URL modified to include the user's level, in a 'level' GET parameter.

When the site is run, it starts at URL

http://localhost:2198/PermissionExample/default.aspx?level=basic

which means that the user is viewing 'basic' content.  Similarly, the start URL can be changed to

http://localhost:2198/PermissionExample/default.aspx?level=admin

to view admin content.  At this point it's worth restating that in a real world app. you would not allow 'admin' content to be view SOLELY on the basis of a GET parameter, instead you would also check the user's login as usual.  In this example, the 'level' GET parameter functions as a way for the search engine to differentiate between the page shown for an admin user and a basic user, based on it's URL.

The index in the project contains an import of the 2 URLs above.  So, in the first case, the website as seen by a 'basic' user is indexed, and in the second case, the website as seen by an 'admin' user is indexed.

Filtering

At this point the user can search and see results for both admin and basic users.  The next step is to restrict results to those appropriate to the level of the user doing the searching.  To do this a simple variation of this article http://keyoti.com/kb/Default.aspx?ToDo=view&questId=179 is used.

public class MySearchAgent : Keyoti.SearchEngine.Search.SearchAgent

string currentUserLevel;

public MySearchAgent(string key, Keyoti.SearchEngine.Configuration configuration, string currentUserLevel) : base(key, configuration) {

this.currentUserLevel = currentUserLevel;

}

public MySearchAgent(Keyoti.SearchEngine.Configuration configuration) : base(configuration) { }

///

if (result.UriString.IndexOf("level="+currentUserLevel) > -1) //result is for the user

The filter just filters out URLs which don't have the GET parameter expected for the current user.

To use the example project attached

Run the project and notice that the start URL is

http://localhost:2198/PermissionExample/default.aspx?level=basic

search for "basic" and notice that the results for the basic user, and likewise, there are no results for "admin".

Conversely, if the start URL is changed to http://localhost:2198/PermissionExample/default.aspx?level=admin then the results be appropriate for the 'admin' user (eg. search for "admin").

It may be a good idea to see how the pages hide/show content in panels based on the user.  Of course, the exact method of determining the user priviledge and how content is made visible is entirely open.  This example simply shows how it could work in it's most basic form.

Alternative to GET parameters

If modifying link URLs is not possible, then an alternative route to pursue would be URL rewriting.  Provided that the URL for a page contains something about the logged in user priviledge, then the above will work.