Installing and Registering Protocol Handlers (Windows Search)

Installing a protocol handler involves copying the DLL(s) to an appropriate location in the Program Files directory, and then registering the protocol handler through the registry. The installation application can also add a search root and scope rules to define a default crawl scope for the Shell data source.

This topic is organized as follows:

About URLs

Windows Search uses URLs to uniquely identify items in the hierarchy of your Shell data source. The URL that is the first node in the hierarchy is called the search root; Windows Search will begin indexing at the search root, requesting that the protocol handler enumerate child links for each URL.

The typical URL structure is:

The URL syntax is described in the following table.

Syntax	Description
Identifies which protocol handler to invoke for the URL.
	Identifies the user security context under which the protocol handler is called. If no user security identifier (SID) is identified, the protocol handler is called in the security context of the system service.
Defines the hierarchy of the store, where each forward slash (‘/’) is a separator between folder names.
Represents a unique string that identifies the child item (for example, the file name).

The Windows Search Indexer trims the final slash from URLs. As a result you cannot rely on the existence of a final slash to identify a directory versus an item. Your protocol handler must be able to handle this URL syntax. Ensure that the protocol name that you select to identify your Shell data source does not conflict with current ones. We recommend this naming convention: companyName.scheme .

For more information on creating a Shell data source, see Implementing the Basic Folder Object Interfaces.

Implementing Protocol Handler Interfaces

Creating a protocol handler requires the implementation of the following three interfaces:

• ISearchProtocol to manage UrlAccessor objects.
• IUrlAccessor to expose properties and identify appropriate filters for items in the Shell data source.
• IFilter to filter proprietary files or to enumerate and filter hierarchically stored files.

Other than the three mandatory interfaces listed, the other interfaces are optional, and you are at liberty to implement whichever optional interfaces are most appropriate for the task at hand.

ISearchProtocol and ISearchProtocol2

The SearchProtocol interfaces initialize and manage your protocol handler UrlAccessor objects. The ISearchProtocol2 interface is an optional extension of ISearchProtocol, and includes an extra method to specify more information about the user and the item.

IUrlAccessor, IUrlAccessor2, IUrlAccessor3, and IUrlAccessor4

The IUrlAccessor interfaces are described in the following table.

Interface	Description
IUrlAccessor	For a specified URL, the IUrlAccessor interface provides access to the properties of the item that is exposed in the URL. It can also bind those properties to a protocol handler-specific filter (that is, a filter other than the one associated with the file name).
IUrlAccessor2 (optional)	The IUrlAccessor2 interface extends IUrlAccessor with methods that get a code page for the item’s properties and its display URL, and that get the type of item in the URL (document or directory).
IUrlAccessor3 (optional)	The IUrlAccessor3 interface extends IUrlAccessor2 with a method that gets an array of user SIDs, enabling the search protocol host to impersonate these users to index the item.
IUrlAccessor4 (optional)	The IUrlAccessor4 interface extends the functionality of the IUrlAccessor3 interface with a method that identifies whether the content of the item should be indexed.

The UrlAccessor object is instantiated and initialized by a SearchProtocol object. The IUrlAccessor interfaces provide access to important pieces of information through the methods described in the following table.

Method	Description
IUrlAccessor::GetLastModified	Returns the time that the URL was last modified. If this time is more recent than the last time the indexer processed this URL, filter handlers (implementations of the IFilter interface) are called to extract the (possibly) changed data for that item. Modified times for directories are ignored.
IUrlAccessor::IsDirectory	Identifies whether the URL represents a folder containing a child URLs.
IUrlAccessor::BindToStream	Binds to an IStream interface that represents the data of a file in a custom data store.
IUrlAccessor::BindToFilter	Binds to a protocol handler-specific IFilter, which can expose properties for the item.
IUrlAccessor4::ShouldIndexItemContent	Identifies whether the content of the item should be indexed.

IProtocolHandlerSite

The IProtocolHandlerSite interface is used to instantiate a filter handler, which is hosted in an isolated process. The appropriate filter handler is obtained for a specified persistent class identifier (CLSID), document storage class, or file name extension. The benefit of asking the host process to bind to IFilter is that the host process can manage the process of locating an appropriate filter handler, and control the security involved in calling the handler.

Implementing Filter Handlers for Containers

If you are implementing a hierarchical protocol handler, then you must implement a filter handler for a container that enumerates child URLs. A filter handler is an implementation of the IFilter interface. The enumeration process is a loop through the IFilter::GetChunk and IFilter::GetValue methods of the IFilter interface; each child URL is exposed as the value of the property.

IFilter::GetChunk returns the properties of the container. To enumerate child URLs, IFilter::GetChunk returns either of the following:

The URL to the item without the last modified time. IFilter::GetValue returns a PROPVARIANT containing the child URL.

The URL and the last modified time. IFilter::GetValue returns a PROPVARIANT containing a vector of the child URL and the last modified time.

Returning PKEY_Search_UrlToIndexWithModificationTime is more efficient because the indexer can immediately determine whether the item needs to be indexed without calling the ISearchProtocol::CreateAccessor and IUrlAccessor::GetLastModified methods.

The following example code demonstrates how to return the PKEY_Search_UrlToIndexWithModificationTime property.

Copyright (c) Microsoft Corporation. All rights reserved.

A container IFilter component should always enumerate all child URLs even if the child URLs have not changed, because the indexer detects deletions through the enumeration process. If the date output in a PKEY_Search_UrlToIndexWithModificationTime indicates that the data has not changed, the indexer does not update the data for that URL.

Installing and Registering a Protocol Handler

Installing protocol handlers involves copying the DLL(s) to an appropriate location in the Program Files directory, and then registering the DLL(s). Protocol handlers should implement self-registration for installation. The installation application can also add a search root, and scope rules to define a default crawl scope for the Shell data source, which is discussed in Ensuring that Your Items are Indexed at the end of this topic.

Guidelines for Registering a Protocol Handler

You should follow these guidelines when registering a protocol handler:

• The installer must use either EXE or MSI installer.
• Release notes must be provided.
• An Add/Remove Programs entry must be created for each add-in installed.
• The installer must take over all registry settings for the particular file type or store that the current add-in understands.
• If a previous add-in is being overwritten, the installer should notify the user.
• If a newer add-in has overwritten the previous add-in, there should be the ability to restore the previous add-in’s functionality and make it the default add-in for that file type again.
• The installer should define a default crawl scope for the indexer by adding a search root, and scope rules using the Crawl Scope Manager (CSM).

Registering a Protocol Handler

You need to make fourteen entries in the registry to register the protocol handler component, where:

• Ver_Ind_ProgID is the version independent ProgID of the protocol handler implementation.
• Ver_Dep_ProgID is the version dependent ProgID of the protocol handler implementation.
• CLSID_1 is the CLSID of the protocol handler implementation.

To register a protocol handler:

Register the version independent ProgID with the following keys and values:

Register the version dependent ProgID with the following keys and values:

Register the protocol handler’s CLSID with the following keys and values:

Register the protocol handler with Windows Search. In the following example, is the name of the protocol itself, such as file, mapi, and so forth:

Prior to Windows Vista:

Registering the Protocol Handler’s File Type Handler

You need to make two entries in the registry to register the protocol handler’s file type handler (which is also known as a Shell extension).

Ensuring that Your Items are Indexed

After you have implemented your protocol handler, you must specify which Shell items your protocol handler is to index. You can use the Catalog Manager to initiate re-indexing (for more information, see Using the Catalog Manager). Or you can also use the Crawl Scope Manager (CSM) to set up default rules indicating the URLs that you want the indexer to crawl (for more information, see Using the Crawl Scope Manager and Managing Scope Rules). You can also add a search root (for more information, see Managing Search Roots). Another option available to you is to follow the procedure in the ReIndex sample in Windows Search SDK Samples.

The ISearchCrawlScopeManager interface provides methods that notify the search engine of containers to crawl and/or watch, and items under those containers to include or exclude when crawling or watching. In WindowsВ 7В and later, ISearchCrawlScopeManager2 extends ISearchCrawlScopeManager with the ISearchCrawlScopeManager2::GetVersion method that gets the version, which informs clients whether the state of the CSM has changed.

Как мне создать свой собственный протокол URL? (например, так: //…) [закрыто]

Хотите улучшить этот вопрос? Обновите вопрос так, чтобы он был по теме переполнения стека.

Закрыто 2 года назад .

Что это за первый раздел, где вы видите http и тому подобное?

Могу ли я зарегистрироваться самостоятельно?

Часть с HTTP:// , FTP:// и т. Д. Называется схемами URI

Вы можете зарегистрировать свой собственный через реестр.

Откройте блокнот и вставьте в него код ниже. Измените «YourApp» на имя вашего приложения. Сохраните его в YourApp.reg и выполните его, нажав на него в проводнике. Это оно! Ура! Эрвин Хаантес

Это отличается для каждого браузера, в IE и Windows вам нужно создать то, что они называют подключаемым обработчиком протокола.

Основные шаги заключаются в следующем:

1. Реализовать интерфейс IInternetProtocol.
2. Реализуйте интерфейс IInternetProtocolRoot.
3. Реализуйте интерфейс IClassFactory.
4. По желанию. Реализуйте интерфейс IInternetProtocolInfo. Поддержка протокола HTTP обеспечивается обработчиком транзакций.
5. Если реализовано IInternetProtocolInfo, обеспечьте поддержку PARSE_SECURITY_URL и PARSE_SECURITY_DOMAIN, чтобы менеджер зон безопасности URL-адресов мог правильно обрабатывать безопасность. Напишите код для вашего обработчика протокола.
6. Обеспечить поддержку BINDF_NO_UI и BINDF_SILENTOPERATION.
7. Добавьте подраздел для вашего обработчика протокола в реестре в HKEY_CLASSES_ROOT \ PROTOCOLS \ Handler.
8. Создайте строковое значение CLSID в подразделе и установите для строки значение CLSID вашего обработчика протокола.

Посмотрите Об Асинхронных Сменных Протоколах на MSDN для получения дополнительной информации на стороне Windows. Существует также образец в Windows SDK.

Быстрый Google также показал эту статью на codeproject: http://www.codeproject.com/KB/IP/DataProtocol.aspx .

Наконец, как сотрудник службы безопасности, я должен указать, что этот код должен быть усилен в бою. Это связано с высокой степенью риска, потому что для надежного выполнения этого вы не можете сделать это в управляемом коде и должны делать это в C ++ (я полагаю, вы могли бы использовать VB6). Вы должны подумать, действительно ли вам нужно это делать, и если вы это сделаете, тщательно продумайте его и надежно закодируйте. Злоумышленник может легко контролировать передаваемый вам контент, просто включив ссылку на страницу. Например, если у вас простое переполнение буфера, тогда никто не сделает этого: Click me for free porn

Launching applications using custom browser protocols

Contents

A very practical version of an Action Menu Item (AMI) is a variant that will run an application or a script on your local computer. For this to work you need to set up a connection between your browser and the script or application you wish to run. This link is called a custom browser protocol.

You may want to set up a type of link where if a user clicks on it, it will launch the [foo] application. Instead of having ‘http’ as the prefix, you need to designate a custom protocol, such as ‘foo’. Ideally you want a link that looks like:
foo://some/info/here .

The operating system has to be informed how to handle protocols. By default, all of the current operating systems know that ‘http’ should be handled by the default web browser, and ‘mailto’ should be handled by the default mail client. Sometimes when applications are installed, they register with the OS and tell it to launch the applications for a specific protocol.

As an example, if you install RV, the application registers rvlink:// with the OS and tells it that RV will handle all rvlink:// protocol requests to show an image or sequence in RV. So when a user clicks on a link that starts with rvlink:// , as you can do in Shotgun, the operating system will know to launch RV with the link and the application will parse the link and know how to handle it.

Registering a protocol

Registering a protocol on Windows

On Windows, registering protocol handlers involves modifying the Windows Registry. Here is a generic example of what you want the registry key to look like:

The target URL would look like:

Windows QT/QSetting example

If the application you are developing is written using the QT (or PyQT / PySide) framework, you can leverage the QSetting object to manage the creation of the registry keys for you.

This is what the code looks like to automatically have the application set up the registry keys:

Windows example that starts a Python script via a Shotgun AMI

A lot of AMIs that run locally may opt to start a simple Python script via the Python interpreter. This allows you to run simple scripts or even apps with GUIs (PyQT, PySide or your GUI framework of choice). Let’s look at a practical example that should get you started in this direction.

Step 1: Set up the custom “shotgun” protocol

Using Windows Registry Editor:

This setup will register the shotgun:// protocol to launch the python interpreter with the first argument being the script sgTriggerScript.py and the second argument being %1 . It is important to understand that %1 will be replaced by the URL that was clicked in the browser or the URL of the AMI that was invoked. This will become the first argument to your Python script.

Note: You may need to have full paths to your Python interpreter and your Python script. Please adjust accordingly.

Step 2: Parse the incoming URL in your Python script

In your script you will take the first argument that was provided, the URL, and parse it down to its components in order to understand the context in which the AMI was invoked. We’ve provided some simple scaffolding that shows how to do this in the following code.

Python script

Step 3: Connect the Shotgun interface with your custom protocol and ultimately, your script

Finally, create an AMI in Shotgun whose URL value will be shotgun://processVersion . You can assign this AMI to any entity type you wish, but this example uses the Version entity.

Go to a Version page, right-click on a version and select your AMI from the menu. This should make your browser open a shotgun:// URL which will be redirected to your script via the registered custom protocol.

In the output.txt file in the same directory as your script you should now see something like this:

Possible variants

By varying the keyword after the // part of the URL in your AMI, you can change the contents of the action variable in your script, all the while keeping the same shotgun:// protocol and registering only a single custom protocol. Then, based on the content of the action variable and the contents of the parameters, your script can understand what the intended behavior should be.

Using this methodology you could open applications, upload content via services like FTP, archive data, send email, or generate PDF reports.

Registering a protocol on OSX

To register a protocol on OSX you need to create a .app bundle that is configured to run your application or script.

Start by writing the following script in the AppleScript Script Editor:

Pro tip: To ensure you are running Python from a specific shell, such as tcsh, you can change the do shell script for something like the following:

In the Script Editor, save your short script as an “Application Bundle”.

Find the saved Application Bundle, and Open Contents. Then, open the info.plist file and add the following to the plist dict:

You may want to change the following three strings:

The third string is the protocol handler; therefore a URL would be:
shotgun://something

Finally, move your .app bundle to the Applications folder of your Mac. Then double click on it—that will register your protocol with the operating system.

The data flow looks like this: once you click the AMI in Shotgun, or click a URL that starts with shotgun:// , the .app bundle will respond to it and pass the URL over to your Python script. At this point the same script that was used in the Windows example can be used and all the same possibilities apply.

Registering a protocol on Linux

Use the following code:

Then use the settings from your local GConf file in the global defaults in:
/etc/gconf/gconf.xml.defaults/%gconf-tree.xml

Even though the change is only in the GNOME settings, it also works for KDE. Firefox and GNU IceCat defer to gnome-open regardless of what window manager you are running when it encounters a prefix it doesn’t understand (such as foo:// ). So, other browsers, like Konqueror in KDE, won’t work under this scenario.