7 ms·

What? Would you rather have JSON as a string or as something like Map<string, JsonValue>? > No, if your idea of validating an email is more complicated than "s

What? Would you rather have JSON as a string or as something like Map<string, JsonValue>? > No, if your idea of validating an email is more complicated than "should have an @ symbol" Then how is just using a string any better? Would you rather litter the entire codebase with validations that this is indeed a valid email or just do it once at the entry point? I think excessive type system hacks are bad too but they are more often than not the problem of the language where its unable to express certain concepts naturally (see C++ template hacks).

jstimpfle 4y ago
> Would you rather litter the entire codebase with validations that this is indeed a valid email Why would you? Just use it. For most of parts of the program it's not relevant to the computation whether the string is a "valid email", whatever that means. It's a string.
- rowanG077 4y ago
  "Just use it" is what lead to the big SQL injection fallout and even today we pay the price as not even a year ago thousands of crucial service were vulnerable via log4j because of the "Just Use It" mantra.
  - jstimpfle 4y ago
    You don't understand what I said. I say, don't make assumptions unless you need them. Formatting an email address in an HTML document would work by wrapping it in the appropriate tag. (which implies html-quoting it correctly, but that is unrelated to email syntax). Sending an email using an API would work by passing the email as a string to the API. Looking up an email address from an address book using a pattern to match would be implemented with normal text search. It doesn't matter if the email is "valid" or not. Don't overthink it.
  - afiori 4y ago
    SQL injection, XSS, and similar attacks are about incorrectly encoding embedded fragments. The solution is either not to embed (SQL parameter bindings) or to always escape embedded fragments based on the embedding context For reference: The Last XSS Defense Talk - Jim Manico - NDC Porto 2022 | https://youtu.be/wRC7jyhTkEM https://youtu.be/wRC7jyhTkEM
  - xigoi 4y ago
    You don't avoid injection attacks by validation, but by escaping.
    - rowanG077 4y ago
      escaping requires validation. You don't know what to escape if you aren't allowed to validate.
      - jstimpfle 4y ago
        You don't know what you're talking about. For example, HTML escaping (a.k.a quoting) rules don't care what you're escaping - an email, a street name. It's just text. And that's the point of it. You quote precisely because the container syntax doesn't know the syntax of what you're embedding. If it knew, there would be no need of the escaping. It's called abstraction.
        rowanG077 4y ago
        HTML escaping requires you to look for characters to escape for it to not interfere with HTML. This is quite literally validating symbols in the input. If they fail validation they need to be escaped. It's literally IMPOSSIBLE to do escaping without first validating every single symbol in the input.
        xigoi 4y ago
        You seem to have a weird definition of “validation”.
        jstimpfle 4y ago
        So you're "validating" symbols now (strange choice of word). But certainly validating that the higher-level construct that we're escaping is an email address. Because the escaping procedure doesn't care.
        rowanG077 4y ago
jstimpfle 4y ago
> What? Would you rather have JSON as a string or as something like Map<string, JsonValue>? This question can't be answered without additional context. What are the requirements? But as a heads up, Map<string, JsonValue> couldn't be representation of all valid JSON documents. Lists are valid Json as well AFAIK. So I think this is making a point.
- Izkata 4y ago
  Based on the casing JsonValue is an object, not a primitive, so there's no reason that interface wouldn't work. It would just by a different subtype depending on what type the value is, and lists/dicts would also implement the Map<string, JsonValue> interface.
  - jstimpfle 4y ago
    As much as I can just happily ignore JSON because I don't do webdev, I think there is a strong case to make that lists should be implemented using a native list, array, or vector class. But I won't argue because it's not necessary. The possibility for argument already proves my point. My point is to show that "the type system" provides endless rabbit holes, and often is just a waste of time. There are a lot of situations where you want to represent a JSON document as a string. (Trivial example, as an embedding in an HTTP response object).
    - Izkata 4y ago
      > The possibility for argument already proves my point. Was just correcting something wrong: > But as a heads up, Map<string, JsonValue> couldn't be representation of all valid JSON documents. So, > As much as I can just happily ignore JSON because I don't do webdev I think this is why you're going wrong here. JSON is pretty much a solved problem, and Map<string, JsonValue> is pretty close to how it's used in Java and other languages that don't have native types that match its structure (like javascript and python do). > (Trivial example, as an embedding in an HTTP response object) This isn't json, it's what you get when you stringify/dumps/convert the json into a different datatype. When you need to be specific it's often called a "json string".

jstimpfle 4y ago

> Would you rather litter the entire codebase with validations that this is indeed a valid email Why would you? Just use it. For most of parts of the program it's not relevant to the computation whether the string is a "valid email", whatever that means. It's a string.

rowanG077 4y ago
"Just use it" is what lead to the big SQL injection fallout and even today we pay the price as not even a year ago thousands of crucial service were vulnerable via log4j because of the "Just Use It" mantra.
- jstimpfle 4y ago
  You don't understand what I said. I say, don't make assumptions unless you need them. Formatting an email address in an HTML document would work by wrapping it in the appropriate tag. (which implies html-quoting it correctly, but that is unrelated to email syntax). Sending an email using an API would work by passing the email as a string to the API. Looking up an email address from an address book using a pattern to match would be implemented with normal text search. It doesn't matter if the email is "valid" or not. Don't overthink it.
- afiori 4y ago
  SQL injection, XSS, and similar attacks are about incorrectly encoding embedded fragments. The solution is either not to embed (SQL parameter bindings) or to always escape embedded fragments based on the embedding context For reference: The Last XSS Defense Talk - Jim Manico - NDC Porto 2022 | https://youtu.be/wRC7jyhTkEM https://youtu.be/wRC7jyhTkEM
- xigoi 4y ago
  You don't avoid injection attacks by validation, but by escaping.
  - rowanG077 4y ago
    escaping requires validation. You don't know what to escape if you aren't allowed to validate.
    - jstimpfle 4y ago
      You don't know what you're talking about. For example, HTML escaping (a.k.a quoting) rules don't care what you're escaping - an email, a street name. It's just text. And that's the point of it. You quote precisely because the container syntax doesn't know the syntax of what you're embedding. If it knew, there would be no need of the escaping. It's called abstraction.
      - rowanG077 4y ago
        HTML escaping requires you to look for characters to escape for it to not interfere with HTML. This is quite literally validating symbols in the input. If they fail validation they need to be escaped. It's literally IMPOSSIBLE to do escaping without first validating every single symbol in the input.
        xigoi 4y ago
        You seem to have a weird definition of “validation”.
        jstimpfle 4y ago
        So you're "validating" symbols now (strange choice of word). But certainly validating that the higher-level construct that we're escaping is an email address. Because the escaping procedure doesn't care.
        rowanG077 4y ago

jstimpfle 4y ago

> What? Would you rather have JSON as a string or as something like Map<string, JsonValue>? This question can't be answered without additional context. What are the requirements? But as a heads up, Map<string, JsonValue> couldn't be representation of all valid JSON documents. Lists are valid Json as well AFAIK. So I think this is making a point.

Izkata 4y ago
Based on the casing JsonValue is an object, not a primitive, so there's no reason that interface wouldn't work. It would just by a different subtype depending on what type the value is, and lists/dicts would also implement the Map<string, JsonValue> interface.
- jstimpfle 4y ago
  As much as I can just happily ignore JSON because I don't do webdev, I think there is a strong case to make that lists should be implemented using a native list, array, or vector class. But I won't argue because it's not necessary. The possibility for argument already proves my point. My point is to show that "the type system" provides endless rabbit holes, and often is just a waste of time. There are a lot of situations where you want to represent a JSON document as a string. (Trivial example, as an embedding in an HTTP response object).
  - Izkata 4y ago
    > The possibility for argument already proves my point. Was just correcting something wrong: > But as a heads up, Map<string, JsonValue> couldn't be representation of all valid JSON documents. So, > As much as I can just happily ignore JSON because I don't do webdev I think this is why you're going wrong here. JSON is pretty much a solved problem, and Map<string, JsonValue> is pretty close to how it's used in Java and other languages that don't have native types that match its structure (like javascript and python do). > (Trivial example, as an embedding in an HTTP response object) This isn't json, it's what you get when you stringify/dumps/convert the json into a different datatype. When you need to be specific it's often called a "json string".