I understand why you would use this, and it does seem like a good enough solution to a problem, but the underlying problem is you’re using Lambda instead of a real server, so it is probably worth seeing if you can solve the underlying problem instead. I say this as someone stuck on Lambda who would rather be on a real server. :-)
Fully agree, and it feels like something I’ve built a bunch of times; latest is that we built something somewhat similar locally to deal with the fact that you can’t add headers to content-disposition: download links, so triggering downloads from our backend requires a roundtrip to fetch a (very short-lived) signed URL and then redirect to that.
I don’t say that to minimize, just to add that this is a common issue that’s relatively easily solved in-app when you don’t have the extra lambda requirement.
The language and the diagrams are a little difficult to reconcile. The description says it will redirect the client’s request to the 3rd party API but it seems clear from the diagram that it is forwarding the request. So I gather, despite the description using AWS APIs as an example, this is generally intended for fronting APIs that do not themselves support signature authentication. Is everyone else reading this that way?
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 redirect the request to the specified third party API, adding any preconfigured headers for that id, like API tokens.
So, as I read it, you’re hard coding the Bearer token that the third party needs in the secrets file for signway.
I understand why you would use this, and it does seem like a good enough solution to a problem, but the underlying problem is you’re using Lambda instead of a real server, so it is probably worth seeing if you can solve the underlying problem instead. I say this as someone stuck on Lambda who would rather be on a real server. :-)
Fully agree, and it feels like something I’ve built a bunch of times; latest is that we built something somewhat similar locally to deal with the fact that you can’t add headers to
content-disposition: downloadlinks, so triggering downloads from our backend requires a roundtrip to fetch a (very short-lived) signed URL and then redirect to that.I don’t say that to minimize, just to add that this is a common issue that’s relatively easily solved in-app when you don’t have the extra lambda requirement.
If you can set up one “real server” like signway, why not a real server for the rest of your traffic?
The language and the diagrams are a little difficult to reconcile. The description says it will redirect the client’s request to the 3rd party API but it seems clear from the diagram that it is forwarding the request. So I gather, despite the description using AWS APIs as an example, this is generally intended for fronting APIs that do not themselves support signature authentication. Is everyone else reading this that way?
So, as I read it, you’re hard coding the Bearer token that the third party needs in the secrets file for signway.
Yeah I’d much rather this be a support library for pre-signed URLs in the end application