gabotechs / signway

Bring the power of pre-signed URLs to your apps. Signway is a gateway for redirecting ephimeral signed URLs to the requested API

Signway is a proxy server that addresses the problem of re-streaming third-party API responses from backend to frontend by allowing the frontend to "directly" request these APIs. Your backend code creates syncronously a short-lived signed URL that points to the third-party API, and your frontend code issues an HTTP query to that URL, which will query the third-party API safely proxying the request through Signway.

Check the docs for more info. If you are looking for the managed version checkout this link.

Sign your requests and proxy them

Terminal 1: Launch Signway

Terminal 2: Create Signed URLs

Export the signing credentials for Signway: export SW_ID="app-id" export SW_SECRET="super-secure-string" Export your OpenAI's API key here: export API_KEY="your working token" Launch Signway, ready for accepting requests signed with SW_ID and SW_SECRET: docker run -p 3000:3000 gabotechs/signway \ $SW_ID \ $SW_SECRET \ --header "Authorization: Bearer $API_KEY" Leave Signway running in this terminal...

👈 Export the same credentials: export SW_ID="app-id" export SW_SECRET="super-secure-string" Install Signway's Python sdk: python3 -m venv venv source venv/bin/activate pip install signway-sdk Make a script for creating signed URLs: cat << 'EOF' > sign.py from signway_sdk import sign_url import os print(sign_url( os.environ['SW_ID'], os.environ['SW_SECRET'], "http://localhost:3000", "https://api.openai.com/v1/completions", 10, # <- URL expiration time in s "POST" )) EOF Make a request to the generated signed URL, as if it was OpenAI: curl $(python3 sign.py) \ -H "Content-Type: application/json" \ -d '{ "model": "text-davinci-003", "stream": true, "prompt": "Say this is a test" }'

What does it solve?

Imagine that you have a setup that looks like this. Your backend accesses a public and authenticated api using an API token, and the response needs to be streamed in chunks, because it is a lot of data or because the response uses SSE.

sequenceDiagram
    participant frontend
    participant backend
    participant third_party api
    
    frontend->>+backend: request
    backend->>backend: authentication
    backend->>+third_party api: request + API token
    third_party api->>-backend: data stream
    backend->>-frontend: data stream

As you own the backend, you can safely configure there any api tokens needed for authenticating against the third party API, and re-stream back the data as it comes to the end user.

However, if you are using a serverless architecture, this gets tricky for two reasons:

1. Most serverless setups, like AWS lamda with API Gateway, don't allow you to stream the response, you can only send back one final blob.
2. Your serverless function would need to live for a very long time, even if it is just doing slow IO data transfer, so cost may increase significantly.

This is where Signway enters the game. Signway provides you a way of letting the end user do the request "almost directly" to the third party API in a secure way without the need of leaking credentials.

The schema using Signway looks like this:

sequenceDiagram
    participant frontend
    participant serverless backend
    participant Signway
    participant third_party api

    frontend->>+serverless backend: request
    serverless backend->>serverless backend: authentication
    serverless backend->>serverless backend: create signed url using an "id" and a "secret"
    serverless backend->>-frontend: signed URL
    frontend->>+Signway: signed URL + request
    Signway->>Signway: verify signature for "id" using "secret"
    Signway->>+third_party api: request + API token
    third_party api->>-Signway: data stream
    Signway->>-frontend: data stream
    

This way you leverage heavy IO work to Signway, which is a high performant gateway server written in Rust prepared for heavy throughput, and you are able to stream data to end users from APIs that send you data chunk by chunk.

Signing algorithm

The signing algorithm is inspired strongly by AWS signature v4, the same that s3 uses for generating pre-signed URLs for letting clients interact with buckets directly.

Generating a signed URL requires that the signer (usually an application's backend) knows a public id and a private secret. The id will live in plain text in the signed URL, and the secret will be used for creating the request's signature, but it is not included in the URL.

Signway, who knows which secret is associated to which id, will take the request and recalculate its signature. If the declared signature and the calculated one match, and the request has not expired, it will proxy the request to the specified third party API, adding any preconfigured headers for that id, like API tokens.

Usage

The server is meant to be used with docker, there are public images with support for linux/arm64 and linux/amd64.

docker run gabotechs/signway my-id my-secret

You can also declare the headers that will be automatically added to the proxy-ed request in case of an authentic signed request is received:

docker run gabotechs/signway my-id my-secret -h 'Authorization:Bearer my-secret-token'

Pre-signed URL generation

Typically, the Signway server will be publicly accessible to the internet, prepared to accept requests with a pre-signed URL, but someone needs to create those pre-signed URLs. This should be a trusted source, as it needs to know the signing secret, like an application's backend.

There is support for generating Signway pre-signed URLs for the following languages:

• Python
• JavaScript

In order to generate a pre-signed URL, knowing the id and the secret that Signway is expecting is necessary, and as the secret is private, it is important to be careful not to leak it.

signway's Issues

This is genius

Hi @gabotechs ,

The approach of using short lived pre-signed URL is genius!

I was looking to solve the same problem - how to use serverless functions and stream results.

I was thinking of building a cloud service that would do that. Although the developer experience and security would be no as great as yours, as you would have to expose the API key of the cloud service to the frontend. I built a landing page for it, but didn't get enough traction and abandoned the idea.

That said, I recently released a library for processing streamed JSON on the frontend.

Anyway, very well done!

And, by the way, the waiting list on your website seems broken. It shows me a 404. after I fill it in.