Is it possible to make a custom REST endpoint open to anonymous users?

Question

I'm exploring Telligent for evaluation purposes to see if it's a good option to migrate a large, heavily customized community on another platform to. One of my requirements is that I am able to implement several custom RSS feeds. The hitch is that they should not require authentication to view. Is this possible? Below is my sample code. It works if I use jQuery.telligent.evolution.get(...) but not if I just try to open the URL in a new browser tab (I get a 403).

  public class SampleRestEndpoint : IPlugin, IRestEndpoints
  {
    private readonly Action<IRestRequest, HttpResponse> _testEndpointFn = (request, response) =>
    {
      var input = request.Request.QueryString["input"] ?? "default-input";
      var output = new string(input.Reverse().ToArray());
      output = $"<root>{output}</root>";
      response.ContentType = "text/xml";
      response.Write(output);
      response.Flush();
    };

    public void Initialize()
    {
    }

    public string Name { get; } = "Sample Rest Endpoint";

    public string Description { get; } = "Sample Rest Endpoint Description";

    public void Register(IRestEndpointController restRoutes)
    {
      restRoutes.Add(1, "myendpoint/test", null, null, HttpMethod.Get, this._testEndpointFn);
    }
  }

Michael Monteleone · Accepted Answer

Hi sonofagum . Yes, what you're doing is definitely possible, though in a slightly different way. In short, instead of creating a custom REST endpoint plugin, I recommend creating a custom INavigable plugin , which exposes a lower-level way of registering HTTP handlers against URL routes. Here's your sample converted to an INavigable. It can be requested directly through the browser at /sample/navigable/endpoint. I'd also recommend reviewing the page definition and URL routing documentation . using System.Linq; using Telligent.Evolution.Extensibility.Urls.Version1; namespace Samples { public class SampleNavigableEndpoint : INavigable { public string Name => "Sample Navigable Endpoint"; public string Description => "Sample Navigable Endpoint Description"; public void Initialize() { } public void RegisterUrls(IUrlController controller) { controller.AddRaw("sample-endpoint", "sample/navigable/endpoint", null, null, (httpContext, pageContext) => { var input = httpContext.Request.QueryString["input"] ?? "default-input"; var output = new string(input.Reverse().ToArray()); output = $"{output}"; httpContext.Response.ContentType = "text/xml"; httpContext.Response.Write(output); httpContext.Response.Flush(); }, new RawDefinitionOptions { }); } } } For REST, you can indeed create custom endpoint plugins. But while REST requests don't inherently require the accessing user to not be the anonymous account, they do still require the request to be authenticated, even if it's authenticated as the anonymous user. A REST request requires authentication via OAuth, API keys, or through platform-rendered UI (jQuery.telligent.evolution.get|post|put|del). You can see anonymous REST requests in action by visiting this site without being logged in, as much of the UI is powered by the same REST API. And you can also see that those same successful requests still can't be issued just by opening a browser window to their URL. Also, REST extensibility is intended for cases where you have services and model entities you wish to expose over HTTP through both XML and JSON serialization. For a custom RSS feed where you're trying to craft a specific, serialized response, INavigable gives you more control. For what it's worth, the platform also has built-in support for RSS already, if that's something you are interested in. And the platform's own RSS endpoints are also based on INavigable. By the way, while plugins might be the best choice for you, there are alternatives, such as Automations . Automations let you define custom server-side functionality completely in script (either JavaScript or Velocity) directly inside Automation Studio in administration without deploying .NET assemblies. Automations aren't just for handling platform event triggers. They can be configured to simply respond to HTTP requests, with or without authentication . A disadvantage would be that you wouldn't be able to define its specific URL. But they're still a quick way to experiment with functionality outside of a compiled plugin. The extensibility possibilities in Community are quite robust, and most of the platform is built directly on them. I'd be happy to answer any more questions you have.

Is it possible to make a custom REST endpoint open to anonymous users?

Top Replies