Editing proxy settings for an approved widget

Edit an approved widget by opening the widget catalog, selecting the widget, and using the edit functions.

About this task

If changes are required to the proxy settings, open the widget document, then select Edit Proxy Data to review and update the proxy settings. These procedures work regardless of whether the proxy settings are listed on the Gadget Proxy or Content Proxy tab.

Procedure

  1. From the Domino® Administrator client, click Files, select the widget catalog and click to open the widget catalog.
  2. Select the widget you are editing, and open the widget document.
  3. Click Edit Proxy Data.

    The Configure Proxy dialog box displays the OpenSocial widget with which proxy settings are associated. The page displays a list of the defined proxies for the widget.

  4. From the list of proxies, select the proxy whose settings you are editing. Click Edit.
  5. Edit these settings as necessary.
    Table 1. Configure Proxy dialog box settings
    Field Description
    URL (required field) The URL pattern for the proxy. The URL can include an asterisk ( * ) as a wildcard character, but only in its last path component. For example, the URL may contain http://www.example.com/images/*. However, http://www.example.com/*/images is not valid.

    For example, this URL http://www.example.com/foobar/test/* is valid and matches http://www.example.com/foobar/test/test.jsp, or http://www.example.com/foobar/test/someOtherstuff. A proxy URL such as http://www.example.com/foobar/test* is not the same, and is not likely to match any target URLs.

    At runtime, the URL contained in the request made by the gadget is compared against each of the different proxy URLs for the gadget. When a match is found, the Actions, Headers, Cookies, and MIME type restrictions are applied to the request.

    Actions (required field) Select one or more of these actions: GET, POST, PUT, DELETE, HEAD. Any action entered here is permitted for any request matching the URL. By default, no actions are permitted.
    Headers Defines the headers that can to be added to a request made from the gadget server. Headers are values sent by a request to a server indicating how the request should be treated and how the response should be returned. The HTTP specification defines a number of headers as a standard. The token value [default] can now be used instead of specifying the individual headers.

    Applications can add additional headers to the request. A gadget's request can include additional headers to be set. However, if those additional headers are not permitted by the proxy setting, then the headers are not allowed. If a request depends on additional headers, those headers must be defined.

    Use commas to separate individual entries in a list of headers. Follow the Internet specification for header names. Header names may contain a wildcard character (*) to match parts of names. For example, if the header name is MyH*, then both MyHeader and MyHome are permitted.

    If nothing is specified, the default set of headers containing Cache-Control, Pragma, User-Agent, Accept*, Content* is used. If an additional header is required, the header list must contain the desired default headers, as well as the required additional header. For example, to add client_secret to the list of headers, the field would contain Cache-Control, Pragma, User-Agent, Accept*, Content*,client_secret. The token value [default] can be used here to represent the default headers, so adding client_secret can also be done by specifying [default], client_secret. If the wildcard * is specified, all headers are permitted.

    To prevent any headers from being sent, add a single header name to the field, and do not include any default headers. For example, specify No_Headers to prevent all headers from being sent. Note The Set-Cookie header is handled separately using the Cookies field, and should not be specified in the Headers field.
    Cookies Cookies are informational elements that transfer data between client and server. Gadget requests may contain cookie values that they desire to set. The Cookies field defines the set of cookies allowed to be passed through the server.

    Use commas to separate multiple cookie names.

    Specify the full cookie name.

    No wildcard characters are permitted.
    MIME Types Set limitations on the request/response style specified with this field. Use commas to separate multiple values.

    The wildcard character (*) is permitted in the MIME types.

    An empty value, or a value of * permits all MIME types to be used.
  6. (Optional) Under IP filter, specify values in the Allow list and Deny list fields as needed. Represent filter values as IPv4 addresses:
    • Fully qualified domain name, no wildcards.
    • IP address and subnet mask, 9.6.1.0/255.255.0.0, no wildcards are permitted. Both sides of the subnet must be valid ip(v4) addresses.
    • IP address with wildcards for specific address components only, for example, 9.6.*.*, but * by itself is not permitted.
  7. Click Save. Click OK.