3 ms·
I see this an issue of typing. Programs use integers in many different kinds of ways, and if you have a function that accepts an integer as an argument, neither
by peterkelly 9y ago
I see this an issue of typing. Programs use integers in many different kinds of ways, and if you have a function that accepts an integer as an argument, neither static nor dynamic type checking will catch the case where you pass the wrong "type" of integer. The same goes for UUIDs, strings, etc. or whatever other opaque values you use to reference entities in your system.
You can avoid these problems by wrapping the integers in objects that you use solely for referencing entities of the relevant type. For example:
class UserRef {
id: int;
}
Then you define functions like this:
function ban_account(user: UserRef) {
// ...
}
And a static type checker will pick up incorrect uses. For dynamically typed languages, you could instead use a unique field name such as user_id, to achieve the same thing (though getting a runtime error instead of a compile time error).
Obviously you'll still be using ints or strings as an external representation, but as long as you do the conversion at the point where the identifier enters the program, the type system will take care of the rest for you.
- tigershark 9y agoIt’s what pretty much everyone in the F# or DDD community is advocating for. Avoiding to use the first 10000 integers as she suggested is not a solution. And using contiguous integers as user ids is the silliest thing that you can do given that it leaves you also open to enumeration attacks.
- naasking 9y ago> And using contiguous integers as user ids is the silliest thing that you can do given that it leaves you also open to enumeration attacks. I don't think it's silly, you just need to protect your parameters. There's a way to do this as part of the basic programming framework. See my other post: https://news.ycombinator.com/item?id=16947546 https://news.ycombinator.com/item?id=16947546
- deleted 9y ago[deleted]
- chriswarbo 9y ago> I see this an issue of typing Yes, this reminds me of "stringly typed programming", i.e. where the language may offer strong types, but the program just uses `String` everywhere. String injection attacks are examples of this: SQL injection can only occur if it's possible to concatenate "SQL statement" with "user input"; if these are both represented as `String` then it's easy to run into such problems; if they're represented as different types, then the only way to combine them would be with a designated conversion function, which is exactly where we can put the neccessary escaping. See also: http://blog.moertel.com/posts/2006-10-18-a-type-based-solution-to-the-strings-problem.html http://blog.moertel.com/posts/2006-10-18-a-type-based-soluti...
- weberc2 9y agoCMake is stringly typed, and that’s only part of the reason it’s such an atrocity.
- weberc2 9y agoYou’re right that it’s an issue of typing, but lots of type systems handle this just fine. Even Go’s type system—which everyone loves to hate—let’s you create new types from existing ones (such as a UserID type based on int). This feature is frequently referred to as newtype, and its even present in Python via typing.NewType! This is a bit nicer than the wrapper approach you describe for performance reasons (in practice, wrapping an int in a class will create unnecessary overhead for many languages).