Re:
William M Conlon <[email protected]>
| Newsgroups | gmane.comp.web.swish-e |
|---|---|
| Message-ID | <[email protected]> |
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 > [email protected] > > Unsubscribe from or help with the swish-e list: > http://swish-e.org/Discussion/ > > Help with Swish-e: > http://swish-e.org/current/docs > [email protected] > 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:[email protected] web: http://www.tothept.com