Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things you should do now (2011)

secure.phabricator.com

Post reply on HN
Print view View original

51–60 of 115 posts

Re: Things you should do now (2011)

#51

Post by marcus_holmes »

mherrmann wrote: post #39
marcus_holmes wrote: post #35

Earlier quoted context omitted.

this, also there's no possibility of collision. You can't have two processes generate the same ID (which means you can generate your IDs in code and send them to the database, which is really useful in some situations). Also, and this is the main one for me - if I mess up my code and accidentally use a document_id instead of a user_id, I'll just get "not found" instead of someone else's data.

Actually, afaik uuids are pseudo-random and can thus absolutely collide in theory. Collision is solved by every db backend out there.

UUID collision is not possible in practice. You can absolutely code in the absolute knowledge that your application will not generate 2 identical UUID's ever. The odds are astronomical. You have bigger concerns.

And yes, every DB backend has solved collision. But as I said, it's useful to be able to generate ID's in code sometimes. This is possible with UUID's and not possible with integers.

Re: Things you should do now (2011)

#52

Post by marcosdumay »

chromatin wrote: post #30
dkarp wrote: post #28

Earlier quoted context omitted.

integer ids are still often used internally for database primary keys with UUIDs being the done thing for external interfaces. Personally I've never experienced the "whole class of bugs" that starting with a big integer is supposed to solve. I'm not using PHP so maybe that's why?

The reason (other than "don't expose integer PK externally") people say you should use integer as PK and UUID as a secondary/external facing id is that conventional B-tree indexing of UUID is not as efficient as B-tree indexing of autoinc integers in most databases. However if you want any sort of efficient lookup on the external key (UUID), your database still needs an index on the UUID, and you are back at square o…

Odds are very big that the set of externally visible entities is much smaller than the set of database entities.

That is, unless you decide to put the same interface into your database and your API, what is not rare for OOM-only programmers to do, but always ends in tears.

Re: Things you should do now (2011)

#53

Post by silvestrov »

> Only Store Valid UTF-8

Linux could learn something about filenames here.

Personally I would also disallow anything below 32 to avoid having filenames contain escape sequences.

I have absolutely no need for a filename that contains an escape character, and would see this as a major bug, like his description of SQL injection. Better to fail fast.

Re: Things you should do now (2011)

#54

Post by urban_alien »

dkarp wrote: post #28
marcus_holmes wrote: post #20

Things you should never do: use integers as ID's. This is literally a solved problem, and the solution is UUIDs, which were invented for exactly this job.

integer ids are still often used internally for database primary keys with UUIDs being the done thing for external interfaces. Personally I've never experienced the "whole class of bugs" that starting with a big integer is supposed to solve. I'm not using PHP so maybe that's why?

I've been using PHP professionally for 5+ years and never experienced it either. Sounds to me that this is just bad coding

Re: Things you should do now (2011)

#55

Post by urban_alien »

marcus_holmes wrote: post #50
LordHeini wrote: post #47

Earlier quoted context omitted.

No you should not. UUIDs are not always a good solution. If you order things by id (often useful for pagination, since incrementing ids are usually ordered by creation date) uuid are of no help. You would need to sort by created_at and this would require an additional index. No to speak of pagination by id ranges or whatever is used sometimes. UUIDs are mpossible to remember and thus somewhat cumbersome to use too. T…

Integer ID's are always a bad thing. Yes, you should be sorting things by created_at. Having another index is not a bad thing. > The weird id mixed up with index problem from the article is something which never happened to me ever in over 10 years of web development. How do you know? It's a remarkably difficult bug to detect.

> Integer ID's are always a bad thing.

You are very wrong and wildly misunderstanding the problem that UUIDs solve

Re: Things you should do now (2011)

#56

Post by Deadron »

account42 wrote: post #42
ivanbakel wrote: post #17

Earlier quoted context omitted.

Those shorter strings can come with their own caveats. Long-form UUIDs have the nice property of being URL-safe - but IIRC, path pieces in HTTP urls are not meant to be case-sensitive, and browsers have historically tried to "help" by re-casing URLs. For correct semantics, short UUIDs have to go in the request parameters instead.

> IRC, path pieces in HTTP urls are not meant to be case-sensitive, and browsers have historically tried to "help" by re-casing URLs. That would break with any webserver that is serving files from a case-sensitive filesystem. Which is most of them.

Windows....enough said.

Re: Things you should do now (2011)

#57

Post by unethical_ban »

corty wrote: post #18
adrianN wrote: post #15

Earlier quoted context omitted.

This topic is pretty close to flamebait so it gets downvoted would be my guess.

Yes, but why? How? I'm a non-native-speaker as well, and these things might be obvious to you, but they aren't to me. Is it a "should not use it", "must not use it", "maybe" or "it's fashionable"? How bad would it be if I accidentially use it, more like a four-letter-word or more like "well, he's a foreigner, he doesn't know"?

I'm the opposite of the other person: Use the known terms until someone complains. Very few people have a problem with `blacklist` just like very few people had a problem with `master` branch.

Re: Things you should do now (2011)

#58

Post by hansvm »

ivanbakel wrote: post #17
krab wrote: post #12

Earlier quoted context omitted.

You can encode it to a shorter string if you use larger alphabet. Still, it's 16 bytes of information, so not as short as sequential IDs. See for example https://pypi.org/project/shortuuid/ >>> shortuuid.uuid() 'vytxeTZskVKR7C7WgdSP3d'

Those shorter strings can come with their own caveats. Long-form UUIDs have the nice property of being URL-safe - but IIRC, path pieces in HTTP urls are not meant to be case-sensitive, and browsers have historically tried to "help" by re-casing URLs. For correct semantics, short UUIDs have to go in the request parameters instead.

Most of the url (including the path pieces) is supposed to be case sensitive unless otherwise specified for a given protocol (and treating e.g. %3A the same as %3a). This should be the most recent RFC on the topic: https://tools.ietf.org/html/rfc3986#section-6.2.2.1
Post reply on HN