[MTOS-dev] Supporting public/private search (was Implementingnew MT::App::Search)

[Fumiaki Yoshimatsu]

So, what do you (and others) think of this idea, inherited and extended
slightly from Jay?

To execute search, user is required to post two parameters: IncludeBlogs
and SearchKey.  Template has this:

  <input type="hidden" name="IncludeBlogs" value="1,2,3" />
  <input type="hidden" name="SearchKey" value="<MTSearchKey
include_blogs="1,2,3">" />

Or <a href="....IncludeBlogs=1,2,3&SearchKey=<MTSearchKey
include_blogs="1,2,3">">search</a>.

IncludeBlogs has blog ids that are allowed to include (after processing
config and exclude_blogs).
SearchKey has the SHA1(MT->config->SecretToken + sort(IncludeBlogs)).

Upon search request, the SearchKey is generated again from IncludeBlogs
query parameter and compared with the parameter value.  If they don't
match, search fails.  This way, no configuration is required and MT does
not have to store SearchKey.

If no SearchKey is specified, it falls back to processing configuration
directives to decide what blogs as before (thus requires sysadmin
configures ExcludeBlogs correctly).  "Everything public" blog would not
care about SearchKey parameter and that's OK.

To allow a protected blog be searched from inside a security realm, the
search template for the blog has those parameters.  You should also
specify ExcludeBlogs theBlogId, for the fallback case, but specifying
correct SearchKey would bypass the ExcludeBlogs setting.

Fumiaki

> -----Original Message-----
> From: mtos-dev-bounces at sixapart.com
> [mailto:mtos-dev-bounces at sixapart.com] On Behalf Of Mark Carey
> Sent: Sunday, March 02, 2008 9:37 AM
> To: MTOS dev
> Subject: Re: [MTOS-dev] Supporting public/private search (was
> Implementingnew MT::App::Search)
> 
> On Sat, Mar 1, 2008 at 8:17 PM, Jay Allen <jay at endevver.com> wrote:
> >  whereas, correct me if I'm wrong, you're suggesting enclosing the
> >  entire form (and search results?) in a multiblog enabled tag:
> >
> >    <MTSearchContext include_blogs="1,2,3">
> 
> No, I am not quite suggesting this either.
> 
> I guess I am coming at this from the same angle as my Fast Search
> plugin (right or wrong).  While it is a php plugin and has obvious
> back-end differences, conceptually it works like this:
> 
> -check the URL parameters
> -check the args for MTSearchResults
> -rationalize between the two, and when conflicts exist, the args win
> (prevents URL hacking)
> -submit query and fetch results + counts
> -template tags that rely of the results of said query *must* be used
> only inside MTSearchResults (perhaps in the search header or footer).
> -MTSearchString is a separate tag that is taken from the query
> parameter, and can thus be used outside the results container (such as
> in the <title> tag, etc.)
> 
> >  it sounds like we're in some agreement too.
> 
> Agreed.
> 
> >  So, if we require a
> >  template parameter that would prevent abuse but even then, that
means
> >  that the search template has to be loaded *first* and then parsed
for
> >  the context.
> 
> Correct.  The blog context of the results (meaning the blog
> *displaying* the results) might be set first, based the blog_id
> parameter, but the rest, especially the search results, would not.
> Performance-wise, is one approach better than the other (assuming the
> same queries are being run)?  I guess this is the key difference
> between the two approaches -- with search keys you have ability to run
> the search query before loading the template, and with tag args you
> have to wait until after loading the template...
> 
> -Mark
> _______________________________________________
> MTOS-dev mailing list
> MTOS-dev at sixapart.com
> http://www.sixapart.com/mailman/listinfo/mtos-dev