Input validation

h commented

2026-06-01 04:11:30 +00:00

Owner

Currently, inputs are not validated. This makes it unsafe to expose a deployment of this project to the internet, to the extent that a deployment is likely to be abused if someone specifically targets it with knowledge of the underlying codebase.

h added the

labels

2026-06-01 04:21:40 +00:00

Firepup650 commented

2026-07-15 06:35:31 +00:00

Contributor

What exactly would be the expected input? Just a youtube URL?

h commented

2026-07-15 06:39:52 +00:00

Author

Owner

await (await fetch(`https://www.youtube.com/@${channelName}`)).text(),

The expected input is a YouTube account username

https://git.h.wer.ee/h/ytrss/src/commit/2ff8b700980533cfac23dd7a685dd260e52c6c8a/index.js#L14 The expected input is a YouTube account username

Firepup650 commented

2026-07-15 06:44:05 +00:00

Contributor

fwiw, that's the channel "handle" not the channel name

based on https://support.google.com/youtube/answer/11585688?hl=en, probably will cap to 3-30 chars (ignoring the weird limits on different scripts), and do the "underscores/hypens/periods" rule, but I feel like "url-like" and "phone number-like" are a bit out-of-scope, unless you disagree

fwiw, that's the channel "handle" not the channel name based on https://support.google.com/youtube/answer/11585688?hl=en, probably will cap to 3-30 chars (ignoring the weird limits on different scripts), and do the "underscores/hypens/periods" rule, but I feel like "url-like" and "phone number-like" are a bit out-of-scope, unless you disagree

h commented

2026-07-15 06:46:42 +00:00

Author

Owner

Honestly, that looks extremely hard to validate, would consider anything not using common ASCII characters to be unsupported at this time

Firepup650 commented

2026-07-15 06:48:39 +00:00

Contributor

Fair enough, do you agree with the rest of my intent though? (3-30 alphanumeric [plus _-.·] characters)

Fair enough, do you agree with the rest of my intent though? (3-30 alphanumeric [plus `_-.·`] characters)

h commented

2026-07-15 06:50:18 +00:00

Author

Owner

@Firepup650 wrote in #1 (comment):

Fair enough, do you agree with the rest of my intent though? (3-30 alphanumeric [plus _-.·] characters)

Sounds good!

@Firepup650 wrote in https://git.h.wer.ee/h/ytrss/issues/1#issuecomment-49: > Fair enough, do you agree with the rest of my intent though? (3-30 alphanumeric [plus `_-.·`] characters) Sounds good!

Firepup650 commented

2026-07-15 06:51:54 +00:00

Contributor

What should resolve_ytid return for bad ids? should we just bail with an error or return nothig or how should we handle this?

What should `resolve_ytid` return for bad ids? should we just bail with an error or return nothig or how should we handle this?

h commented

2026-07-15 06:56:02 +00:00

Author

Owner

Honestly, an error would be best if and only if express handles that by returning an error on the HTTP request, rather than crashing the entire server

Firepup650 commented

2026-07-15 06:59:02 +00:00

Contributor

Since we're doing very little validation here, would it be worth it to have 404s/things like that also throw an error?

It's not hard to make express handle errors, in fact that's actually pretty easy.

Example from my site:

app.use(function(error, req, res, next) {
  console.log(error);
  res.status(500).render(dir + "errors/500.ejs", { error });
});

Since we're doing *very little* validation here, would it be worth it to have 404s/things like that also throw an error? It's not hard to make express handle errors, in fact that's actually pretty easy. Example from my site: ```javascript app.use(function(error, req, res, next) { console.log(error); res.status(500).render(dir + "errors/500.ejs", { error }); }); ```

h commented

2026-07-15 07:00:16 +00:00

Author

Owner

@Firepup650 wrote in #1 (comment):

Since we're doing very little validation here, would it be worth it to have 404s/things like that also throw an error?

It's not hard to make express handle errors, in fact that's actually pretty easy.

Example from my site:
app.use(function(error, req, res, next) {
  console.log(error);
  res.status(500).render(dir + "errors/500.ejs", { error });
});

if you want to implement such a thing, go for it, I guess!
would prefer it if different types of things caused different types of errors and resulted in different responses tbh

@Firepup650 wrote in https://git.h.wer.ee/h/ytrss/issues/1#issuecomment-53: > Since we're doing _very little_ validation here, would it be worth it to have 404s/things like that also throw an error? > > It's not hard to make express handle errors, in fact that's actually pretty easy. > > Example from my site: > > ```javascript > app.use(function(error, req, res, next) { > console.log(error); > res.status(500).render(dir + "errors/500.ejs", { error }); > }); > ``` if you want to implement such a thing, go for it, I guess! would prefer it if different types of things caused different types of errors and resulted in different responses tbh

Firepup650 commented

2026-07-15 07:01:49 +00:00

Contributor

That shouldn't be hard either, we can do an if/then/elif check off the error message from the error object that gets passed to the error handler.

For things that fail input validation/404 on youtube, should we just send a 404, and a 500 for any unknown error?

That shouldn't be hard either, we can do an if/then/elif check off the error message from the error object that gets passed to the error handler. For things that fail input validation/404 on youtube, should we just send a 404, and a 500 for any unknown error?

h commented

2026-07-15 07:03:00 +00:00

Author

Owner

would prefer errors that make sense, so a 404 for input validation failures wouldn't be ideal.
honestly, feel free to submit a PR; reviewing an actual implementation would be easier than reviewing ideas

would prefer errors that make sense, so a 404 for input validation failures wouldn't be ideal. honestly, feel free to submit a PR; reviewing an actual implementation would be easier than reviewing ideas

Firepup650 commented

2026-07-15 07:04:30 +00:00

Contributor

What should we return then? It "should" be a 404 for channels on youtube that don't exist, and anything that fails input validation, by logic, does not exist, so I feel a 404 is correct as a reply, you know?

h commented

2026-07-15 07:05:33 +00:00

Author

Owner

Honestly, seems appropriate for a validation failure

Honestly, ![a 400 response](https://http.cat/400) seems appropriate for a validation failure

Firepup650 commented

2026-07-15 07:06:46 +00:00

Contributor

I suppose that's fair, but then should we return a 400 for 404'd channels as well? It feels odd to treat validation failures as a 400, especially when the upstream service would give a 404 in reply instead (I think)

h commented

2026-07-15 07:09:22 +00:00

Author

Owner

@Firepup650 wrote in #1 (comment):

I suppose that's fair, but then should we return a 400 for 404'd channels as well? It feels odd to treat validation failures as a 400, especially when the upstream service would give a 404 in reply instead (I think)

Returning a 404 if we get an upstream 404 makes sense, sure, but if we're generating the response code ourselves based on our own validation failure, we should return something that reflects that, even if only for making debugging easier.

@Firepup650 wrote in https://git.h.wer.ee/h/ytrss/issues/1#issuecomment-59: > I suppose that's fair, but then should we return a 400 for 404'd channels as well? It feels odd to treat validation failures as a 400, especially when the upstream service would give a 404 in reply instead (I think) Returning a 404 *if* we get an upstream 404 makes sense, sure, but if we're generating the response code ourselves based on our own validation failure, we should return something that reflects that, even if only for making debugging easier.

Firepup650 commented

2026-07-15 07:09:47 +00:00

Contributor

Fair enough.

Firepup650 referenced this issue from a pull request that will close it,

2026-07-15 23:28:18 +00:00

feat:Channel handle validation #4

h closed this issue

2026-07-15 23:48:03 +00:00

Rows
Columns

Input validation #1