Uploaded image for project: 'Guacamole'
  1. Guacamole
  2. GUACAMOLE-289

Add support for declaring REST services within extensions

    Details

      Description

      Though Guacamole extensions can modify JavaScript, HTML, expose static resources, etc., they are not able to expose custom REST services. This limits the ability of extensions to provide functionality which depends on services unrelated to maintenance of users or connections, as well as functionality which may not currently be covered by the extension API.

      Extensions should be able to:

      1. Expose REST resources/services which do not require authentication
      2. Expose REST resources/services which do require authentication (require an associated auth token)

        Issue Links

          Activity

          Hide
          mike.jumper Michael Jumper added a comment -

          Moderate revision to the above:

          Class Authenticated? URL
          UserContext Yes (implicitly) .../api/session/ext/IDENTIFIER/
          AuthenticationProvider No .../api/ext/IDENTIFIER/

          Seems much more sane.

          Show
          mike.jumper Michael Jumper added a comment - Moderate revision to the above: Class Authenticated? URL UserContext Yes (implicitly) .../api/session/ext/IDENTIFIER/ AuthenticationProvider No .../api/ext/IDENTIFIER/ Seems much more sane.
          Hide
          mike.jumper Michael Jumper added a comment - - edited

          It might be nice to extend this further, such that all resources exposed through the REST API can have an optional subresource at ext, thus avoiding the need for extensions to reimplement the existing hierarchy.

          But it would be nicer to keep REST services exposed by extensions completely separate from the mainline REST API, rather than intruding on existing structure. With revisions to the URL patterns of extension REST services, this makes yet more sense.

          Show
          mike.jumper Michael Jumper added a comment - - edited It might be nice to extend this further, such that all resources exposed through the REST API can have an optional subresource at ext , thus avoiding the need for extensions to reimplement the existing hierarchy. But it would be nicer to keep REST services exposed by extensions completely separate from the mainline REST API, rather than intruding on existing structure. With revisions to the URL patterns of extension REST services, this makes yet more sense.
          Hide
          mike.jumper Michael Jumper added a comment -

          In the current WIP, I've added a getResource() function to UserContext (inherently requires authentication) and AuthenticationProvider (does not require authentication). If the extension does not return null for either of these, then corresponding REST resources are exposed.

          Class Authenticated? URL
          UserContext Yes (implicitly) .../api/session/data/IDENTIFIER/ext/
          AuthenticationProvider No .../api/ext/IDENTIFIER/

          where IDENTIFIER is the identifier of the AuthenticationProvider.

          Essentially, a new REST service has been added at .../api/ext/ which provides access to the unauthenticated REST resource exposed by each AuthenticationProvider, and the existing REST resource at .../api/session/data/IDENTIFIER/ has been modified to additionally expose the REST resource from the UserContext at ext.

          There is probably room for improvement here in the naming.

          Show
          mike.jumper Michael Jumper added a comment - In the current WIP, I've added a getResource() function to UserContext (inherently requires authentication) and AuthenticationProvider (does not require authentication). If the extension does not return null for either of these, then corresponding REST resources are exposed. Class Authenticated? URL UserContext Yes (implicitly) .../api/session/data/IDENTIFIER/ext/ AuthenticationProvider No .../api/ext/IDENTIFIER/ where IDENTIFIER is the identifier of the AuthenticationProvider . Essentially, a new REST service has been added at .../api/ext/ which provides access to the unauthenticated REST resource exposed by each AuthenticationProvider , and the existing REST resource at .../api/session/data/IDENTIFIER/ has been modified to additionally expose the REST resource from the UserContext at ext . There is probably room for improvement here in the naming.

            People

            • Assignee:
              mike.jumper Michael Jumper
              Reporter:
              mike.jumper Michael Jumper
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development