Add filehost #562
Add filehost #562
Conversation
| When clients wish to upload a file using the server's recommended service, they | ||
| can send a request to the upload URI. The request method MUST be POST. Clients | ||
| SHOULD authenticate their HTTP request with the same credentials used on the | ||
| IRC connection (e.g. HTTP Basic for SASL PLAIN, HTTP Bearer for SASL |
There was a problem hiding this comment.
The spirit of my draft was that servers would embed credentials in the URL, to allow uploading to third-party services. With your design, third-party services get connection credentials that are valid for the IRCd in the most common SASL scheme (PLAIN).
There was a problem hiding this comment.
Yes. This is an intentional design decision. The filehost server can forward the request to another server if need be.
There was a problem hiding this comment.
but it still knows the password
There was a problem hiding this comment.
I'm not sure I understand?
What I meant is that the filehost server can be hosted by the same folks as the IRC server, can check the credentials in the request, and can forward requests without IRC credentials to another server if need be.
Here's why I deviated from your proposal:
- Putting secrets in URLs is a bit scary. ISUPPORT is in general not security-sensitive.
- The upload service cannot be any random third-party: it needs to implement the spec's endpoints. In general, third-party upload services have a custom API.
- With your proposal, the external service still needs to be somehow tied to the IRC server to check the credentials embedded in the request URL. Credentials need to be per IRC connection. With signed tokens you hit issues regarding revocation etc.
- It resulted in a lot of additional complexity in my server implementation. On the other hand, proxying is very simple (and implemented in soju).
There was a problem hiding this comment.
What I meant is that the filehost server can be hosted by the same folks as the IRC server
My point was that it doesn't have to be.
The upload service cannot be any random third-party: it needs to implement the spec's endpoints.
There's no endpoint, it's just a URL that accepts generic HTTP POST
With your proposal, the external service still needs to be somehow tied to the IRC server to check the credentials embedded in the request URL.
My thinking was that the IRC server would create token on the external service, not the other way around.
Putting secrets in URLs is a bit scary. ISUPPORT is in general not security-sensitive.
It resulted in a lot of additional complexity in my server implementation. On the other hand, proxying is very simple (and implemented in soju).
Those however, are good points. I'm sold.
This is shipped by soju + gamja + goguma + senpai as a vendored spec, and is based on an earlier draft by @progval.