Skip to main content.
home | support | download

Back to List Archive

Re:

From: William M Conlon <bill(at)not-real.tothept.com>
Date: Thu Jul 27 2006 - 20:55:37 GMT
I've been contemplating this for a while.  I have an ordinal access  
control structure, where a user can see all content with an  
access_level <= the user's access_level.

I would then return only the documents to which I user has access

	swish-e -w $query -L access_level <= $user_access_level

I use the spider method, with swish-e logging in and then following  
all links it receives.  At first I expected to provide a login method  
to allow users (specifically swish-e) to set the access level at  
which they want to login (checked off course to make sure it's <=  
their allowed level).  Then I would set up my @servers as a loop on  
the same url, but with successively increasing access levels, up to  
the limit I give the swish-e user.  With each hit, we will tell the  
indexer to store swish-e current access level as a property.

The gotcha I'm worried about is will spider.pl somehow fetch the  
'same' page at multiple access levels?  I'm thinking it might, if the  
spider clears it list of visited URLs as it begins each element in  
@servers.  And I can't depend on the MD5 hash, because additional  
menu items appear as a user's access level changes, so the home page,  
for example, will have a different menu for $access_level == 1, than  
for $access_level=2.

Another approach would be for the app server to return the access  
level as a cookie (some of the content is in files (pdf, doc, etc) so  
we can't use metatags within the content), and then swish-e could log  
in at the highest level I want searched, and just spider all the  
content that's available to it.    I've been thinking about having  
the server send the $access_level  as a cookie in the http header.   
Then the spider can store the cookie in the access_level property.

bill
On Jul 27, 2006, at 11:19 AM, Bill Moseley wrote:

> On Thu, Jul 27, 2006 at 11:09:04AM -0700, Chad Day wrote:
>> Scenario:
>>
>> =20
>>
>> I have a postgres DB that is storing files in it.  Users have various
>> access levels which control access to these documents, so if a user
>> searches, swish-e should not return any results that user normally
>> doesn't have access to.
>
> How about adding a metaname for the access level of the document, and
> when searching always specify the access level in the query?
>
> If user has access levels "A" and "B" then:
>
>     -w access=(A or B) and $query
>
>
>> I think the end result is the same, I'm just trying to find the  
>> best way
>> to go about this and not sure if there's an easier way, or some  
>> feature
>> of swish-e I might be overlooking.  I think the multiple swish-e  
>> indexes
>> being built for each user access level is needed and I just control
>> which index they search through the front end, but maybe swish-e can
>> handle that by some method I'm unaware.
>
> I don't think I'd use multiple indexes unless the data was huge and
> there was real separation of access levels (like users only ever have
> one access level).
>
> -- 
> Bill Moseley
> moseley@hank.org
>
> Unsubscribe from or help with the swish-e list:
>    http://swish-e.org/Discussion/
>
> Help with Swish-e:
>    http://swish-e.org/current/docs
>    swish-e@sunsite.berkeley.edu
>

Bill

William M. Conlon, P.E., Ph.D.
To the Point
345 California Avenue Suite 2
Palo Alto, CA 94306
    vox:  650.327.2175 (direct)
    fax:  650.329.8335
mobile:  650.906.9929
e-mail:  mailto:bill@tothept.com
    web:  http://www.tothept.com
Received on Thu Jul 27 13:55:47 2006