1. 2

Warpist solves the typical cross-origin issues (CORS) when requesting APIs you don’t control, without deploying a server component.

It is an alternative to deploying nginx, a quick and dirty nodejs proxy or whatever. The main differentiator is that Warpist is managed, so you don’t need to provision, configure, deploy and maintain a server. It also solves some common API proxying needs (namely HTTPS/SSL, API token management …)

As I’m reaching the MVP stage soon product-wise, I thought I could try to generate some traction already and validate the idea further.

Is this something you have a need for? Make sure to sign up if it’s something you could make use of. Constructive feedback is also very welcome.

https://warpist.com

  1.  

  2. 2

    I’m so completely and utterly terrified by the ways by which this is about to be abused, especially if you’re promoting it as “solving” HTTPS/SSL - which is going to incline people to hide HTTP behind it.

    Hopefully it requires SSL-terminated endpoints? Any endpoint this connects to should absolutely be an encrypted connection, or you’re leaking peoples’ data. Bad for the world of security as a whole if not, and possibly still if so.

    Also, if this is managed then what is the reason to choose it over - for example - cloudflare?

    EDIT: Okay, the front page literally shows it masking an HTTP endpoint as HTTPS. This is anti-security.

    1. 1

      which is going to incline people to hide HTTP behind it.

      That makes sense. The actually message I tried to convey is that Warpist’s proxy does not lower your existing security. In other terms, the SSL certificate is another thing you’d have to manage yourself if you deploy your own reverse proxy.

      But I see how that could be understood as “All your SSL problems are solved”, which would indeed be a dangerous thing to do.

      Thanks for the heads up!

      what is the reason to choose it over - for example - cloudflare?

      Which specific Cloudflare product do you have in mind? To make the product a bit clearer, Warpist works by adding CORS headers to the API, and managing API authentication server-side (tokens and secrets).

    2. 2

      The claim “without a server” left me baffled, I must say. I was intrigued on how that’s going to work and found, that it meant “managed proxy/ SaaS”. For me, I would rather consider a service if I felt it was honest about the claims.

      I agree to the SSL problem: I suppose having letsencrypt on the API is the best way to deal with this, but if you manage to provide an even easier solution (like having an easy module I can plug into my app that then allows some sort of zero-config and secure communication with your proxy and my API), maybe that would help some devs who would otherwise run the service unsecured.

      1. 1

        Sorry to disappoint! :D You’re correct, server here refers to the developer having to deploy and manage something on the server side, or rather the absence of.

        But at no point did I try to be dishonest. I don’t see actually see a benefit for Warpist to make this “revolutionary” claim, as it’s not trying to compete on neatness / bleeding edgeness of the proxying tech as much as simplifying the experience of deploying and managing it.

        Re: SSL, your suggestion is actually very close to a note I have in the roadmap, however I de-prioed this approach as I thought it could be more valuable to solve the problem for people who don’t control the API, and most likely don’t want to run a server just to reverse proxy it. The assumption (to be validated) being that if you have your own API, the benefit you would get from a managed reverse proxy will be relatively small, as you could deploy say nginx (from scratch or with a template), or some docker container that will handle reverse proxying for you, for a relatively minimal cost.

        In your opinion, why would you choose Warpist over nginx or other proven solutions, when you have control over the server of the API to proxy?

        1. 1

          No worries, I’m not trying to say you’re dishonest, just that finding out what’s behind the claim baffled me in a negative way. But we’re living in a time where “serverless” doesn’t mean “no-one actually runs a server”, so yeah.

          Ah, I see your point - and therefore the CORS claim that you made prominent. I think it might solve an issue, although I feel that it more feels like a workaround for setting up CORS correctly. Shouldn’t services that actually are supposed to be used from other sides where CORS would be an issue have the rules set up?

          As nginx and reverse proxying is actually part of my everyday work, I personally would just install nginx for sure - it’s minimal efford and I get full control and eliminate an additional party that would have access to the traffic. Developers that focus more on the backend/ frontend side of things instead of the underlying infrastructure might thing differently, though.

          1. 1

            No worries, I’m not trying to say you’re dishonest, just that finding out what’s behind the claim baffled me in a negative way. But we’re living in a time where “serverless” doesn’t mean “no-one actually runs a server”, so yeah.

            All good, but that’s indeed a legit source of confusion, and I’m trying to think of a good way to rephrase it.

            I feel that it more feels like a workaround for setting up CORS correctly

            That is partially true. The current incarnation of Warpist would be a transitional solution until all APIs have adopted CORS or a new standard appears. However, beyond the implementation itself, it seems not everyone wants to implement CORS.

            Many API providers have a legitimate concern that enabling CORS would make it harder to manage security, for example API secrets could be stolen from client-side only apps, and to my knowledge Google’s the only large provider who implements a proper way to deal with this (origin validation + only a client ID, so no secret to leak).

            To address this, Warpist gives you a way to setup an allowed origin whitelist, as well as a way to manage API secrets, so that they’re never exposed to the browser. So it’s a little bit more convenient for this use case than a vanilla reverse proxy setup (nginx based for example).

            it’s minimal efford and I get full control and eliminate an additional party that would have access to the traffic.

            Exactly my reasoning for targeting APIs the developer does not control. Those would be public APIs mainly where the effort to deploy a CORS proxy might mess with the original project plan, but secondarily it could also be software you deployed yourself, yet it doesn’t have CORS support built-in (Wordpress comes to mind).

      2. 1

        When you say “without a server” you mean “without a server that you have any control over”.

        1. 1

          To be more precise, “without having to manage an additional server just for reverse proxying. As I mentioned in the other comment thread, the goal is not to make earth shattering tech claims, rather highlight that this solution allows you to avoid managing and deploying a server for reverse proxying.

          I’ll try to rephrase it nevertheless, thank you!